Maintenance programmers have it rough. I know; I've been there. You walk into your first day on a job or a project and make the discovery: "Oh, the windowing system was written in ALGOL by nihilists," says the engineer, handing off that code to you. Or, "They didn't call it Java back when this was written, but it's Java. Sort of." The project is a quest through the dark underbelly of the human imagination, using technologies too old to be anything more than footnotes on civilization. You hope to move the project to a newer language (someday), but once you've spent a few months getting to know the code, maybe even making a few fixes, you're stuck.
Maybe you can't convince your bossor worse, yourselfto make the move. Maybe you're waiting for an unspecified "right" time to do it. There's too much code, you don't know what all of it does, how would such a change even work? There's a monkey in your future: a code monkey, hacking away at a tangled web of code that should have died a decade ago and will continue to breathe only because you force air through its evil, blackened lungs, probably late at night and on weekends.
That monkey is you.
What can you do about it? In this article, I'll show you some simple steps I use for upgrading code. This stuff is easy and obvious, probably techniques you've tried (or at least considered) previously, but I'll show you how to add structure and confidence. Then, when you're ready, you can kick that monkey to the curb, shout "I've got a new life now!" and run for the fabled Coding Hills of Happiness, where sample code is plentiful, MSDN entries are relevant to your project, and the libraries do most of what you need. I call this technique snippet-driven migration.
Let's start simply.