Legacy software

In a nice article, David Norfolk talks about legacy software applications and what they can do to a company that is to maintain it.

"beware of transforming legacy without a good business reason, just because new technologies are more fashionable – the pointy haired boss may not realise this, but most developers can turn their hand to any language, given a little training and encouragement."

This is so true. In fact, these days, if you are not able to learn a new programming language in a fashionable manner, you cannot be called a good developer. If you "stay true to your first love" you will not be able to become agile in the long term.
But if someone decides to transform a legacy software without a good business reason, like improving performance or adding new and futuristic features, the new endeavour would have a pretty good chance at stalling.

"the code tells you what the legacy does, but you need a domain expert (and, if you're lucky, the documentation) to tell you why it does it; and a technologist to make sure you get the best out of what you're moving to."

This is also very true. You CANNOT port an application if there's nobody that can read between the thousands (if you're lucky) lines of code. The lines of code alone can't help you very much, and, if you believe otherwise, you will hit a concrete wall when you will realize that you were wrong (and you will, eventually).
Furthermore, you'll need a good technician that will leverage the advantages that the language you are porting the application to provides you with.

God knows, in my "programming youth", I've written some code that even I would find hard to read and understand. Given my experience now, I would know how to write the code, even if I don't always write it the way I would like to. But when I see "bad code" written by people I know have experience with such things, I get angry.