My comment on being locked in specifically referred to the long train of Microsoft technologies that arrived, flowered for a short while, and then whithered over the years while I was working on this thing. One of my first choices as a young engineer was to use the win32 API instead of MFC. MFC proved to be a dead-end, so I feel fully justified in choosing what was (officially) the more difficult option. I forget the names of the others... Silverlight is a good example. I feel for anyone who invested in that. And .NET is on the way out, _in my opinion_ (feel free to disagree) - relying on that is a good way to be obsolete a few years from now. But there certainly were others. Who is using COM now, except to interface with specific Microsoft APIs? DCOM? ATL? OLE?
Modernisation is something I've always done during quiet periods. None of my customers needed (or need, even today) IPv6 support, but since adding it was fairly straightforward I've done so anyway. None of my customers needed unicode when I introduced it either, but we have since added a German customer who certainly appreciates being able to use that German S character. Could they have lived without it? Probably. Could we have built in unicode support while already under high load to tailor the software to their site? I very much doubt it. And consider this: the competition for this bid was a package I also happen to know, that crashes when you feed it any character that has the high bit set, so that was one point in our favor then. IPv6 will eventually make sense, and when some customer convenes a Tiger Team for Emergency Network Migration to IPv6 they will call me in, and I will nod sagely and say "click that checkbox over there, and it uses IPv6 instead."
My language of choice is C++. I find the hatred that language gets on /. astonishing - it is not only a powerful language that results in very fast programs, but also a well-established standard supported by multiple vendors with multiple compilers. Over the years I've compiled this project with Visual C++ 5, 6, 2008, 2012, 2013, and now 2015 (see me chase those versions!), acc, and uncounted GCC versions. I'd truly hate to be stuck with a single-compiler language.
We rely on plenty of external packages as well. The underlying database is currently Postgres. Before it used to be Oracle. Our SQL usage is not so arcane that we coulnd't run it on other SQL-compliant databases - a few specialty functions for things like checking database sizes would have to be rewritten, but the bulk of the software would run out of the box.
We have our own drawing API (about 7 primitives, nothing too fancy). It used to do win32 only. Then it got the ability to do X11 as well. Then we changed it to Cairo. We print using the same API - originally through xprint, and now through Cairo + CUPS. It may sound like a lot of change, but it was all confined to a handful of classes, with the rest of the software never knowing the difference.
Anyway, just rambling on now ;-)