Legacy modernization without the big-bang rewrite

Almost every legacy modernization that ships on time has one thing in common: it was never a big-bang rewrite. The systems replaced in one heroic switchover are the ones you read about in post-mortems. Here is how to modernize a core system incrementally, while the business keeps running on it.

Why the big-bang rewrite keeps failing

The plan always sounds clean. Freeze the legacy system, build a modern replacement in parallel, cut over in one weekend, retire the old one Monday morning. It rarely survives contact with reality.

The first problem is that the legacy system is not frozen. It is the business. While the rewrite runs for two or three years, the legacy system keeps absorbing new regulation, new pricing rules, new edge cases. By the time the replacement is "done," it is already missing two years of changes nobody documented.

The second problem is the cutover: a single moment where everything must work at once. Data migration, integrations, performance, the twenty undocumented behaviors some downstream system quietly depends on. If one fails at 2am on go-live night, you roll back the whole thing and explain to the board why the year cost nothing.

Standish Group's CHAOS data has shown for years that large software projects fail or blow their budget far more often than small ones. A big-bang rewrite of a core platform is the largest project a company can pick: the size is the risk. There is a better default.

The strangler-fig pattern, in plain terms

The pattern is named after a fig that grows around a host tree until the tree is gone and the fig stands alone. Applied to software modernization: you build the new system around the old one, capability by capability, until the legacy system has nothing left to do and you switch it off.

Concretely:

• Put a routing layer in front of the legacy system. Every request still hits the old system, for now. Nothing changes for users.
• Pick one capability and rebuild it in the new system, then flip routing for it from old to new. Everything else still runs on legacy.
• Repeat. Each iteration moves one more slice off the old system, until the last one moves and the legacy system becomes dead weight you decommission.

The win is that you are never one switchover away from disaster, only dozens of small, reversible steps away from done. Each step ships to production, gets validated under real load, and can be rolled back in minutes by flipping the route. The business runs the whole time. This is software modernization "while the lights stay on."

The cost is honesty. It is slower in calendar time than the big-bang plan looks on paper, and you run two systems at once during the transition. You pay in duration to remove the risk of one catastrophic failure.

The anti-corruption layer: do not import the old model

Here is the trap that turns a strangler-fig migration into a slow-motion big-bang. To save time, the new code reads and writes the legacy data model directly: same table structures, same sentinel values, same thirty-year-old assumptions in the column names. Six months in, your "new" system is a fresh coat of paint on the old constraints.

The anti-corruption layer prevents this. It is a translation boundary: the new system speaks its own clean domain language, the layer translates to and from whatever the legacy system actually stores, and the legacy quirks stop at that boundary instead of leaking into your new code.

This matters most for legacy application modernization where the data model is the real debt. When the legacy system finally dies, you delete the layer and the new system is free of the old constraints. Skip it, and you will have spent a fortune to relocate your debt.

Sequence by value-at-stake, not by age

The instinct is to start with the oldest, ugliest module. Usually wrong. The oldest module is often the most stable, running untouched for fifteen years precisely because nobody needs to change it. Rebuilding it first burns budget on something that was not hurting anyone.

Sequence by value-at-stake instead. For each capability, ask two things: what does it cost you to leave it on legacy (incidents, manual workarounds, blocked launches, compliance exposure), and what does modernizing it unlock (a new revenue line, a real-time feed an AI workload needs, a partner integration sales keeps losing deals over). The order rarely matches age.

It also front-loads the proof. A modernization that shows value in month three buys the runway to finish; one that spends its first year on invisible plumbing gets cancelled.

Keeping data consistent during the transition

The hardest part of any strangler-fig migration is not the code. It is that for a while, two systems are authoritative for overlapping data and they must agree. Patterns that work:

• One writer per data domain at any given time. Never let both old and new systems accept writes for the same records, or you inherit reconciliation conflicts that are brutal to debug.
• Use change data capture to keep the follower in sync. Stream changes from the system of record to the other so reads stay consistent wherever they land, instead of fragile two-way sync.
• Run the new path in shadow mode first. Send it real traffic, compare its output against the legacy result, log every divergence, but keep serving the legacy answer. You find discrepancies under production conditions without users ever seeing a wrong number.
• Treat historical-data migration as its own track. Live routing and back-filling years of history are different problems with different risk profiles.

Get this wrong and the failure is quiet: two slightly different numbers in two systems, found weeks later by an auditor. Trust evaporates faster than after an outage.

Mainframe realities, and the re-platforming trap

Mainframe modernization deserves its own caution. The strangler-fig pattern still applies, but the constraints are sharper. COBOL business logic is often the only surviving specification of how the company works, with no test suite and no author still employed. Batch windows are contractual. Throughput on a well-tuned mainframe is hard to match, so "it's old" does not mean "it's slow."

This is where the most expensive mistake hides: confusing migration with modernization. Lifting COBOL into a managed cloud emulator, or auto-translating it line-by-line into Java no human would ever write, changes the host but not the architecture. The batch dependencies, the data model, the coupling all survive the move, and you have spent a large budget to run the same constraints with a higher monthly bill. Wrapping the mainframe in REST APIs has the same flaw at smaller scale: the API makes the core reachable but does nothing to retire it. It is a fine first step as long as everyone understands the wrapper is scaffolding, not the destination.

Real mainframe modernization means moving capabilities off the platform and rebuilding them around the data the business runs today. It is slower and harder, and the only version that actually frees you from the platform.

How DNA approaches it

We run legacy modernization as a sequence of small, reversible, production-validated steps, not a rewrite you bet the year on: a routing layer and an anti-corruption boundary from day one, sequencing by value-at-stake, and a data-consistency plan that keeps old and new honest throughout. We have done this on insurance cores, billing and tolling platforms, and mainframe-anchored stacks, and we are blunt about the timelines it takes. If you are staring at a core system everyone is afraid to touch, tell us what it is and we will map the first three capabilities worth moving.