Legacy systems are simultaneously the most critical and most fragile components of most organizations' technology landscape. They run core business processes, contain decades of institutional knowledge embedded in their logic, and are understood by a shrinking pool of specialists. They are also slow, expensive to maintain, impossible to integrate with modern tools, and a growing security risk.
The temptation is a big-bang replacement: build the new system, flip the switch, decommission the old one. This approach has a catastrophic failure rate. A 2025 Standish Group report found that 67% of large-scale system replacement projects exceed their budget by more than 50%, and 28% are cancelled entirely. The organizations that succeed use incremental migration strategies that reduce risk and deliver value continuously.
Named after the tropical fig that gradually envelops and replaces its host tree, the strangler fig pattern is the safest approach to legacy system migration. Instead of replacing the old system all at once, you build new functionality alongside it and gradually redirect traffic and processes from old to new.
The pattern works in three steps. First, identify a specific business function handled by the legacy system that can be isolated. Second, build a modern replacement for that specific function. Third, route requests for that function to the new system while the legacy system continues to handle everything else. Repeat until the legacy system has no remaining functions and can be decommissioned.
The key architectural requirement is a routing layer (sometimes called a facade or proxy) that sits between users and both systems. This layer decides which system handles each request based on the migration status of each function. It also handles data synchronization between old and new systems during the transition period.
The strangler fig pattern typically takes 2-3x longer than a big-bang approach in total calendar time. But it delivers value from the first migrated function (usually within 3-4 months), maintains business continuity throughout, and has a dramatically lower risk of catastrophic failure.
Data migration is where legacy modernization projects most frequently derail. Legacy systems often contain data that is inconsistent, undocumented, or encoded in formats that no longer make sense. A customer record that has been modified by 15 different versions of the software over 20 years may contain fields that mean different things depending on when they were last updated.
Start with a comprehensive data audit. Map every table, field, and relationship in the legacy database. Identify data quality issues: null values where they should not exist, inconsistent formats (dates stored as strings in multiple formats), orphaned records, and duplicate entries. Quantify the scale of each issue -- a few hundred bad records can be fixed manually; a few hundred thousand require automated remediation.
Build a data transformation pipeline that cleans, normalizes, and migrates data in repeatable, testable batches. Never do a one-time data dump. Run the migration pipeline multiple times in a test environment, comparing source and destination data at each iteration. Only when the pipeline produces identical results across multiple consecutive runs should you execute it in production.
Data migration from legacy systems to a new system breaks in the same few places on almost every project. Work through these steps in order on any legacy database migration. Each step ends with a check that tells you it is done.
For mission-critical systems, parallel running is essential. Both old and new systems process the same transactions simultaneously, and automated reconciliation compares the outputs. Any discrepancy triggers an alert for investigation before the old system is decommissioned.
Parallel running adds cost and complexity, but it provides an invaluable safety net. The reconciliation process catches bugs, data migration errors, and business logic discrepancies that testing alone would miss. Plan for a minimum parallel running period of 30 days for non-critical functions and 90 days for critical functions like financial processing or customer-facing operations.
During parallel running, the old system remains the system of record. Users interact with the new system, but if a discrepancy is detected, the old system's output is used while the issue is investigated. Only when the new system has proven itself through sustained error-free parallel operation does it become the system of record and the old system is demoted to a backup role.
Legacy system migration is as much an organizational challenge as a technical one. The people who know the legacy system best are often the most resistant to replacing it -- they have built their expertise and sometimes their career identity around that system.
Involve legacy system experts from day one of the migration project. Their knowledge of business rules, edge cases, and workarounds is irreplaceable and cannot be extracted from documentation alone. Position them as essential contributors to the new system, not as defenders of the old one. Many of the most valuable insights about what the new system needs come from people who have spent years working around the old system's limitations.
Plan for a temporary productivity dip during migration. Users will be slower on the new system than on the old one for the first 2-4 weeks. Budget for this in your project timeline and communicate it explicitly to business stakeholders. The productivity dip is real but temporary -- within 6-8 weeks, most users report higher productivity on the new system than they had on the old one.
Not every legacy system migration should use the same playbook. The four approaches below trade speed against risk. For most business-critical systems the strangler fig pattern wins, but a low-risk internal tool can justify a faster route.
| Approach | Risk | Downtime | Relative cost | When to use |
|---|---|---|---|---|
| Big Bang | High | Hours to days at cutover | Lowest upfront, high if it fails | Small, well-understood systems you can afford to re-run |
| Strangler Fig | Low | None (gradual redirect) | Higher total, spread over time | Business-critical systems that must stay live |
| Parallel Run | Very low | None (both run at once) | Highest (two systems at once) | Financial or customer-facing systems where a wrong number is unacceptable |
| Phased / Modular | Medium | Brief per module | Moderate | Systems that split cleanly into independent modules |
A legacy system migration strategy can look sound on paper and still stall on one of these six mistakes.
Give a business owner the final sign-off on each migrated function. The people who run the process know which edge cases matter.
Every record you move has to be cleaned, mapped and reconciled. Agree a cutoff date, archive closed records older than it, and move only what the new system needs to run.
A 1,000-row sample hides the problems that live in record 400,000. Run every trial load on a full copy of production data.
Legacy systems carry business rules in code nobody has read in years. Before you build the replacement, list what the old system does with each input and test the new one against that list.
Set an exit rule, such as two full month-end closes with zero reconciliation differences, and keep both systems running until you meet it.
Keep it read-only for at least one full business cycle. Someone will ask for a record you did not migrate, and a read-only system answers that in minutes.
Budget between 15% and 40% of what a ground-up rebuild would cost. The split is rarely what the original estimate assumed. Licenses and infrastructure, the line most budgets are built around, come in near the bottom, while data work and the parallel-running period take the top two slots.
| Cost driver | Typical share of budget | What inflates it |
|---|---|---|
| Data extraction, cleaning and reconciliation | 30% to 40% | Undocumented schemas, duplicate records, years of ad hoc fixes |
| New platform build or configuration | 25% to 35% | Custom workflows the legacy system grew around |
| Parallel running | 10% to 20% | Every extra month of paying to run both systems |
| Integration rework | 10% to 15% | Downstream tools that read the legacy database directly |
| Training and change support | 5% to 10% | Staff who have used the same screens for a decade |
| Licenses and infrastructure | 5% to 10% | Rarely the surprise, and rarely the biggest number |
A 40-person distributor replacing a 2009 order management system budgeted 120,000 euro over nine months. The platform build landed close to plan at 38,000. Data was the overrun. Fourteen years of order history held 60,000 customer records that collapsed to 41,000 once duplicates were merged, and reconciling them took eleven weeks instead of four, at 52,000. Parallel running added 18,000 because finance would not sign off until two full month-end closes matched. Final spend was 141,000, seventeen percent over, and all of the overrun sat in the two lines the original budget treated as rounding errors.
Price the data work before the platform. If nobody can tell you how many records exist and how many of them are duplicates, you have a guess rather than a budget.
It depends on the approach and the size of the system. A big-bang replacement of a small tool can finish in weeks, while a strangler fig migration of a business-critical system usually runs 2 to 3 times longer in calendar time but delivers the first working function within 3 to 4 months. Most enterprise legacy system migrations run 12 to 24 months end to end.
Phased approaches like the strangler fig pattern are far safer for anything business-critical. Big-bang replacement flips the whole system at once, and a 2025 Standish Group report put the budget-overrun rate for large replacements at 67%. A phased legacy system migration keeps the old system running while you move one function at a time, so a problem never takes the whole business down.
Data. Legacy systems accumulate inconsistent, undocumented records over years, and a legacy system migration lives or dies on migrating that data cleanly. Audit and clean the data first, run the migration pipeline repeatedly in a test environment, and reconcile source against destination before any production cutover.
Inventory and profile the legacy data, map each field to the new schema, and write the cleansing rules into a repeatable pipeline. Run full trial loads on a copy of production, reconcile row counts, totals and checksums against the source, then sync the changes made during parallel running before the final cutover. The checklist above lists each stage and the check that closes it.
It is the plan for moving functions and data off the old system. It names the approach (big bang, strangler fig, parallel run or phased), the order in which functions move, how data stays in sync during the transition, and the result that lets you switch the old system off. For a business-critical system, a strangler fig or phased strategy with a parallel run on the riskiest functions keeps the old system serving customers until each new piece has proven itself.
Part of our complete guide: Digital Transformation →
This article is part of our comprehensive knowledge hub on digital transformation. Read the full guide for a complete strategic framework.
Our team helps companies implement the frameworks and strategies covered in this article.
Get in Touch