The system nobody dares touch can be modernized while it keeps running. We did it for a FTSE-listed financial group's core back-office, with thousands of users and no interruption. Here is the method.
The rewrite trap
The proposal arrives: the old system is unmaintainable, so build a new one beside it, switch over when it is ready. Eighteen months later the new system is at seventy percent, the old system has changed in forty ways to keep the business running, and the switch-over date has moved three times.
The industry's failure rate on full rewrites is not discussed in sales meetings.
The alternative
Modernize in place. The live system keeps serving users while it is decomposed, cleaned, and replaced one component at a time.
Map first. Every module, dependency, data flow, and consumer, documented as it is, not as the original design intended. This is usually the first accurate documentation the organization has had.
Decompose along the business seams. Not the seams a microservices diagram suggests, but the ones where the business actually changes: billing changes independently of reporting; onboarding changes independently of both.
Migrate data with integrity checks at every stage. A migrated database with one wrong column is worse than no migration, because it is trusted.
Introduce pipelines. Manual deployments and hope are replaced by automated, tested, reversible releases, often for the first time.
Replace components one at a time, with the old and new running side by side until they agree.
What it felt like from inside
At Aegon UK, our CTO worked inside the client's secured data centers, in close collaboration with product owners, infrastructure engineers, and compliance leads. Thousands of internal users kept working throughout. The result was a stable backend that could take future upgrades without risking live operations, and no rewrite was ever needed.