Here are a few recommended readings for those who deal with legacy code...
Refactor vs. rewrite
Spolsky is a very good writer, and expresses simple ideas very well. This article says that it can easily become a strategically disastrous move to rewrite an application from the ground-up. Spolsky recommends against doing that, if at all possible.
On the other hand, there Dan Milstein prodives a counter-argument to Spolsky's, in the following recent response (only 13 years later!):
The "strangler application"
Coined by Martin Fowler, this pattern enables the gradual phase-out of a pre-existing codebase into a new one. Fowler of course makes it sound far, far easier than it actually is (or would be). Like Spolsky though, his thinking is clear and he makes a good point.
A recent article (July 2013) written by Paul Hammant discusses a few "strangler application" initiatives that he has been involved with at ThoughtWorks:
If you read nothing else in Paul Hammant's article, go to the the "best practices" section at the end and just read that.
[Strangler Vine - Source: http://www.flickriver.com/photos/tags/attacking/interesting/]
Technical and innovation debt
Then Peter Bell reminds us of the perils of not taking the opportunity to aspire to the cutting edge and resting on our laurels (that is, current/former market success), with his article on "Innovation Debt":
Innovation debt is essentially technical debt, but applies to people, processes and businesses - instead of nuts, bolts and code.
Refactoring legacy code
Feathers defines "legacy" code as essentially being any code that is untested or currently untestable.
The book is written in the style of the "Gang of Four" Design Patterns book - there are three sections; the first sets the stage, introducing Feathers' reasoning, definitions, and some tools. The second section is scenarios (essentially suggestions as to how to apply patterns to deal with problems, like "My Application Is All API Calls") and the third is a reference for a stack of dependency breaking patterns.
Of course, there is also Martin Fowler's original book on refactoring:
To me, Feather's book however seems to be a much easier read.