Rewrite vs. Refactor: The Decision Your CFO Will Fund

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A COO or founder of a 100–500-person Indian business running a 7–12-year-old custom application whose engineering team has just told her 'the code is too messy to add features to' — and she needs to decide whether to approve a full rebuild or a refactor before the next board meeting

Refactor first, rewrite only when the architecture itself blocks the business — and when you do rewrite, do it in increments that each ship to production inside a quarter. That is the short answer, and it is grounded in a number your CFO will care about: complete rewrites fail 60–80% of the time, either canceled outright or delivered without the promised benefits, according to industry research compiled by Loop Studio. Of the ones that do finish, most arrive 2–3× late and 2–4× over budget.

So when your head of engineering tells you the ten-year-old .NET monolith or the Laravel application that runs your operations is "too messy to add features to," the right next question is not "how much will a rebuild cost?" It is "what is the smallest piece of this we can modernize that pays for the next piece?" This post gives you the argument to take into the board meeting.

Why your engineers are probably half right

Engineering teams asking for a full rewrite are rarely lying. The codebase genuinely is painful. New hires take months to be productive. A one-line change requires regression testing of modules nobody fully understands. Deploys are scheduled at 2am on Sundays because the team is scared of them.

But "painful to work in" and "needs to be thrown away" are different diagnoses. McKinsey estimates technical debt can account for up to 40% of an organization's technology estate value, with 10–20% of every new product dollar quietly diverted to managing it (cited via Gorilla Logic). That is the cost you are already paying. The question is whether a rewrite reduces it or doubles it for 18 months before reducing it.

The honest reason senior engineers prefer rewrites: refactoring is slow, unglamorous, and produces no artifact to show at an all-hands. A rewrite is a greenfield project with modern tooling, which is more fun and better for a CV. This is not a conspiracy — it is incentive gravity. Your job as the business owner is to make the decision on business terms, not on team-morale terms.

The cost of doing nothing — in CFO language

Before comparing rewrite to refactor, price the status quo. This is the number your CFO will anchor against, and it is almost always bigger than the finance team realizes because it is spread across multiple cost centers.

Four line items to put on the slide

• Support and licence drag. Gartner (2024) found legacy applications can consume up to 80% of total IT budgets, leaving under 20–30% for growth and innovation (via Gorilla Logic). Pull your actual AMC, hosting, and specialist-contractor spend for the last three years and plot the trend.
• Headcount absorbed by workarounds. How many people in operations, finance, or customer support exist primarily because the system cannot do something it should? A reconciliation team of four reconciling two systems that should talk to each other is a ₹60–80 lakh annual line item hiding in payroll.
• Audit and breach exposure. Unsupported runtimes, unpatched dependencies, no audit trail on sensitive tables. If you are regulated — healthcare, lending, payments — this is a real contingent liability, not a theoretical one. Get your auditor's view on this in writing; this post is not a substitute for that.
• Revenue the system blocks. List three features sales has asked for in the last 18 months that engineering has refused or deferred. Attach a realistic revenue number to each. This is usually the biggest line item and the hardest to see.

Add these up over a three-year horizon. That is your "do nothing" baseline. Any modernization approach has to beat it on expected value — not best case.

The three options, honestly compared

You have three real choices. Each has a distinct risk profile.

Option A: Pure refactor (6–12 months, lowest risk)

Keep the architecture. Clean up the code module by module. Add tests. Upgrade the runtime. Fix the deploy pipeline. The business keeps running on the same system throughout; new features ship on the same cadence or slightly slower while the work is in progress.

Good for: Codebases where the data model is still right and the business logic still matches operations. If the system is slow and ugly but conceptually correct, refactor.

Bad for: Systems built on a database schema that no longer reflects how the business works, or on a framework whose vendor has stopped shipping security patches. You cannot refactor your way out of a dead runtime.

Option B: Strangler-fig incremental rebuild (12–24 months, moderate risk)

Named after a plant that grows around a host tree and eventually replaces it. You stand up a new system alongside the old one and migrate functionality module by module — orders first, then inventory, then reporting — with a routing layer deciding which system handles each request. The old system shrinks as the new one grows. Both run in production for most of the project.

Good for: Most real-world situations. It is the approach that handles the thing rewrites fail at — mid-project scope change. If the board decides in month 7 that the business needs a new pricing model, you build it in the new system without stopping the old one.

Bad for: Teams that cannot tolerate running two systems in parallel operationally. There is a real integration tax — the routing layer, the data sync, the dual-write period. For a six-month small-scope job this overhead is not worth it.

Option C: Big-bang full rewrite (9–18+ months, highest risk)

Freeze features on the old system. Build the new one. Cut over on a weekend. This is what your engineers are probably proposing.

Good for: Genuinely small, well-understood systems — think a single internal tool used by 20 people. Or situations where regulation forces a hard architectural break (data residency, tenancy isolation) that cannot be done incrementally.

Bad for: Almost everything else, and here is why your CFO should care: PMI's Pulse of the Profession found 52% of projects experience scope creep or uncontrolled change, up from 43% five years earlier, and 43% of projects finish over budget (TRCR analysis of PMI data). Scope creep can drive cost overruns up to 4× the initial estimate (IEEE Access / ResearchGate). A big-bang rewrite concentrates all that risk into a single, unshippable work-in-progress for 12+ months.

The decision rule your CFO will fund

Here is the one-page framework. Walk your head of engineering and your CFO through it in the same room.

In practice, for a 7–12 year old application at a 100–500 person Indian business, the honest answer is almost always: refactor the parts that work, strangler-fig the parts that do not. The question of when to rewrite legacy software in India is rarely binary — it is a sequencing question.

What modernization actually costs — the shape of the number

Published benchmarks exist, and they are wide ranges because the inputs vary enormously. The average cost of a traditional legacy tech upgrade was $2.9 million in 2023, and 67% of legacy modernization projects exceed initial budget by more than 35% (Horizon.dev, 2026). India's Application Modernization Services Market is projected to grow from USD 626.68 million in 2025 to USD 1,746.63 million by 2030, an 18.6% CAGR (MarketsandMarkets, 2025) — so pricing is competitive but demand is rising, which matters for vendor selection timelines.

What actually moves the number

• Surface area. Count screens, API endpoints, scheduled jobs, and reports. Not lines of code — that is an engineer's metric, not a scoping metric.
• Integrations. Every external system (payment gateway, ERP, SMS provider, GSTN, bank APIs) adds discovery, auth, error handling, and testing. Two integrations is a different project from eight.
• Data migration. How many years of data, how dirty is it, do old records need to remain queryable? This is often the single largest line item and the most under-estimated.
• Compliance scope. SOC 2, HIPAA-equivalent, RBI, DPDP — each adds process overhead that is not negotiable.
• Business availability. Can your operations head give the vendor two hours a week, or two hours a day? Vendor velocity is capped by business clarity.

Illustrative only: a strangler-fig modernization of a ten-year-old operations application with roughly 40 active screens, three integrations (payment, SMS, one ERP), five years of transactional data to migrate, and no regulated-industry overhead typically scopes as a 9–14 month engagement delivered in three or four shippable increments. Change any one of those assumptions and the shape changes. Your CFO should expect a vendor proposal to show the drivers, not just a total.

Three specifics will turn any range into a real quote: a feature inventory of the current system (even a spreadsheet), a sample of the actual production data (anonymized), and a decision on which integrations are in-scope for the first increment. Without those, every number is a guess. A scoping conversation is where those get pinned down.

Phasing the spend so increment one pays for increment two

This is the part that unlocks CFO sign-off. Do not ask for the full budget upfront. Structure the program so each phase delivers measurable business value that funds — in cash or in approved budget — the next phase.

A pattern that works:

1. Phase 0 (4–6 weeks): Discovery and architecture decision. Fixed scope, small spend. Output is a written modernization plan, a feature inventory, a data assessment, and a go/no-go on refactor vs strangler-fig. If the vendor cannot deliver this cleanly, do not give them phase 1.
2. Phase 1 (3–4 months): Pick the module with the highest pain-to-complexity ratio. For most ops systems this is reporting or a specific workflow that consumes disproportionate headcount. Ship it. Measure the headcount hours it recovers.
3. Phase 2 onwards: Each subsequent increment is funded against the operational savings or revenue unlock of the prior one. McKinsey reports organizations typically cut operational costs by 30–50% within two years of completing modernization (cited via Gorilla Logic) — but that number is realized increment by increment, not at the end.

This structure is what makes the refactor vs rewrite business case fundable. You are not asking the CFO to approve a $2M rebuild. You are asking her to approve a $150K discovery, with a committed decision gate before each subsequent tranche. Her downside is capped at the current phase.

What the business has to supply (this is non-negotiable)

Modernizations fail more often from the client side than the vendor side. If you commit to this, commit to these three things:

• A single empowered decision-maker who can resolve business-logic ambiguity within 48 hours. Not a committee.
• Access to the operations team that actually uses the current system — not just the manager who thinks they know how it is used. Half the business rules in a ten-year-old application live only in the heads of the people clicking through it.
• A written change-control rule for mid-project scope requests. Something as simple as "any new feature request pauses current sprint, costs an estimate, and requires sign-off from [name]." Without this, you will join the 52% with scope creep.

How CodeNicely can help

The engagement closest to this situation in our portfolio is GimBooks — a fintech accounting SaaS where we worked through exactly this question. The product had grown features faster than its architecture could support, and the team had to decide what to carry forward and what to rebuild. We did not propose a full rewrite. We scoped a modular modernization that let the business keep shipping to existing customers while the new foundation grew underneath. The company went on to raise from Y Combinator — not because of the engineering decision alone, but because the engineering decision did not become a reason to miss a product milestone.

For operations-heavy systems with marketplace and integration complexity, the Vahak engagement is a closer analogue — a logistics platform where we had to modernize the matching and routing layer while the marketplace continued transacting. In both cases the client kept full IP ownership and the right to take the codebase to any vendor afterwards. That matters more than it sounds: a modernization that creates a new form of lock-in is not a modernization, it is a hostage transfer. More on the broader approach at digital transformation and enterprise services.

The one-paragraph version for your board pack

A full rewrite fails 60–80% of the time and arrives late and over-budget when it succeeds. The failure mode is not technical — it is that the business cannot stop changing for the 9–18 months the rebuild takes, and uncontrolled change blows up the project. The lower-risk approach is a strangler-fig modernization: discover first, then ship the highest-pain module in the first quarter, then fund each subsequent increment from the savings or revenue of the one before. The business commits to a single decision-maker, operations access, and written change control. The downside is capped at the current phase, and the first production ship-date is inside 90 days of kickoff — not 18 months.

That is the paragraph. Take it to the meeting.

Frequently Asked Questions

How do I know if my engineers are proposing a rewrite because it is necessary or because it is more interesting work?

Ask them to produce a written feature inventory of the current system and a specific list of what in the architecture — not the code — makes the next six features impossible or unsafe to build. If they can name specific architectural constraints (dead runtime, schema that cannot represent a new entity, no way to achieve required isolation), the case is real. If the answer is vague — "the code is spaghetti," "we need a modern stack" — it is a refactor conversation, not a rewrite one.

What does a legacy modernization project typically cost for a mid-sized Indian business?

Published benchmarks put the average traditional legacy upgrade at around USD 2.9M globally in 2023, with 67% of projects exceeding budget by more than 35% (Horizon.dev) — but Indian delivery pricing and project scope varies widely from those figures. The number is driven by surface area (screens, endpoints, jobs), integration count, data migration volume, and compliance scope. To get a real quote you need a feature inventory, a sample of production data, and clarity on which integrations are in-scope for phase one. A short discovery engagement produces those inputs.

How long does a strangler-fig modernization take before we see the first production release?

The pattern is designed to put a working increment into production inside the first quarter after discovery — that is the point of the approach. The full program for a mid-complexity operations system usually runs 12–24 months across three or four increments. Timeline is driven by how fast the business can make decisions, not just how fast the vendor can code; a client that can answer business-logic questions within 48 hours moves roughly twice as fast as one that cannot.

What happens to our existing team during a modernization?

They continue to run and patch the existing system through most of the project. The strangler-fig pattern specifically keeps the old system in production until each module is retired. Many clients use the modernization as an opportunity to upskill their internal team on the new stack by pairing them with the vendor team, so that post-handover the business is not dependent on the vendor for ongoing changes. Insist on this in the contract.

What is the single biggest reason modernization projects fail?

Uncontrolled mid-project scope change. PMI data shows 52% of projects experience scope creep, and the cost impact can be up to 4× the original estimate (IEEE / PMI research). The protection is structural, not contractual: a strangler-fig approach that ships small increments, a written change-control rule, and a single business decision-maker with authority to say no to new requests mid-sprint. Technology risk is manageable. Scope risk is what kills budgets.