Almost every established organisation has one: the system that runs a critical part of the business, built years ago on technology nobody wants to touch, understood properly by one or two people. It works, mostly. Replacing it feels risky, and leaving it alone feels riskier every year.
Big-bang rewrites are where most of the horror stories come from. A staged approach is slower to describe and much safer to deliver.
1. Find out what the system actually does
Documentation for legacy systems is usually missing or out of date. The real specification is the code, the data and the people who use it every day. Discovery means reading all three: tracing the important workflows, finding the business rules hidden in reports and scheduled jobs, and listing every system it talks to.
This step often surfaces features nobody remembers asking for but somebody depends on. Finding them now is far cheaper than finding them after launch.
2. Decide what not to rebuild
Modernisation is a chance to remove as well as replace. Some features are unused. Others are better handled by an off-the-shelf product today. A smaller new system is faster to build, easier to test and cheaper to run.
3. Migrate in slices, not all at once
Instead of replacing everything on one weekend, move one capability at a time. Common patterns include:
- Strangling the old system: new features are built in the new platform, and existing ones move across gradually until the old system has nothing left to do.
- Integration first: connect old and new so data stays consistent while both are in use.
- Read-only coexistence: keep the old system available for history while new work happens in the new one.
4. Treat data migration as its own project
Data in long-lived systems is rarely clean. Expect duplicates, inconsistent formats and fields that were repurposed years ago. Write migrations as repeatable scripts, run them many times against copies of production data, and reconcile the results: record counts, totals and spot checks agreed with the people who know the data best.
5. Run in parallel where it matters
For processes where mistakes are expensive, such as billing or compliance, run the old and new systems side by side for a period and compare their outputs. Differences are either bugs in the new system or undocumented rules in the old one. Both are worth finding before the old system is switched off.
6. Cut over deliberately
A good cut-over is uneventful. It has a written plan, a rehearsal, a clear decision point and a way back if something unexpected happens. Communicate early with the people affected, and have the team who built the new system on hand in the days after launch.
7. Don’t recreate the original problem
The reason the old system became risky is usually that knowledge concentrated in too few people and the code stopped being maintained. Avoid repeating it: automated tests, documentation, code review and a plan for ongoing maintenance are part of the modernisation, not extras.
The goal isn’t just new technology. It is a system more than one person can understand and safely change.