Cost to rewrite a legacy application in 2026
Cost to rewrite a legacy application in 2026
Rewriting a legacy application in 2026 typically costs $80,000 to $3,000,000+, almost entirely driven by codebase size and hidden business logic. A small internal tool under 50,000 lines of code lands at $80k to $200k. A mid-sized SaaS in the 50k to 200k LOC range runs $300k to $800k. Anything past 200k LOC routinely exceeds $1M, and complex enterprise systems push past $3M. The cost is rarely the obvious part. The hidden killers are feature parity, undocumented business logic, data migration, dual-running infrastructure, and user retraining.
Most rewrites cost 3x to 5x more than the initial quote. A surprising number cost infinity, because they never ship.
The honest first answer: you probably shouldn't rewrite
Before we get to the price tag, we have to say the thing no consulting firm will say. The most common outcome of a full rewrite is a worse product delivered 18 months late, by a team who quit halfway through. Joel Spolsky wrote about this in 2000 and it is still true in 2026.
If your legacy app is making money, the safer math is to refactor in place. A team using Cursor, Claude Code, and a strangler-fig pattern can modernize a 100k LOC codebase for around $150k over 6 months, while shipping new features the entire time. A clean-room rewrite of the same app costs $500k+ and ships zero customer value until launch day.
We will give you the rewrite numbers because you asked. We will also tell you when not to spend them.
What "rewrite" actually means (and the three honest options)
People use "rewrite" to mean three very different projects. The cost spread between them is 10x or more.
- Lift-and-shift port. Same logic, new runtime. Example: COBOL to Java, jQuery to React, Heroku to AWS. Cheapest, lowest risk, lowest reward.
- Strangler-fig modernization. New code wraps the old, route by route, until the old code is dead. Medium cost, low risk, high reward. This is what we recommend 80% of the time.
- Big-bang rewrite. Throw it all out, write fresh, swap on launch day. Highest cost, highest risk, the option Joel warned about. Sometimes correct (we will say when).
Cost by codebase size, in 2026 dollars
Here are the realistic ranges we see when founders book through Cadence. These assume AI-native engineers using Cursor and Claude Code as a daily driver. Without AI tooling, multiply by 1.6x to 2x.
| Codebase size | Big-bang rewrite | Strangler-fig | Lift-and-shift port |
|---|---|---|---|
| Under 50k LOC | $80k to $200k | $40k to $120k | $20k to $60k |
| 50k to 200k LOC | $300k to $800k | $150k to $400k | $80k to $200k |
| 200k to 500k LOC | $1M to $2M | $400k to $900k | $250k to $600k |
| 500k+ LOC | $2M to $3M+ | $900k to $2M | $500k to $1.5M |
These ranges are for the engineering line item only. Add 15% to 25% for QA, 10% for project management, and a contingency buffer of at least 30% for the things you did not see coming. You did not see things coming. Trust the buffer.
The true cost factors nobody quotes you
Engineering hours are the cheapest part of a rewrite. The bills that surprise founders are the ones below.
Feature parity
Your current app has features you forgot exist. The export-to-CSV nobody mentions in the roadmap. The Friday-only batch job that finance depends on. The undocumented webhook that one enterprise customer signed a contract around in 2022. A rewrite has to find and reimplement every one of them, and the discovery phase alone is usually 15% to 20% of total cost.
A useful exercise: pull the list of every endpoint, every cron job, every webhook, every email template, every PDF generator, every CSV export, every admin tool. Multiply by 1.5x because you missed some. That number is what you have to recreate before launch.
Hidden business logic
The single most expensive part of any rewrite is the if-statement that was added in 2019 to handle one customer's edge case and never documented. Your legacy app is full of these. Some of them are load-bearing.
The only safe extraction method is to run the old and new systems side by side and compare outputs on production traffic. This is called shadow testing. Stripe used it when they rewrote their billing engine. GitHub used it for the move from MySQL to Vitess. Budget at least 8 weeks of dual-running for any rewrite that touches money or compliance.
Data migration
If your data model changes (and it always does), you owe yourself a migration plan that handles three cases: backfilling historical data, dual-writing during cutover, and rolling back if launch day goes sideways. Each one is its own mini project.
A realistic migration budget for a 50k to 200k LOC SaaS with a few million rows: $30k to $80k, and 4 to 12 weeks of calendar time. Migrations of PII or financial data are at the high end because of audit requirements. If you are running on MySQL today and moving to Postgres as part of the rewrite, we wrote a full breakdown of MySQL-to-Postgres migration costs that maps cleanly onto this section.
Dual-running period
For strangler-fig and shadow-tested big-bangs, you pay for two production environments at the same time. Compute, databases, third-party services (Auth0, Segment, Datadog all bill per environment), monitoring. Plan for 3 to 9 months of dual cost, which usually adds $15k to $80k depending on the stack.
Retraining users
Internal tools have a real change-management cost. If 40 ops people have to relearn the order-entry screen, you owe them docs, office hours, and a parallel period where both systems work. For B2B SaaS, every UI change risks churn. The standard discipline: keep the UI identical during a rewrite, refresh it later as a separate project.
The opportunity cost
Every week your seniors spend on the rewrite is a week they did not ship revenue features. A 6-month big-bang at a 20-person startup typically costs $400k to $800k in missed product velocity, on top of the engineering bill.
Strangler-fig vs big-bang: when each one is correct
We get asked this constantly. Here is the honest framework.
Choose strangler-fig when
- The app is making money today and you cannot afford to stop shipping.
- The codebase is over 50k LOC.
- You have any meaningful third-party integrations (payments, webhooks, OAuth).
- Your data model has more than 20 tables.
- The team that wrote the original code is gone or partially gone.
Choose big-bang only when
- The codebase is small (under 30k LOC).
- You are pre-revenue or pre-PMF and have no users to disappoint.
- The current stack literally cannot be extended (a discontinued runtime, a vendor that shut down).
- You have a hard external deadline (regulatory change, contractual end-of-life) and no other path.
- You have an experienced team that has done a rewrite before. Not their first.
The third category is "do not rewrite at all, refactor". This is the right answer more often than founders want to admit.
The "don't rewrite, refactor" path
A surprising percentage of rewrites are triggered by frustration, not by a real technical wall. The codebase is messy, the senior engineer who knew it just left, the new hires complain about it. None of those problems are solved by a rewrite. They are solved by 3 months of disciplined refactoring.
A good refactor plan looks like this:
- Add tests to the parts you are most afraid to touch. Use Claude or Cursor to generate test scaffolds against the current behavior. You are not testing what the code should do, you are pinning what it does do.
- Pay down the top 5 dependencies. Upgrade your framework, your ORM, your auth library to current versions. Most "I hate this codebase" pain is actually "this codebase is 4 major versions behind".
- Extract one bounded context per month. Move billing into its own module. Then notifications. Then admin. Each extraction makes the next one easier.
- Replace one commodity feature per quarter with SaaS. Roll-your-own auth becomes Clerk or WorkOS. Roll-your-own analytics becomes PostHog. This removes 30% of your codebase without rewriting anything.
A mid-level engineer at $1,000/week, 20 weeks of focused refactor work, costs $20k. That is one twentieth the cost of a rewrite, and you keep shipping the whole time. Many of the same lessons apply to the admin dashboard refactor breakdown we published earlier this year.
Cost breakdown by approach
| Approach | Typical cost (100k LOC app) | Timeline | Pros | Cons |
|---|---|---|---|---|
| US full-time hire (3 engineers) | $750k+ first year | 9 to 18 months | Deep ownership, in-house knowledge | Hiring takes 4+ months; rewrite scope creeps |
| Dev agency (US/EU) | $400k to $1.2M | 6 to 12 months | Process discipline, dedicated PM | Slow ramp, agency margins, change-order fees |
| Offshore agency | $150k to $400k | 9 to 18 months | Cheapest hourly | Communication lag, parity drift, IP risk |
| Freelancers (Upwork) | $80k to $250k | Unpredictable | Cheap, fast to start | Hard to coordinate, retention risk mid-project |
| Toptal | $300k to $700k | 6 to 12 months | Vetted, fast to start | $500/hr range; minimums; long contracts |
| Cadence | $150k to $400k | 48-hour trial then 4 to 9 months | Every engineer AI-native by default, weekly billing, replace any week, no contracts | Less suited for enterprise procurement processes |
A typical Cadence rewrite team is one Lead at $2,000/week for architecture, one Senior at $1,500/week for the strangler-fig work, and one Mid at $1,000/week for migration tooling and tests. That is $4,500/week, or $117k over 6 months, plus contingency. We see roughly 67% of trial bookings convert to multi-week engagements, and the median first commit lands at 27 hours from booking, which keeps the discovery phase short.
How to reduce cost without cutting corners
Five moves that consistently work.
- Pick strangler-fig as the default. You ship value the whole time and never face a launch-day cliff.
- Use AI-native engineers. Cursor and Claude Code change the time-to-understand-a-codebase from weeks to days. Every engineer on Cadence is AI-native by default, vetted on Cursor, Claude, and Copilot fluency in a voice interview before they unlock bookings. This is not optional or premium tier; it is the baseline.
- Replace commodity features with SaaS during the rewrite. Do not port your custom auth. Drop Clerk in. Do not port your custom analytics. Drop PostHog in. Every system you delete is one you do not have to rewrite, test, or maintain.
- Shadow test in production before cutover. Run the new system in parallel for 4 to 8 weeks. Diff the outputs. The bugs you find this way cost 10x less than the bugs you find at 2am after launch.
- Budget the contingency before you start. Add 30% to whatever number you arrived at. If you do not need it, great. You will need it.
The fastest path from "we need to rewrite" to shipped
The honest 3-step recommendation:
- Run a 2-week scoping engagement first. Hire one Senior engineer for 2 weeks to audit the codebase, list every feature, and produce a strangler-fig plan. This is around $3,000 and saves you from buying the wrong rewrite.
- Decide refactor vs rewrite based on the audit. If a 3-month refactor solves 80% of the pain, do that instead. If not, the audit becomes the rewrite plan.
- Staff the team weekly, not yearly. Long contracts lock you into the team you picked on day one, before you knew anything. Weekly billing lets you adjust the team as the rewrite reveals what it actually needs.
If you do not already have an engineer in mind for step 1, the fastest path is to book a Senior on Cadence for a 2-week audit. Replace the week if it is not working, the 48-hour trial means you do not pay for the first two days, and you walk away with a written plan either way.
Booking on Cadence takes 2 minutes, the first 48 hours are free, and you can swap the engineer any week without notice. If you are weighing a rewrite, that is the cheapest way to get a real second opinion before committing $500k.
FAQ
How long does a full rewrite actually take?
For a 50k to 200k LOC app: 6 to 14 months end to end, including discovery, shadow testing, and dual-running. Big-bang rewrites that "should take 4 months" almost always take 12. Strangler-fig projects feel slower at first because no launch event, but they ship value every week and finish closer to the original estimate.
Is it cheaper to rewrite or refactor?
Refactor wins on cost roughly 8 times out of 10. A focused 3 to 6 month refactor by a Mid or Senior engineer costs 10% to 25% of a full rewrite, and you keep shipping features the whole time. Rewrite is only cheaper when the underlying platform is end-of-life or the data model is fundamentally broken.
What tech stack should we rewrite to in 2026?
If you do not have a strong opinion, the default boring stack is Next.js or Remix on Vercel, Postgres on Supabase or Neon, Clerk or WorkOS for auth, Stripe for billing, PostHog for analytics. This is the stack with the largest pool of AI-native engineers and the best Cursor and Claude tooling. We covered this in detail in our Next.js application cost breakdown.
Should we hire full-time or contract for the rewrite?
Contract for the rewrite itself, then hire full-time for the long-term maintenance. The rewrite is a defined project with a clear end. Once it ships, you want full-time owners. Doing it in this order saves you from hiring 3 engineers, finishing the rewrite in month 8, and then needing to find work for the team in month 9.
How do we know when the rewrite is "done"?
When the old system has been deleted from production and the on-call rotation has not been paged about either system for 4 weeks. Anything short of "the old code is deleted" is not done. We have seen rewrites run for 3 years because the team never finished the last 10%.
What if the rewrite goes over budget?
Plan for it before you start. Budget your engineering estimate plus 30% contingency. If you are halfway through and 60% over, stop and re-scope. Sunk-cost reasoning has killed more rewrites than any technical problem. A re-scope at month 4 is far cheaper than shipping a worse product at month 14.