TL;DR: For most legacy software owners, "rewrite" is the wrong instinct. A rescue — reading the existing code, documenting it, and repairing what actually fails — is cheaper, faster, and lower-risk than a rewrite in the vast majority of cases. The rewrite decision hinges on six specific factors: business criticality, size of the codebase, quality of what exists, cost of downtime, availability of the original developer, and the honest state of your industry knowledge. This article walks through each factor, gives thresholds that flip the answer, and shows the actual cost math behind each choice.
Want a fast triage first? Try the interactive calculator — six questions, two minutes, no email. Or read on for the full framework.
Why this framework exists
If your business runs on software built between 1998 and 2012, someone has probably told you the system needs to be rewritten. That someone is usually well-meaning: a developer you hired last year, a vendor pitching a new platform, a board member who read something in an airport bookstore. The advice sounds responsible. It also almost always leads to a project that costs three to five times the initial quote, runs eighteen months longer than planned, and ships a system that does 70% of what the old one did while the business waits.
We have watched this pattern play out roughly 500 times in 26 years. The pattern is so consistent that the industry has a name for it — the failed migration case. In that engagement, a healthcare company paid $180,000 to a specialist consultancy to rewrite a Classic ASP system into modern .NET. Eighteen months later, nothing was working. We took over the project and delivered a complete, tested system in four months at a fraction of the remaining budget. The lesson generalizes: the rewrite was not the wrong destination — it was the wrong first move.
The right first move for a legacy system is almost always a rescue — an engagement that reads the existing code, produces a written assessment of what it actually does, and then performs targeted repairs or incremental modernization. Not a rewrite. Rewrites are the exception, and this article gives you the exception criteria.
Book a free 30-minute consultation if you want to skip to a specific answer for your situation. What follows is the general framework.
The six factors
There are six factors that determine whether a system should be rescued or rewritten. No single factor is decisive. All six need to be weighed together, and one of the biggest sources of bad decisions is treating any one factor as the whole answer.
Factor 1 — Business criticality
Definition: what happens to the business if the system stops working for one day, one week, one month?
If the answer is "we cannot ship orders," "we cannot bill patients," or "we cannot report to the regulator," the system is business-critical. Business-critical systems are the worst candidates for rewrites, not the best ones. This is counterintuitive. Most owners assume critical systems deserve the "quality" of a rewrite. The evidence says the opposite: critical systems cannot tolerate an eighteen-month period where the old system is being decommissioned while the new one is being validated. The failure mode is not "the new system doesn't work" — it is "we are running both systems simultaneously for a year, half our data is in one, half is in the other, and every reconciliation surfaces a bug."
Rescue if: the system is business-critical AND currently running. Rewrite if: the system is business-critical AND has already stopped working reliably AND a rescue would still not stabilize it. This is rare.
Factor 2 — Size of the codebase
Definition: roughly how many lines of code, how many modules, how many database tables? Any competent developer can eyeball this in an afternoon.
Small systems (under ~50,000 lines of code) are cheap enough to rewrite that the decision is often not about cost but about whether the original business logic is well-understood. If it is, a rewrite may be viable. If it isn't, even a small system is a rescue candidate — a rewrite of undocumented small code produces a new small system that reproduces different bugs.
Medium systems (roughly 50,000 to 250,000 lines) sit in the danger zone. This is where rewrites usually fail. The code is too large to hold in one person's head, but small enough that a project manager can convince a board it's "just a few months." It is not a few months. It is typically 18 to 36 months, and the last 40% of the work is discovering business rules that were never documented.
Large systems (250,000+ lines) are rewrite-immune. Nobody rewrites 250,000+ lines successfully. What they do is rewrite it in phases over five to ten years, with the old system running the whole time. That is not a rewrite — that is a modernization. Which is a rescue's larger cousin.
Rescue if: codebase is medium or large. Rewrite if: codebase is small AND business logic is well-understood.
Factor 3 — Quality of what exists
Definition: how much of the current system actually works? What percentage of the user-visible functionality is not broken?
Legacy software owners tend to over-estimate the brokenness. When a system frustrates people daily, the frustration is emotionally proximate. When the system successfully processes millions of transactions per year in the background, the successes are invisible. Ask "what percentage of what the system does actually works?" and the honest answer is usually 80 to 95 percent. Ask "how much of it drives you crazy?" and the answer is 100%.
Rewrites throw away the 80-95% that works and rebuild it from scratch, alongside fixing the 5-20% that doesn't. Rescues fix the 5-20% and leave the rest alone. The math is straightforward: rescuing 5-20% of a codebase costs 5-20% as much as rewriting the whole thing. In practice it costs less than that, because the parts that work are the parts developers don't need to think about.
Rescue if: 70% or more of the system works. Rewrite if: less than 30% of the system works AND the working parts are genuinely worthless to rebuild.
The threshold is not 50%. It is closer to 30%. That is because even a system that "only" works 30% of the time is doing 30% of a business's work — and reproducing that 30% during a rewrite is expensive and error-prone.
Factor 4 — Cost of downtime
Definition: what does one hour, one day, one week of the system being down cost the business?
If downtime cost is negligible (an internal tool used weekly by three people), the decision matrix is different from a system where an hour of downtime costs $10,000 in lost transactions.
High-downtime-cost systems must run continuously. Rewrites force downtime — either during cutover, or during the parallel-run period where both systems are live and reconciliation problems eat everyone's Tuesday. Rescues run in the background and preserve uptime.
The rewrite math changes if the current system already has significant downtime. If it crashes weekly and costs $10K per crash, the annual downtime cost is $500K. A rewrite that eliminates the downtime pays for itself in one year at $500K, but only if the rewrite ships on time and the new system doesn't introduce its own downtime. It usually doesn't ship on time. It usually does introduce its own downtime.
A rescue that stabilizes the failing 5% (see Factor 3) typically eliminates 80% of the downtime for 10-20% of the rewrite cost.
Rescue if: downtime cost is significant AND current downtime is caused by a small number of identifiable issues. Rewrite if: downtime is spread across so many modules that stabilization would require touching most of the codebase — at which point rescue and rewrite converge.
Factor 5 — Availability of the original developer (or their documentation)
Definition: does anyone alive know why the system was built this way?
This is the single most under-considered factor. Every legacy system has business logic embedded in the code that nobody wrote down. The night job runs at 2:47 a.m. because someone in 2007 discovered that at 2:45 a.m. the payment gateway was still processing weekend batch settlements. The report has that specific format because in 2011 a compliance officer required it. The database column customer_type has values 1 through 7 because in 2004 there were seven customer types, three have merged since, but the code still expects seven codes to be present.
If the original developer is available (even part-time), rescue is straightforward. Rewrites are also cheaper because the developer can transfer knowledge to the new team.
If the original developer is unavailable, rescue is more important, not less. You need someone to read the code and document it before any decision can be made responsibly. This is exactly what we describe in What to Do When Your Software Vendor Disappears.
The mistake is assuming that unavailability of the developer justifies a rewrite. It does not. It means you have less information about what the current system does, and rebuilding from an information-poor position is the worst basis for a project.
Rescue if: original developer is available OR original developer is unavailable AND you have not yet done a code-archaeology assessment. Rewrite if: original developer is unavailable AND you have done a thorough assessment AND the assessment concluded that documenting-then-repairing costs more than rebuilding.
That last condition almost never applies. We have not encountered it in 500+ engagements.
Factor 6 — Honest state of your industry knowledge
Definition: how much has the business changed since the software was written? Are the underlying processes the software encodes still the ones the business runs today?
Some businesses change slowly. Manufacturing, healthcare, and enterprise back-offices tend to evolve in stable directions — the software may be old, but what the business does hasn't fundamentally changed since 2005.
Other businesses change faster. Consumer-facing e-commerce, fintech, and some marketing software may have shifted so significantly that the underlying processes are no longer the ones the software was built to serve. In those cases, the software's business logic itself is stale, not just the technology stack.
If the business logic is stale, a rewrite becomes more defensible — you are not just rebuilding the technology, you are rebuilding a system that matches the current business. If the business logic is stable, a rewrite mostly re-invents the same wheel in a newer language.
Rescue if: the business processes the software encodes are still the ones the business runs. Rewrite if: the business has fundamentally changed AND the current system's business logic is genuinely obsolete AND documenting-then-modernizing cannot bridge the gap.
Most legacy-software businesses are in the "processes stable" bucket. If yours isn't, that's a signal worth taking seriously — but it's still one factor among six.
The framework applied
Here is the decision procedure. Answer each factor with your best current understanding, then use the aggregate to decide.
Rescue signals (each rescue point +1)
- System is business-critical AND currently running
- Codebase is medium or large (50K+ lines)
- 70% or more of the system works
- Downtime cost is caused by a small number of identifiable issues
- Original developer is available OR you have not yet done an assessment
- Business processes are stable
Rewrite signals (each rewrite point +1)
- System is small AND business logic is well-understood
- Less than 30% of the system works AND the working parts are worthless to rebuild
- Downtime is spread across most of the codebase
- Original developer is unavailable AND a thorough assessment shows rebuild is cheaper
- The business has fundamentally changed AND current logic is genuinely obsolete
Score interpretation
- 5-6 rescue points, 0-1 rewrite points: Rescue. This is the modal answer.
- 3-4 rescue points, 2-3 rewrite points: Rescue first, keep rewrite as a longer-term option. Do the rescue assessment before committing either direction.
- 0-2 rescue points, 4-5 rewrite points: Rewrite is defensible, but do the assessment anyway. Rewrites without an assessment fail at very high rates.
Any combination with rewrite points ≥ rescue points: the assessment is still the correct first step. It's cheap ($15K-25K in most engagements), fast (2-6 weeks), and gives you information you did not have when choosing between the two paths.
Book a free 30-minute consultation to talk through your specific factor answers.
The cost math
Framework-thinking is only useful if it maps to dollars. Here is the honest cost comparison for a representative engagement — a mid-sized business system on a legacy stack:
Rescue engagement:
- Assessment: $15K-25K, 2-6 weeks
- Targeted repair or incremental modernization: $40K-150K, 2-6 months
- Ongoing support (optional): $2K-8K per month
- Total first-year cost: $60K-200K
- Business disruption: minimal (targeted work on failing modules)
- Time to first measurable improvement: weeks
Rewrite engagement:
- Discovery + design: $30K-80K, 2-4 months
- Development: $200K-800K, 12-24 months
- Data migration + parallel run: $50K-150K, 3-6 months
- Total first-year cost: $280K-1M
- Business disruption: significant (parallel-run reconciliation issues)
- Time to first measurable improvement: 12-24 months (or never, if the rewrite is one of the ~40% that never ships)
Modernization engagement (rescue's larger cousin, applied to large systems):
- Assessment: $25K-40K
- Phased modernization over 12-36 months: $150K-500K over the period
- Total year-one cost: $100K-250K
- Total three-year cost: $250K-750K
- Business disruption: none (old system runs the whole time)
- Time to first measurable improvement: weeks (first phase) with continuous improvement thereafter
The disparity is not subtle. Rescues are typically 4-10x cheaper than rewrites for equivalent outcomes. This is not us marking up rewrites and marking down rescues — it is the observable industry pattern. Our modernization service is built around the third row of that table because the third row is the correct answer for most engagements.
Common objections
There are five objections owners raise when we explain this framework. All five deserve honest treatment.
"But the system is really old"
Age is not brokenness. FoxPro applications built in 1998 still process warehouse transactions correctly today when the code is well-maintained. The oldest system we have in an active support engagement was written in 1995. Its business logic has been read, documented, and adjusted six times since. It runs. Age is a proxy for risk, not a diagnosis of failure.
"But nobody knows the technology anymore"
The market for FoxPro developers is smaller than the market for React developers, yes. But smaller is not zero, and the market for "developers who can read legacy code" is close to zero — which is why the ones who can charge premium rates. That is a problem for the customer only if the customer requires 24/7 in-house coverage on a stack nobody else touches. Most rescue engagements involve one specialist for weeks-to-months, not a permanent hire.
Rewrites into modern stacks solve this problem — at 4-10x the cost of a rescue plus the risk of the rewrite itself. If you can afford it and the risk is worth it, fine. Most owners cannot.
"But the vendor is quoting $X for a rewrite"
Vendors quoting rewrites almost never quote rescues. Rescues are hard to sell because they don't have the "we'll replace your dinosaur with a spaceship" narrative. Rewrites are easy to sell because that narrative is compelling. If your only quote is a rewrite quote, you are hearing from vendors who don't do rescues. That does not mean rescue isn't a viable option. It means you should get a rescue-shop quote too before deciding.
We do exactly that — assessment first, then a written recommendation, then work. The recommendation may include partial rewrite. But it will be honest about what the trade-offs are.
"But we want to be on modern technology"
Understandable. Nobody wants to be the CIO who missed the boat. But "modern technology" is not a business outcome — it is a technology outcome. The business outcome is "our operations continue to work while our costs go down and our team gets easier to hire." Rescue plus incremental modernization delivers that outcome for a fraction of the cost of a rewrite.
If "modern technology" is genuinely a strategic requirement (for regulatory reasons, or because the technology stack is genuinely end-of-life and unsupported), then a phased modernization is right. That is different from a big-bang rewrite.
"But we already started the rewrite"
If you have already started a rewrite and it is going badly, you are not alone. The industry pattern of stopping-a-failing-rewrite-and-rescuing-what-exists is common enough that it has a name — the rescue-of-a-rescue-attempt. Our own engagement history includes the $180K failed migration rescue where we took over a stalled rewrite and delivered a working system in four months.
Sunk-cost is not an argument to continue. Stop the rewrite. Do an assessment. Decide from the new information.
When rewrite is actually the answer
To be balanced: there are situations where rewrite is the right decision. They are rarer than the industry pretends, but they exist. Rewrite is the right answer when all of the following are true:
- The business has fundamentally changed — the software encodes processes the company no longer runs.
- The codebase is small — under 50,000 lines, ideally under 20,000.
- The business logic is fully documented — either from the original team or from a completed rescue-style assessment.
- Downtime tolerance is high — the business can accept a 6-12 month period of degraded functionality during cutover.
- The vendor doing the rewrite has done this exact pattern before — not "we do rewrites in general" but "we have rewritten this specific technology stack for this specific industry three or more times."
- The budget has 50% contingency — because rewrites always run over.
If you can honestly answer yes to all six, rewrite is a reasonable choice. If you cannot, do the rescue assessment first.
What to do next
If your count of rescue signals is 4-6, the next step is a free 30-minute consultation. We walk through your six-factor answers, sanity-check them, and tell you honestly whether a rescue, a partial-rewrite-plus-rescue, or a full rewrite is the right first move. No quote until we understand your problem.
If your count is close to even (3 rescue, 3 rewrite), the next step is a written assessment. That is not the same as a consultation — it is a 2-6 week engagement where we read the code, document the business logic, and produce a report with a clear recommendation. Assessment costs are transparent up-front and are refundable against the eventual engagement if you choose to proceed.
If your count is heavily rewrite-weighted (0-2 rescue signals), you may already have the answer. But we would still recommend the assessment. Every rewrite we have rescued after failure — including the $180K one — was preceded by an owner who was certain the rewrite was correct without doing the assessment first. The certainty was expensive.
Schedule the consultation here. The call is free. The recommendation comes without an invoice.
A closing note on the Warning Signs framework
This article is the decision-side companion to Five Warning Signs Your 20-Year-Old System Is About to Fail. If two or more of the five warning signs from that article are firing in your system, the decision framework here becomes urgent — you are past the point where "we'll get to it eventually" is a viable stance.
The three companion articles work as a set:
- What to Do When Your Software Vendor Disappears — for the acute-crisis case.
- Five Warning Signs Your 20-Year-Old System Is About to Fail — for the deciding-when case.
- This article — Rescue vs. Rewrite Decision Framework — for the deciding-what case.
If you have read all three and still want a second opinion, that is exactly what the consultation is for. Book it here.