In 2026, the most common mistake companies make when evaluating legacy system modernization is treating "rewrite" as the only option. In practice, there are at least four distinct paths — rewrite, refactor, API-based integration, and replace — with cost and timeline differing by several times over. A small-to-mid-sized API integration project might cost USD 16k-50k and take 6 to 12 weeks, while a full rewrite of a similarly sized system might run USD 50k-160k and take 4 to 9 months. According to McKinsey's research on technical debt, the tipping point where rebuilding starts to outweigh continued patching is roughly when a division's technical debt exceeds 50% of its technology asset value. This guide walks through a comparison of the four strategies and a decision matrix mapped to common system symptoms.
A quick note on how to read the ranges in this guide: they reflect the spread we actually see across mid-sized projects, not one "typical" price. The low end usually describes a system with clean requirements and modest integration needs; the high end reflects heavier legacy dependencies, larger data volumes, or compliance review cycles. Treat the midpoint as a planning anchor, not a quote — your own number will likely sit toward the high end if the system passed through several teams with inconsistent documentation.
The four common paths for legacy system modernization
Before deciding what to do with a legacy system, it helps to know what your actual options are — most teams jump straight to "rewrite," which happens to be the highest-cost, highest-risk option and usually shouldn't be the default.
| Strategy | Definition | Typical cost range (mid-sized system) | Risk | Typical timeline |
|---|---|---|---|---|
| Rewrite | Tear it down and rebuild on a new architecture and stack | Based on our 2026 project experience, roughly USD 50k-160k | Highest — easy to accidentally replicate hidden bugs from the old system, and timelines slip most often here | 4-9 months |
| Refactor | Keep the core logic, restructure the internals incrementally | Typically 30-50% lower than a rewrite | Medium — needs solid test coverage to guarantee behavior doesn't change | Can be phased by module, 4-8 weeks per phase |
| API integration / wrap | Leave the legacy core untouched, add an interface layer so new systems can talk to it | Roughly USD 16k-50k | Medium-low, but the legacy system's underlying debt still isn't resolved | 6-12 weeks |
| Replace | Buy or adopt an off-the-shelf system (ERP, CRM, SaaS) instead | Roughly USD 32k to several hundred thousand, depending on complexity | Medium — data migration and process change are the most commonly underestimated costs | 3-6+ months |
These four paths aren't mutually exclusive, and picking one doesn't mean living with it until the system is decommissioned. Most companies' modernization path shifts as symptoms change — start with API integration to solve an immediate connectivity problem, then revisit in a few months to decide whether deeper refactoring is worth it. What should drive the choice is the system's current stability and debt severity, not which stack looks most appealing to build in; defaulting to a rewrite is often more about a team wanting a reason to use new tools than about the system's actual condition.
When should you rewrite?
A rewrite makes sense in three situations: the vendor or open-source community has stopped supporting the system, you can no longer find engineers willing or able to maintain it, or technical debt has gotten severe enough that patching costs more than rebuilding. These three signals usually show up together — the tech stack is running an outdated version, documentation is thin, and only a couple of senior engineers who "understand this system" are willing to touch it. If that's your situation, continued patching just compounds the risk over time. A rewrite costs more upfront, but it's usually the more stable long-term choice once you're in this state.
A rewrite done badly is also its own kind of risk. The most common failure mode we see is a team rebuilding the system from a fresh architecture but copying the old system's business logic line by line, including workarounds that were only ever meant to patch a since-fixed upstream problem. The new system ends up just as tangled as the old one, except now it's tangled in an unfamiliar codebase with no institutional memory of why any of it is there. A rewrite is only worth its cost if it comes with an honest audit of which rules are actual business logic and which are historical accidents nobody has questioned in years.
When should you use API integration instead?
If the legacy system itself is still stable and its core functionality isn't the problem — it just can't connect externally, for example to a newly deployed AI agent, a mobile app, or a third-party service — API integration is usually the highest-return option. It leaves the legacy core untouched and adds a layer that lets new systems safely read and write its data, at a fraction of the risk and cost of a rewrite. The downside: the legacy system's underlying technical debt isn't actually resolved, just wrapped. If the core logic itself starts breaking down later, you'll eventually still face the refactor-or-rewrite decision.
The main execution risk with API integration isn't the legacy system — it's the interface layer you're adding on top of it. A poorly designed wrapper becomes a second layer of debt if it starts encoding business logic instead of staying a thin pass-through. Budget time for load-testing under realistic traffic, not just functional testing: legacy databases were rarely designed for the query patterns a modern AI agent will throw at them, and that mismatch tends to surface under real usage.
How serious is your technical debt, really?
McKinsey's CIO survey found that 10-20% of the technology budget allocated to new products gets diverted to resolving technical-debt issues, and CIOs estimated that technical debt amounts to 20-40% of the value of their entire technology estate before depreciation, with 60% saying their debt had visibly increased over the prior three years. McKinsey also offers a simple diagnostic: if more than half of a company's IT project budget goes to system integration and legacy patching rather than new feature development, that's a sign the company is stuck in a "tech-debt spiral" — paying interest without paying down principal. And when a division's technical debt exceeds 50% of its technology asset value, the cost-benefit case for rebuilding (effectively, a rewrite or replace) starts to outweigh continued maintenance. That 50% threshold is a useful rule of thumb for deciding whether to patch or rebuild.
In practice, you don't need a full audit to get a working answer. Ask the engineering team a few direct questions: how many hours this quarter went to patching versus building new functionality? Does every change to a given module still depend on the same one or two senior engineers? Have any core dependencies — framework, database version, third-party integrations — already lost official support? If most answers point the wrong way, debt is likely near or past the 50% threshold, and a rebuild evaluation is worth it.
The hybrid path: integrate first, then replace incrementally
In practice, few real projects cleanly pick just one strategy and stop there. Most mature modernization paths are combinations: use API integration first so the legacy system can talk to newer systems, buy time to evaluate which modules are worth refactoring and which have outlived their usefulness, then replace or rewrite module by module rather than tearing down the whole system at once. This is often called the "strangler pattern" — new systems gradually take over the legacy system's responsibilities until what remains is small enough to retire safely. The advantage of a hybrid approach is that risk is spread out and every phase produces something verifiable; the trade-off is that it demands more disciplined project planning, since letting the old and new systems coexist indefinitely just adds operational complexity of its own. For companies with high technical debt that can't tolerate extended downtime, a hybrid approach is usually more realistic than a single big-bang rewrite.
Sequencing matters once you commit to a hybrid path. Tackle lower-risk, high-external-dependency modules first — the ones that need to talk to an AI agent or a mobile front end, for example — with API integration, so you get a visible win early. Modules with complex internal logic but few external integration needs can wait for a later phase, once you have more information to weigh refactor against rewrite. The real risk in a hybrid strategy isn't picking the wrong module order — it's never setting a clear end condition, so old and new systems coexist indefinitely and end up costing more in combined operational overhead than a single rewrite would have.
The cost of waiting isn't zero, either
One factor that rarely shows up in a rewrite-vs-integrate spreadsheet is the ongoing cost of doing nothing. A legacy system that's merely inconvenient today tends to get more expensive to touch every quarter it goes unaddressed — the engineers who understand it retire or move on, the surrounding tech stack drifts further from anything current, and each new integration request piles more workaround logic onto a foundation nobody wants to disturb. In one case McKinsey documented, a global financial-services company that finally quantified this properly found that some of its business units carried up to 58% additional hidden cost in their IT total cost of ownership once the cost was actually made visible and measured, rather than left as an unexamined line item. That's a useful reminder that "leave it alone, it still works" is itself a decision with a cost, not a neutral default — it just defers the cost rather than avoiding it, and the deferred cost tends to compound.
That doesn't mean every legacy system needs immediate attention. A system with low technical debt, stable requirements, and no integration demands can reasonably be left alone for years. The point is to make that a deliberate choice based on an actual assessment, rather than the default outcome of never asking the question.
Worked example: a mid-sized manufacturing client
As a composite example based on patterns we've seen across similar engagements, not any single named client, consider an 80-person manufacturing company running a scheduling system that had managed production work orders for years. The system itself was stable and the original engineers were still on staff, but it had no external API, so it couldn't talk to a newly deployed AI scheduling assistant — someone exported a report manually every day and re-typed it into the new tool. Mapped against the decision matrix below, this is a textbook case of "stable system, no external connectivity," which points to API integration rather than a rewrite.
That's what the client did: an integration project landing within the ranges cited above (roughly USD 16k-50k, 6-12 weeks) that let the AI scheduling assistant read and write work-order data directly. After a few months confirmed the legacy core had no deeper problems, the client refactored just the one underperforming reporting module users complained about most, instead of rebuilding the whole system — solving the urgent problem first at a fraction of a full rewrite's cost.
Decision matrix: strategy by system symptom
| Symptom | Recommended strategy |
|---|---|
| Vendor or community support has ended; can't find engineers to maintain it | Rewrite or replace |
| Core logic still has value, but the codebase is fragile and every change is painful | Refactor |
| System runs stably but can't connect externally — no way to integrate with an AI agent or mobile app | API integration |
| A mature off-the-shelf product (ERP, CRM) can already replace the custom system | Replace |
| Estimated technical debt exceeds 50% of the system's asset value | Prioritize rewrite or replace |
| Only one specific feature is underperforming; the rest of the system works fine | Targeted refactor or API integration around that feature — skip the full rewrite |
Common mistakes and red flags
- Evaluating only "rewrite" without first checking whether refactoring or API integration would be sufficient
- Underestimating data migration and process-change costs, especially when evaluating a replacement with an off-the-shelf product
- Copying the old system's logic verbatim during a rewrite without first separating actual business rules from legacy workarounds that outlived their reason for existing
- Not budgeting enough test time for a refactor or rewrite, and discovering behavioral differences only after launch
- Leaving technical-debt prioritization entirely to the engineering team, without business stakeholders weighing in on what's actually worth rebuilding first
Next Steps
There's no single right answer for legacy system modernization — rewrite, refactor, API integration, and replace each fit different situations, and the key is honestly assessing your system's current technical debt and symptoms before defaulting to "rewrite." If you're evaluating what to do with a legacy system, see Noise & Signal's Industry Digital Transformation services for how we help companies diagnose technical debt and plan a modernization path. For a side-by-side view of process and pricing across our services, see our Process & Pricing page.