The most dangerous project in a company's portfolio is often the one it has avoided for a decade: modernising the legacy system that runs the business. Everyone agrees the twenty-year-old core is too slow, too brittle, and too expensive to maintain. Everyone also agrees it cannot be switched off. So nothing happens, and the risk compounds every quarter. The answer is not a bigger project; it is a different strategy. Modernise in small, reversible steps while the old system keeps running. This is the approach we use—and it is how MENA banks, insurers, distributors, and manufacturers keep serving customers while their cores change beneath them.
Why Big-Bang Replacement Fails
The big-bang replacement has a beautiful logic and a brutal record. The project runs for years, the budget grows, requirements shift while the build continues, and the business cannot afford the downtime the cutover requires. By the time a big-bang replacement lands, the requirements that shaped it are already history. The safest way to modernise a legacy system is to stop trying to replace it in one move and start shrinking it instead. You are not replacing the castle; you are building a new one around it and moving rooms over while the residents sleep.
The Strangler Pattern
The strangler pattern works in three moves. First, wrap the legacy system behind a single interface or gateway, so that callers no longer talk to the old system directly. Second, build new services that deliver parts of the old functionality, and route new demand to them. Third, gradually cut the legacy paths as each capability is replaced, until the old system is small enough to retire. Each step is reversible: if a new service underperforms, traffic flips back to legacy in minutes, not months. That reversibility is the whole point.
Choosing What to Strangle First
The order of replacement decides the success of the programme. Start with the capability that causes the most pain and has the fewest dependencies—usually a read-heavy process that can be rebuilt without touching the transactional core. Score every candidate against the same criteria before you commit:
- Clear business value: does replacing it reduce cost, risk, or customer friction?
- Measurable success: can we state before and after in numbers?
- Few dependencies: can it be isolated from the transactional core?
- Small team: can a focused team deliver it in a quarter?
- Reversible: can traffic fall back to legacy if the new slice fails?
- Visible win: will the business notice the improvement quickly?
The Incremental Modernisation Framework
Run the programme on a quarterly heartbeat. Start with an inventory and a dependency map of the legacy landscape—most organisations discover their system is more tangled than they thought. Define the interface contract between the new services and the rest of the world. Build the first slice in parallel with the running system, behind a switch you can flip back. Route a controlled share of traffic to it and measure before and after against the success criteria. When the slice proves itself, move to the next, and let every quarter produce either a finished slice or a documented lesson.
People and Data: The Real Constraints
The legacy system is usually not the hardest part. The hardest parts are the migration of data and the retraining of people, and both are routinely underestimated. Data migration fails on quality, not volume: duplicate records, missing keys, and rules that lived only in people's heads surface only during migration. Plan the data work as a programme of its own, with ownership and cleanup rules before the move. Retraining follows the same logic: sequence it with the technology, keep the old screens documented as long as they exist, and let users meet the new system while it still has a safety net. When technology, data, and people move in the same rhythm, the risk drops sharply and the programme stops being an act of faith.
Funding and Governance for the Programme
An incremental modernisation programme needs its own governance, because it cuts across teams and years. Fund it as a rolling commitment with a quarterly review, not as a one-year project with a fixed end, and tie continued funding to the delivery of finished slices rather than to the passage of time. Assign a single accountable owner who can make trade-offs between the legacy and the new, and protect the programme from the temptation to optimise each slice in isolation. When funding follows value and governance follows delivery, the strangler pattern stays honest and the programme keeps its momentum.
Smart Logic designs and engineers legacy modernisation programmes for MENA organisations—strangler migrations, data migration, and the team skills to sustain them. Start with a modernisation readiness audit and find the first slice that pays for the rest.