Every legacy system is despised for the same reasons it is indispensable. It is slow because it handles cases nobody remembers agreeing to handle. It is convoluted because the business is convoluted, and the system, unlike the org chart, was never allowed to pretend otherwise.
When teams plan a replacement, they usually start with a workshop, a whiteboard, and a fantasy: the clean version of the business. The workshops produce a backlog describing a company that does not exist. Then the new system launches, meets the company that does exist, and the "edge cases" begin. They are not edge cases. They are the business.
Read the code like an anthropologist
The twenty-year-old codebase is the only complete, executable description of how your company actually operates. Every weird conditional is a fossil of a real decision: a customer that was too big to lose, a regulation that arrived mid-quarter, a merger that half-happened. You do not have to keep the code. You do have to keep the knowledge.
Before we write anything new, we mine the old system for behaviour: what it does under load, what its users quietly work around, which reports get exported to Excel the moment they render. The workarounds are the roadmap. Anything your staff maintains in a spreadsheet is a feature the old system failed to ship, and the first thing the new one should.
The workarounds are the roadmap.
Replace behaviour, not software
The safest migrations we have run never had a launch day. They wrapped the old system, moved one behaviour at a time behind a seam, and let the legacy core shrink until switching it off was an anticlimax. If your replacement plan requires a weekend cutover and a prayer, what you have is not a plan. It is a bet.
Written by the codemyx studio, the people who build the things these opinions come from.