Legacy System Migration: Strangler Pattern, Risk Management and the 18-Month Plan

Big-bang rewrites kill companies. The strangler-fig pattern doesn't. Every successful legacy migration we've shipped at Alher Tech follows the same shape: incremental replacement, dual-running for a controlled period, reversible steps and continuous business value delivery. This guide is the 18-month playbook for replacing legacy COBOL, Java EE, .NET Framework or Oracle systems without downtime, including the risk management framework and what to expect realistically at each phase.

Why Big-Bang Rewrites Fail

The pattern is depressingly consistent: 18-month roadmap, scope grows, deadlines slip, business changes faster than the rewrite, day of cutover the new system has bugs the old didn't, productivity drops, executives panic, project gets canned at month 24. The company has spent $5-15M on something that didn't ship.

The strangler-fig pattern (Martin Fowler, 2004) doesn't suffer from this. It assumes the rewrite will be wrong somewhere, and makes every step reversible.

Incremental replacement, not full rewrite
Old and new run side by side for months
Each replaced module proves itself before the next starts
Business value visible every 90 days, not at month 24
Reversible at every step

The 18-Month Playbook

A typical legacy migration we run at Alher Tech, broken into phases:

Months 1-2: Discovery and risk inventory: Map every entry point to the legacy system, every external integration, every reporting flow. Identify the single biggest risk: usually data integrity, sometimes a third-party with a 1990s SOAP interface.
Months 2-3: Foundation: Build the platform: identity, audit, observability, deploy pipeline, the test environment that mirrors production. The first 3 months are often 'no visible progress', but every later month depends on this.
Months 3-6: First module replacement: Pick the module with the highest pain × lowest dependency complexity. Read-only mirror first, then dual-write, then cutover. Six months in, you have one production module and proof the pattern works.
Months 6-12: Modules 2-4: Pace accelerates. Each new module borrows infrastructure from the first. Business sees value quarterly. Old system shrinks, new system grows.
Months 12-18: Long tail and decommission: The last 20% of functionality is often 80% of the surprises: undocumented batch jobs, third-party integrations, edge cases business never told you about. Plan for it.
Months 18+: Operate and improve: Old system decommissioned. License savings start. New features ship at 3-5x the legacy velocity. The investment finally pays back.

The Risk Management Framework

Legacy migration is risk management more than engineering. The disciplines that matter:

Reversibility at every step: Every change must have a documented rollback. Feature flags everywhere. Dual-running long enough to catch slow-burn issues (month-end reports, year-end batches).
Data integrity verification: After every dual-write window, automated reconciliation: counts, sums, sample comparisons. Diffs investigated within 24 hours, not 'when we have time'.
Characterization tests: Before refactoring, write tests against the legacy system's actual behavior, bugs included. The new system must replicate behavior, not 'fix' it without explicit decision.
Communication cadence: Weekly status to operational stakeholders, monthly to executives, quarterly to board. Surprises kill migrations; transparent progress saves them.
Skin in the game: Engineers on call for what they ship. No 'throw it over the wall' between dev and ops. The team that wrote the new module owns its incidents.

Choosing the Right Module to Replace First

Highest license fee on the legacy system or third-party plugin, for the biggest immediate ROI
Most painful for the operational team: quick wins build credibility for the rest
Least integrated with other legacy modules, which minimizes coupling risk during the first migration
Reasonably stable scope. Don't pick a module that's actively being changed by the business
Auditable success criteria: you need to be able to declare victory and decommission

The first module is the proof of concept for the entire 18-month plan. Pick conservatively. The second and third modules are where you accelerate.

Cost Reality

Migration scope	Cost range	Timeline
Single module of a 5-module legacy	$200K – $600K	4 – 8 months
Mid-sized legacy system (10-15 modules)	$1.5M – $4M	12 – 24 months
Large legacy system (50+ modules, multiple subsystems)	$5M – $15M+	24 – 48 months
Legacy with third-party EDI / mainframe interfaces	+30-50% on top	+6-12 months

Costs include foundation work and parallel operation overhead, which are 30-40% of the total. License savings on the legacy side typically recover 40-70% of the migration cost over 5 years.

Common Mistakes

Big-bang despite swearing not to. Schedule pressure pushes teams into 'just one cutover at year-end'. It always backfires.
Underestimating data migration. Cleaning, mapping and validating decades of legacy data is often 30-40% of project cost. Always.
Ignoring undocumented batch jobs. The 4 AM cron job that nobody owns has been keeping a critical report alive for 10 years. Find it before cutover, not after.
Replacing functionality without business validation. The legacy system has a button that 3 users press once a quarter. Don't remove it without asking: it might be load-bearing.
Skipping characterization tests. Refactoring without tests against the existing behavior is how 'simplifying' a calculation breaks reporting six months later.
Not paying down the legacy. New modules borrow code from old, then everyone forgets. Decommission aggressively or you'll run both forever.

Strangler, Not Sledgehammer

Every legacy migration that succeeds is incremental. Every one that fails is big-bang. The teams that internalize this and design for reversibility ship; the ones that promise a single year-end cutover collapse.

If you're staring at a legacy system that's costing you $1M+/year and slowing every product decision, the path forward is real, but it doesn't look like a rewrite. It looks like a strangler fig.

Frequently asked questions

How long does a legacy migration take?

Single module: 4-8 months. Mid-sized system: 12-24 months. Large system: 2-4 years. Strangler-pattern lets you ship value every 3-6 months along the way, not 'at the end'.

Do I have to migrate everything?

No. Some legacy modules will outlive the migration project. The right answer is to migrate what's painful or expensive, and leave stable, low-friction modules alone until they break or get replaced for other reasons.

What about data migration?

Always 30-40% of project cost on systems older than 10 years. Plan for cleaning, mapping, validation and dual-running. Don't underestimate.

Can we do this with our internal team?

Yes if your team has migration experience. Most don't. The mistakes are expensive enough that bringing in a partner for at least the first 2-3 modules pays back. Knowledge transfer makes the rest doable in-house.

What's the right modern stack?

Depends on the legacy. Java EE → Spring Boot. .NET Framework → .NET 8/9. Oracle Forms → React + REST APIs. COBOL → Java or Python with a deliberate translation layer. Don't pick by hype. Pick by team's hireability and operational maturity.