Every legacy system still in production is, first of all, a system that works. It processes payments, issues documents and supports the company’s revenue. The problem is that change has become expensive: every update takes months, few people know the code and integration with digital channels turns into a patchwork. The temptation is to rewrite everything from scratch. In our experience with large banks, payment providers and the public sector, the big-bang replacement is usually the riskiest path. What works is modernizing piece by piece, while operations keep running.
Strangler fig: replace it gradually
The strangler fig pattern means building the new system around the old one, taking over one capability at a time. Each migrated piece is served by the new system, and the legacy shrinks until it can be switched off. Risk is spread across small releases, and every step delivers value on its own.
APIs in front of the legacy
The first step is usually an API layer between the channels and the old system. Consumers talk to a stable contract, with no knowledge of what sits behind it. That way, you can swap the implementation of a route without touching apps, partners or integrations. This layer is also the right place for observability, security and traffic control.
Migrate by domain, not by layer
Moving the entire database or the entire front end at once creates huge dependencies. It is better to slice by business domain: customer records, billing, limits, customer service. Each domain goes live with an owner, metrics and a team accountable end to end.
Data: the hardest part
Code can be rewritten; data must be preserved. During the transition, the legacy and the new system run side by side, and you need to decide which one is the source of truth for each piece of information. Event-based synchronization, daily reconciliation and clear write rules prevent discrepancies that would otherwise only surface at month-end close.
Modernizing is not about swapping technology. It is about lowering the cost of change without raising the risk of running the business.
Rewrite or wrap?
- Wrap: when the business rules are stable, the system is reliable and the problem lies in integration or user experience.
- Rewrite: when the rules change often, maintenance blocks progress or the technology no longer has vendor support or available talent.
- Regression tests first: before changing anything, capture current behavior with automated tests and compare legacy and new outputs. Without that, there is no way to prove nothing broke.
- A way back: every migration needs gradual traffic switching and a tested rollback.
With this approach, modernization stops being a high-risk bet and becomes a sequence of predictable deliveries. The business keeps running, and the legacy steps aside at the pace operations can handle.
Want to talk about this?
Tell us about your challenge. The conversation is direct and with no commitment.