Legacy System Modernization Without a Rewrite

Why do big-bang rewrites derail legacy system modernization?

A big-bang rewrite defers every benefit to one cutover date while the business keeps changing underneath it. Large IT programmes already overrun more often than not, and a rewrite concentrates that risk into a single release.

What does the public data say?

McKinsey and the University of Oxford studied 5,400 large IT projects in 2012 and found an average of 45% over budget, 7% over schedule and 56% less value delivered than predicted. That study covers big IT programmes in general, not only rewrites, so treat it as a base rate rather than a rewrite failure rate.

The 56% is the figure worth dwelling on. Budget overruns get noticed. Value shortfalls arrive quietly, as behaviour the old system had that nobody wrote down.

Why does the risk pile up at cutover?

A rewrite has to reach feature parity before any user benefits, and parity is a moving target. The old system keeps receiving patches and regulatory changes while the new one is built, so the gap never closes on schedule.

Data is the second trap. A one-shot migration of years of records, with every quirk the old schema tolerated, is rehearsed less often than it should be. Rollback after cutover is usually impossible, because the new system has already accepted writes.

What is actually load-bearing in your legacy system?

Load-bearing means the behaviour, data and integrations the business depends on and nobody can fully describe. Find them by observing the running system, not by reading documentation written years ago.

How do you map runtime behaviour?

Instrument before you plan. Read access logs to see which endpoints are called, database query logs to see which tables are read and written, and the scheduler to see every batch job.

You will usually find endpoints with no traffic in a quarter. You will also find an overnight job nobody owns that finance reads every morning. The second kind is what breaks a rewrite.

A practical check is to keep the logs running for at least one full month-end and, if the business has one, a quarter-end or year-end close. Some behaviour fires only then: a reconciliation export, a tax calculation, a statement run. A two-week sample will mark these as dead code, and they are exactly the paths that cause an incident after the old system is switched off.

How do you classify what you find?

Sort each capability into one of the migration strategies in the AWS Prescriptive Guidance, which lists retain, retire, rehost, replatform, repurchase, refactor and relocate. Retire and retain are the cheapest outcomes, and a surprising share of an old system qualifies for one of them.

Then capture characterisation tests: record real inputs and outputs from the legacy system and replay them against the replacement. That gives you an oracle for parity, and it is the main job of QA and testing in a migration.

How does the strangler pattern work in practice?

The strangler fig pattern puts a routing facade in front of the legacy system, moves one capability at a time behind it, and retires old code once it receives no traffic. Microsoft Learn and AWS Prescriptive Guidance both document it.

What do the facade and routing rules look like?

The facade can be a reverse proxy, an API gateway or a routing layer inside the application. Routing rules decide who reaches the new code: by path, by tenant, by user cohort or by percentage.

A sequence that works is shadow traffic first, where requests are mirrored and responses compared without being served. Then a small canary, then full traffic. A feature flag gives you rollback in minutes rather than a redeploy.

Shadow comparison needs a tolerance rule agreed in advance. Timestamps, generated IDs and rounding will differ between systems even when both are correct, so decide which fields are ignored and which must match exactly. Otherwise the diff report fills with noise and the team stops reading it.

Where does the pattern cost you?

The facade is a new single point of failure and an extra network hop. You run two systems for the whole migration, with shared authentication and session handling between them.

Put an anti-corruption layer between old and new, as Microsoft's architecture guidance describes. Without it, the new code inherits the legacy data model and you have moved the mess rather than removed it.

The pattern also fails when there is no seam. If business logic lives in stored procedures that every module calls directly, there is nowhere to intercept.

Which module should you migrate first?

Pick a module with a clear boundary, genuine business pain and a small blast radius. The first slice exists to prove your routing, testing and deployment pipeline, so it should not be the biggest prize.

How do you score candidates?

Score each candidate on three axes:

• Coupling: how many tables and callers it touches. Fewer is better for the first slice.
• Change frequency: version control history shows which modules are edited constantly. Those hurt most and repay migration fastest.
• Blast radius: what breaks, and for whom, if it fails. Start where the answer is "an internal report".

Why should the first slice be boring?

Read-only capabilities such as reporting, search, catalogue browsing and notifications make good first slices. They carry no write-consistency problem, so you learn the pipeline without risking data.

Where the replacement is a net-new capability rather than a port, a fixed-scope Moonship MVP, a working product in 30 days, can serve as the first slice behind the facade. Writes and money-moving flows come last, once the pipeline has survived real traffic.

How do you keep both systems in sync during cutover?

Name exactly one system of record per data entity at every moment, and replicate changes one way from it. Dual writes without that rule drift apart, and the drift surfaces as customer-facing bugs.

Why does one writer per entity matter?

Ownership moves in steps. First the legacy system owns an entity and the new service reads a replica. Then you flip ownership for that entity, and the legacy system reads the replica.

Writing to both stores from application code fails partially: one write succeeds, the other times out, and there is no transaction spanning them. You then have two versions of the truth and no rule for which wins.

How do you replicate safely?

Change data capture reads the database transaction log and publishes changes without touching application code. SQL Server's documentation on change data capture describes the mechanism, and similar features exist in other databases. For events your own code emits, the outbox pattern gives the same guarantee.

Add a nightly reconciliation job that compares row counts and checksums per entity, and fails loudly. This is data engineering work, and it is the part teams skip. Keep reverse replication running for a rollback window after each flip.

What does legacy system modernization cost, and how long does it take, by system size?

Cost and duration track capabilities, coupling, integrations and data quality, not lines of code. No credible public benchmark gives a price or duration per system size, and Viithiisys does not publish figures it cannot stand behind.

What drives scope at each size?

How should you read the cost curve?

Cost rises faster than size because coupling compounds. Two modules sharing a table are not twice as hard as one; they are a negotiation over who owns the table.

You also pay to run both systems until the last slice retires, so a stalled migration is the expensive outcome. Viithiisys's system modernisation service starts with an inventory like the one above, and moves to cloud migration only where hosting is part of the problem.

When is a rewrite the right call?

A rewrite is justified when no seam exists to intercept traffic, when the platform cannot be supported or hosted, or when the system is small enough that a facade costs more than the rewrite.

What are the real signals?

• The runtime or platform is out of support and cannot be migrated in place.
• Logic sits inside the database or a monolithic binary with no interface to route at.
• The system is small, so the facade and sync machinery cost more than the port.
• The underlying business process is being replaced, so porting its behaviour preserves what nobody wants.

How do you rewrite without the big bang?

Even then, deliver in time-boxed slices with a parallel run, comparing outputs from old and new on live inputs before anyone switches over. Fix the scope of each slice and hold it.

The call between rewrite and strangle is a senior judgement, not a template. Viithiisys has shipped software since 2007 from Mohali in the Chandigarh tricity and an office in Markham, Ontario, with 500+ projects across six countries for clients including Paytm, Snapdeal, IKEA and Shiprocket. Where a team lacks that judgement in-house, CTO-as-a-Service supplies it on a fractional basis, and the case studies show how past work was sequenced. To get your own system inventoried and ranked, book a modernisation assessment.