The system everyone wants to replace is the one the business cannot run without, and that is exactly why the “big bang” rewrite is the wrong way to replace it. Here are the four ways to modernize a legacy core, the one question that picks between them, why large rewrites fail so reliably, a worked example, and how to start.
Four ways to modernize, and the one question that picks between them
“Modernize” hides four very different projects with very different risk. Naming which one you are doing is half the planning.
- Rehost. Move the system as it is onto new infrastructure, typically a cloud region inside the Kingdom. Cheapest and fastest; changes nothing about how it behaves.
- Replatform. Keep the application, swap what it stands on: the database, the operating system, the middleware. Moderate risk, moderate gain.
- Strangle, or incremental replacement. Wrap the old system, route new work to new components, and migrate function by function while both keep running. This is the pattern for genuine core systems, and the rest of this post is about it.
- Rewrite. Build a replacement from scratch and cut over. Only defensible for small, well-understood systems where a failed cutover is an inconvenience, not a headline.
The question that picks between them is not “how old is it?” It is: if this system stopped for a week, what would stop with it? The bigger that answer, the more the plan has to be incremental and reversible.
flowchart TD
A(["The old system"]) --> B{"If it stopped for a week, what would stop with it?"}
B -->|"Nothing critical"| C(["Rewrite or replatform"])
B -->|"One department"| D(["Replatform, then strangle the painful parts"])
B -->|"The business"| E(["Strangle it: replace piece by piece, never one big switch"])
E --> F(["Every step reversible on its own"])
Why the big bang keeps failing
The instinct is the clean cutover: build the new system off to the side, flip the switch one weekend, retire the old one. It is how the most expensive failures happen.
The track record is sobering. McKinsey and Oxford, across more than 5,400 IT projects, found that large IT projects (initial budget over $15M) run on average 45% over budget, 7% over time, and deliver 56% less value than predicted, and that 17% go so badly they threaten the company’s existence (McKinsey, 2012). The Standish Group’s CHAOS research says the same: roughly 31% of projects succeed, about half are “challenged” (late, over budget, or under scope), and around 19% fail outright, with small projects succeeding far more often than large ones (InfoQ summary of Standish CHAOS, 2015). ERP replacements are not exempt: according to Gartner, a large share of ERP initiatives fail to meet their intended business goals.
In our experience the reasons are predictable. The old system quietly handles hundreds of edge cases nobody wrote down (the customer with two billing addresses, the Hijri-date contract, the month-end job that reruns twice), and the rewrite misses them. We wrote about why software projects really fail; legacy replacement is where every one of those reasons shows up at once.
Strangle the old system, don’t detonate it
The proven pattern has a slightly violent name: the strangler. You put a thin layer you control in front of the old system, route new functionality to new components, and migrate it piece by piece while both keep running. Vines grow over an old wall and take its weight section by section, until the wall is gone and nothing fell down. Each step delivers real value and is reversible on its own.
timeline title Strangle the old core, one safe stage at a time Map it : Learn what the old system really does, edge cases and all Wrap it : Put a facade in front, route new work to new components, old and new running together Win small : Replace a high-pain, low-blast-radius piece first Migrate : Move data and logic across in parallel, compare outputs, keep a path back Reach the core : Take on the scariest part last, once you've earned the confidence
That thin layer, the facade, is what makes each step reversible: once everything talks to it instead of to the old system, any function can be moved to a new component, and moved back, without anyone upstream noticing.
Do this before you touch anything
- Map what the system actually does. Produce three documents: an interface inventory (everything that reads from or writes to it), a batch-job list (every scheduled job and what breaks if it does not run), and a behavior log kept by the operators for a month, noting every workaround.
- Separate what matters from what is just old. Not everything legacy is bad. Some of it encodes years of hard-won business logic. Modernize the parts holding you back, and preserve the logic that is quietly correct.
- Protect the data, and check where it is allowed to go. Migration is where these projects live or die: rehearse it monthly against a copy of production, and keep a path back. If the system holds personal data, the new platform’s location is a legal question: PDPL took effect on 14 September 2023, full compliance was required by 14 September 2024, SDAIA is the regulator, and cross-border transfers are governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). Settle data residency before you pick the target platform.
- Sequence by risk and value. Start where the pain is high and the blast radius is small. Win there, build confidence, then work toward the core, never the other way around. Banks face the least forgiving core of all, and the same sequencing runs through our core banking modernization playbook.
- Get an independent read first. A short technology assessment tells you which of the four types you are facing, and whether the vendor proposing a rewrite is solving your problem or selling a platform.
A worked example: a billing core, piece by piece
Say a distributor runs a fifteen-year-old billing system producing 40,000 invoices a month, and the vendor proposes a 24-month rewrite with one cutover at the end. The numbers are made up to show the shape.
The incremental plan: months one and two are mapping, and the interface inventory turns up eleven integrations, not the six on the architecture slide. Month three puts the facade in front. Months four to six replace the first slice, customer statements: high pain (late every month-end) and low blast radius (a wrong statement is a reissue, not a wrong ledger). Months seven to twelve take on pricing, with a parallel run: every invoice is priced by both engines and compared automatically for three months before the new one is trusted. Ledger posting, the scariest part, comes last, once the team has done the pattern twice.
If the new pricing engine disagrees with the old one on 2% of invoices, the parallel run catches it and the facade stays pointed at the old engine. In the big-bang plan, that same 2% is 800 wrong invoices in the first month, discovered by customers. And if the budget is cut at month twelve, you have working statements and pricing instead of a half-built system nobody can use.
Where modernization goes wrong
- Modernizing the undocumented behavior away. The new team decides the odd rule is a bug and “fixes” it. It was a contract term one large customer still relies on.
- A parallel run without a comparison harness. Running old and new side by side proves nothing unless something compares every output automatically. “It looks fine” is not a test.
- Replacing one lock-in with another. A modernized core only the new vendor can change is the old problem with fresh paint. Exit and integration costs belong in the total cost of ownership before you sign.
- The temporary facade that becomes permanent. This is the honest catch of the strangler pattern: it is easy to stop halfway, with the old system still doing the hard part behind a modern-looking API. Put decommissioning on the plan as a dated milestone with an owner, or it never happens.
How to start without betting the business
The pattern that works is boring and reliable. Spend four to six weeks mapping the system honestly. Score every function on how much pain it causes and how much would break if the replacement went wrong, and pick the one slice that is high on pain and low on blast radius. Put the facade in place, replace that slice, and run old and new in parallel until the numbers match. Measure what changed: cycle time, error rate, hours the team got back. If it worked, scale the pattern to the next slice. If not, you have lost one slice, not the business. It looks slower on a plan and is far faster in real life, because it does not collapse halfway through.
Sitting on a critical system you’re afraid to touch? SDCG plans and delivers incremental modernization. We map what the old system really does, then replace it piece by piece without stopping the business. We’re independent, so we’re solving your problem, not selling you a platform. Book a free 30-minute review.