Every engineering leadership team eventually faces the same conversation. The system works, barely, but adding anything new takes twice as long as it should. The original developers are gone. The documentation describes what the system was supposed to do in 2014, not what it actually does today. And somewhere in the codebase there is a 4,000-line file that nobody wants to touch because the last time someone tried, three things broke that were not obviously connected.
The instinct at this point is to rewrite. Start fresh. Do it properly this time. The problem is that rewrites are among the most reliably expensive and frequently failed projects in software engineering. Not because the idea is wrong, but because the cost drivers are systematically underestimated, the timeline assumptions are optimistic, and the embedded knowledge in the old system is invisible until you try to replicate it.
This post breaks down what modernization actually costs across three approaches — incremental refactoring, strangler fig migration, and full rewrite — and explains when each is the right call and when it is not.
Three Approaches and What Separates Them
The decision between refactoring, strangler fig, and full rewrite is not primarily a technical question. It is a question about risk tolerance, team capacity, and how much of the existing system is still correctly encoding business rules versus how much is just cruft.
Incremental refactoring improves the existing codebase without replacing it. You break apart the 4,000-line file. You add tests to code that has none. You replace a synchronous blocking call with an asynchronous one. The system stays running throughout. Business continuity is preserved. The downside is that you are working inside the existing architecture, which means you cannot fix structural problems that require tearing something down and rebuilding it.
The strangler fig pattern builds the new system alongside the old one. New functionality is built in the new system. Old functionality is migrated piece by piece as it is rebuilt. At some point, the old system is handling nothing and can be decommissioned. The name comes from the strangler fig tree, which grows around an existing tree until it replaces it entirely. This pattern is slower than a full rewrite but dramatically de-risks the migration: the old system stays in production and handles traffic while the new system is proven incrementally.
Full rewrite shuts down development of the old system and builds the new one from scratch, with an intended cutover date. The old system stays in production until the rewrite is ready, but there is a defined end state where the switch is flipped. This approach is only appropriate in a narrow set of circumstances, which we will come back to.
Cost Table: Scope by Approach
The cost ranges below assume mid-market engineering rates ($125–$175/hour for senior engineers, $85–$120/hour for mid-level). They include engineering, QA, and project management but exclude infrastructure cost during parallel running periods, which is addressed separately.
| Scope | Incremental Refactor | Strangler Fig | Full Rewrite |
|---|---|---|---|
| Single module or service 10,000–30,000 LOC |
$15,000–$40,000 | $25,000–$60,000 | $30,000–$80,000 |
| Medium monolith 50,000–150,000 LOC |
$60,000–$150,000 | $120,000–$350,000 | $200,000–$600,000 |
| Large legacy system 200,000+ LOC, 10+ integrations |
$150,000–$400,000 | $400,000–$1,200,000 | $600,000–$2,000,000+ |
| Critical data pipeline ETL, reporting, financial calculations |
$40,000–$120,000 | $80,000–$250,000 | $120,000–$400,000 |
The upper bounds on full rewrite cost are not theoretical. They reflect what happens when a project hits the combination of parallel running period overrun, scope growth as the team discovers undocumented requirements in the old system, and the cost of keeping two systems aligned while one is in production and one is in development. Projects that budget for the lower bound and land at the upper bound are common. Projects that budget for the upper bound and come in under it are rare but not impossible when the scope is well-defined and the domain knowledge is intact.
Hidden Cost Driver 1: Domain Knowledge Loss
The most underestimated cost in any legacy modernization project is the time spent reconstructing knowledge that used to live in someone's head. The original developer understood why the validation rule has that specific edge case. They knew which downstream system sends data in a non-standard format and why the parser has a special handling branch. They remembered the 2019 incident that caused them to add the retry logic with that specific timeout.
When that developer is gone — and in legacy systems, they usually are — the new team has to reverse-engineer the intent from the behavior. This takes longer than writing new code. For every hour of development work in a legacy codebase with poor documentation, expect 30 to 60 minutes of archaeology: reading old commits, tracing data flows, running the system and observing what it does rather than what the documentation says it does.
In a full rewrite, this cost shows up as the team building the new system that passes all the written acceptance criteria but fails in production when it hits an edge case the old system handled silently. The fix cycle for these issues is expensive: they are discovered in production, diagnosed against two systems running in parallel, fixed in the new system, and then validated against the old system's behavior as the reference. Budget 20 to 30 percent of total engineering time on a full rewrite for this category of work. Most project estimates budget zero.
Hidden Cost Driver 2: The Parallel Running Period
Any modernization approach that keeps the old system in production while building the new one incurs a parallel running cost. This includes strangler fig migrations and full rewrites where the old system stays live until cutover. The parallel period generates cost in three ways.
Infrastructure doubling. Running two systems in parallel means paying for two sets of compute, two sets of databases, two monitoring setups, and two deployment pipelines. For systems with non-trivial infrastructure spend, this can add 20 to 40 percent to monthly operational cost for the duration of the migration. A strangler fig migration that runs 12 months on a system with $8,000/month in infrastructure costs adds $19,200 to $38,400 in infrastructure cost above what the estimate typically accounts for.
Change synchronization. While the rewrite is in progress, the business does not stop changing requirements. Every change that goes into the old system in production needs to be evaluated: does it need to be replicated in the new system? Does it change the migration order? Does it invalidate work already done in the new system? This synchronization overhead is real engineering time, typically 10 to 20 percent of the capacity of the team working on the old system.
Cutover complexity. The cutover from old to new is not a single switch flip. It is a process of routing traffic incrementally, monitoring for behavioral differences, handling rollback scenarios, and decommissioning the old system cleanly. Plan 4 to 8 weeks of focused effort for a medium-complexity cutover, separate from the migration work itself.
Hidden Cost Driver 3: Data Migration
Data migration is consistently the item that overruns most severely on legacy modernization projects. The reasons are structural: the old system's data model encodes years of ad hoc decisions, and the new system's data model is designed to be clean. The gap between them is filled by a migration script that has to handle every variation of the old data, including the invalid records, the null values where something was supposed to be not-null, and the duplicate records created by bugs in the old system that nobody fixed because users learned to work around them.
The data migration cost depends on three factors: data volume, data quality, and schema divergence. A migration with high volume but clean, well-structured data and modest schema changes can be done quickly with a well-tested ETL script. A migration with moderate volume but years of accumulated data quality problems and a completely new data model can take months.
Budget separately for data migration as a line item, not as part of the engineering estimate for feature development. Realistic ranges by system size:
- Simple schema changes, clean data: $8,000–$25,000
- Significant schema redesign, moderate data quality issues: $30,000–$80,000
- Major schema divergence, large volume, historical data quality problems: $100,000–$300,000+
The upper bound matters. Teams that discover their data migration is in the third category after budgeting for the first are facing a project-level problem, not a line-item overrun.
When to Refactor vs. Strangle vs. Rewrite
The decision framework is not about which approach is technically superior. It is about matching the approach to the actual problem.
Choose incremental refactoring when: The architecture is sound but the code quality is poor. The system can be improved by adding tests, breaking apart large files, and replacing deprecated patterns without needing to change what the system does architecturally. The team has domain knowledge and can work safely inside the existing codebase. Feature velocity is the primary problem, not the fundamental design.
Choose strangler fig when: The architecture needs to change but the system must stay in production. The team can identify discrete functional boundaries that can be migrated independently. The risk of a complete cutover is unacceptable because the system handles critical operations. The organization has the patience for an 18-month migration that delivers incremental improvements throughout rather than a big release at the end.
Choose full rewrite when: The existing system cannot be modified safely enough to execute a strangler fig. The technology is so obsolete that no current engineers can work in it effectively. The domain has changed enough that the old system's architecture is actively wrong for the current problem, not just outdated. And critically: when the team has the domain knowledge to specify what the new system needs to do, not just what the old system does.
When "Just Rewrite It" Is the Wrong Call
The full rewrite is the wrong call more often than engineering teams want to admit. There are three situations where it sounds right but leads to failure.
When the domain knowledge is gone. If the people who built the old system are no longer available and the documentation is incomplete, a rewrite team is building a new system whose correctness they cannot fully verify. They will build what the users and product managers tell them the system should do, which is not the same as what the system actually does after years of edge case handling and incident-driven patches. The new system will have a clean codebase and a different set of bugs.
When the old system is the specification. In systems with complex business rules — insurance calculation engines, financial reporting systems, compliance-driven workflows — the old system is often the most complete specification of correct behavior that exists. Rewriting it requires either reverse-engineering every rule or accepting that the new system will behave differently. Neither outcome is cheap.
When the timeline is fixed. Full rewrites slip. The reasons vary, but the pattern is consistent: the parallel running period takes longer than planned, the scope of undocumented requirements exceeds expectations, and the cutover reveals behavioral differences that require additional reconciliation cycles. If the business is counting on the new system being in production by a specific date, a full rewrite is the approach with the least margin for the variance that will actually occur.
How to Scope a Modernization Estimate
The most reliable way to scope a legacy modernization project is to run a discovery sprint before committing to a project estimate. A two to four week audit by engineers who will do the work produces a dramatically more accurate estimate than one built from a requirements document.
The audit should produce: a count of external integrations and their documentation quality, an assessment of test coverage and what it actually covers, a map of the high-churn files in git history (these are where the complexity is, regardless of size), an inventory of the business rules that are encoded in code but not in documentation, and an assessment of data quality against the intended schema.
The output of the audit is a project estimate with a scope statement. Without the audit, the estimate is a guess. With it, the estimate is still imprecise, but the sources of variance are at least visible rather than hidden.
Frequently Asked Questions
How long does legacy code modernization take?
Timeline depends on scope and approach. Targeted refactoring of a single module takes 4 to 12 weeks. A strangler fig migration of a medium-sized monolith runs 6 to 18 months. A full rewrite of a system with 200,000 or more lines of code rarely finishes under 18 months, and commonly runs 24 to 36 months when you include the parallel running period, data migration, and integration testing. Budget the longest credible estimate plus 25 to 40 percent contingency for scope discovered mid-project. Projects that budget for the optimistic case almost always overrun.
What is the risk of a big bang rewrite?
The primary risk is that the rewrite team re-encodes bugs and business rules from the old system without knowing it. Legacy systems accumulate years of implicit business logic in edge case handling, undocumented validations, and workarounds that no specification covers. A rewrite that ignores this embedded knowledge ships a system that handles the happy path correctly but fails on edge cases the old system handled silently. The second risk is the parallel running period: while the rewrite is in progress, the old system accumulates new changes, and the rewrite team is always chasing a moving target. Projects that underestimate this frequently find the rewrite is functionally complete but perpetually six months from production because the old system keeps generating new requirements.
How do you estimate legacy code modernization cost?
Start with a codebase audit: measure lines of code, count external integrations, identify undocumented business logic concentration points using git history, and assess test coverage. Then map the intended approach. Multiply estimated engineering effort by 1.5 to 2x to account for discovery work, parallel running period, and data migration, which together consistently consume more time than teams budget. For a strangler fig, add infrastructure cost for running two systems in parallel: typically 20 to 40 percent of monthly infrastructure spend per month of migration. Run a two to four week discovery sprint before committing to a full project estimate — it produces a far more defensible number than an estimate made from a specification document.
Talk Through Your Modernization Decision
If you are staring at a legacy system and trying to decide whether to refactor, migrate, or rewrite — or if you have already started and the cost is tracking above what you expected — a short conversation can help you identify where the overrun is coming from and whether the current approach is the right one. Bring the scope, the current estimate, and a description of the problem, and I will tell you what I see.
