The old system is slow, nobody enjoys it, and the person who understands it best retires in two years. Everyone agrees it should be replaced. And every year it isn't, because replacing it means stopping the business for a quarter and nobody can find a quarter.
Your staff may spend the day exporting CSVs, importing them elsewhere and reconciling errors. Scope that integration work before committing to a rewrite; you may be able to address it for less.
Why the rewrite keeps not happening
A replacement can cost a large sum while delivering the capability the business already has. You need to show the board how easier maintenance or future changes justify that cost and the migration risk.
A rewrite that runs 18 months and stops at 70% can leave your team maintaining two incomplete systems. Include that transition risk in the proposal.
Start with the integration work
Give other applications a supported way to exchange data with the legacy system.
Check how staff get data into and out of the system. If its payroll, stock or billing functions have worked for fifteen years, you may be able to retain them while replacing manual transfers.
Give it an API
A thin service in front of the old system, speaking a modern contract. The legacy database doesn't change; what can reach it does.
Move the humans out of the path
Wherever a person is copying between systems, that person is an integration with a salary and a sick day. Replace the path, not the person.
Make the boundary explicit
Once everything talks to the interface rather than the system, the system becomes replaceable — quietly, later, on your schedule.
Once consumers depend on the interface contract, you can replace the implementation behind it in stages. Include that separation in the integration design.
The order that works
Stabilise
Nothing else is safe while the current thing is falling over. Backups, monitoring, and the failure that wakes people up — first, always.
Find where the humans are the integration
Follow the CSVs and the re-keying. That's your map, and it's more honest than any architecture diagram.
Wrap, don't replace
Put an interface in front of the old system. Nothing behind it changes yet.
Point new work at the interface
Every new consumer talks to the contract. The legacy system stops accumulating new dependencies.
Replace behind the contract, when it suits you
Piece by piece, with the business running throughout — and with the option to stop if priorities change.
What this buys you
- The daily pain stops early, because the pain was the seams
- The business case closes, because each step delivers something on its own
- You stop betting the company on a single date
- If priorities change at step three, you can retain the completed integrations instead of depending on a rewrite abandoned at 70%
Ask which requirements would remain unmet if you fixed the integrations alone. Compare those gaps with the cost and risk of a rewrite.
Reasons to replace the system
Consider replacement when:
- The vendor is gone, or the platform is out of support and exposed
- It cannot meet a regulatory obligation, certification requirement or customer's security review
- The people who can maintain it no longer exist in the market
- The cost of working around it each year now exceeds the cost of replacing it
Assess the support, obligations and operating cost before deciding that age warrants replacement.
Where to start
List the transfers your staff perform between systems. Cost their time, reconciliation work and errors, and record who supports each transfer.
Compare that recurring cost with an integration project before you price the full replacement.
Frequently asked questions
You may be able to put a service in front of the legacy system and exchange data through a defined interface. Assess its access and data constraints before committing to the integration.
An integration layer can support a staged replacement if you define and maintain its contract. Once consumers depend on the contract rather than the system, you can replace what's behind it in pieces, on your own schedule. The integration layer is how you earn the option to replace the system later without a big bang.
When the vendor is gone or the platform is out of support and exposed; when it can't meet an obligation you now have, like a certification or a customer's security review; when the people who can maintain it no longer exist in the market; or when the annual cost of working around it exceeds the cost of replacing it. Assess those constraints before choosing replacement on the basis of age.
Ask which requirements would remain unmet after fixing the integrations. Compare those gaps with the cost of replacing the application.
Fix the seams before you bet the quarter on a rewrite
We'll map where people are acting as the integration, and cost the honest version.
Related reading
- Legacy System Modernisation — the phased path
- Software Development — the integration work itself
- Software Review & Implementation — sometimes the platform was fine and the implementation wasn't
- Why the second implementation fails the same way as the first — before you replace it, know what it refused to do
- Build or buy: when off-the-shelf software stops fitting — extending a platform rather than replacing it