Header image

What $20M in Replacement Cost Actually Means (And Why It Matters)

At some point in this whole journey, an outside group did the math:

“To rebuild this platform from scratch, to the same depth and standard,
you’re looking at roughly $20M.”

That number isn’t sacred. It’s directional.

But it’s not fantasy.

It’s what happens when you translate:

20 years of systems work
Hundreds of integrations and workflows
Mountains of domain knowledge

…into realistic engineering and business costs.

This post is about what that $20M actually represents and why business owners should pay very close attention before they ever say:

“Let’s just rewrite it.”

1. The $20M Calculation (No Hand-Waving)

You don’t get to $20M by saying “our code is special and priceless.”

You get there with ugly, spreadsheet math:

Scope:
- Core application logic
- Integrations with state systems and partners
- Workflows, reporting, compliance behavior
- Data migration and cutover
Team:
- 15–25 engineers (mix of mid, senior, and architects)
- 3–5 QA / SDET / Ops / DevOps
- PM / BA / domain experts
Timeline:
- 3–4 years, not 9–12 months
- Because:
  - domain knowledge doesn’t parallelize
  - integrations and migrations take time
  - you can’t pause the existing business while you “rebuild”

Now put numbers to it:

20 people × $175K/year fully-loaded × 4 years
≈ $14M in engineering labor

Add:

QA / Ops / PM / domain specialists
Extra contractors
External vendors
Contingency because this never goes exactly as planned

You’re very comfortably in the $18–22M range before lost revenue and disruption.

That’s the $20M ballpark.

Not magic. Math.

2. Labor Cost: The Meat of the Number

Break it down a bit more concretely.

Developers

12–18 devs over 3–4 years
Fully-loaded (salary + benefits + overhead): $150K–$180K/year
Let’s say 15 × 165K × 4 ≈ $9.9M

Architects / Senior Leads

2–3 architect-level people
$220K–$250K/year loaded isn’t crazy at all
3 × 235K × 4 ≈ $2.82M

QA / SDET / DevOps

3–5 people
$140K–$170K/year
4 × 155K × 4 ≈ $2.48M

Add those three buckets:

~$9.9M + ~$2.82M + ~$2.48M ≈ $15.2M

We haven’t counted:

PM / BA roles
Compliance / legal / external security work
Additional migration support staff

Getting to $16–18M in direct labor is not aggressive at all.

$20M isn't "we multiplied everything by 10 because we feel special." It's "we added realistic overhead to a large, ugly, real project."

The math breakdown

3. Time Cost: Why You Can't Just "Throw More Devs at It"

Non-technical folks love:

“If it takes 20 people 4 years, let’s just hire 80 and do it in 12 months.”

No.

Because:

Domain knowledge is serial, not parallel
- You can’t teach 80 people a complex domain faster just by hiring more.
- They have to:
  - talk to users
  - study reports
  - discover edge cases
- That takes calendar time.
Business rules are discovered, not just recopied
- Half the behavior in a 20-year system was never written down.
- It lives in:
  - edge-case code paths
  - ops playbooks
  - “Of course it works that way” assumptions in users’ heads.
Integrations and migrations move at the speed of reality
- External vendors and state agencies don’t care about your aggressive timeline.
- They have:
  - test windows
  - maintenance schedules
  - their own politics
- You cannot brute-force their calendars.
Coordination overhead explodes
- Past a certain team size, every new hire adds more:
  - meetings
  - miscommunication
  - review cycles
- You hit diminishing returns fast.

Realistic rebuilds are multi-year, not “one extra sprint.”

4. Complexity Cost: What You’re Actually Rebuilding

You’re not just rebuilding screens and endpoints.

You’re rebuilding:

Business logic
- Eligibility logic
- Workflow transitions
- State-specific quirks
- “If X, Y, and Z, but not on weekends” rules
Integrations
- SOAP / REST / file drops / SFTP
- Legacy systems with undocumented behavior
- Error handling patterns that evolved over years
Compliance
- HIPAA
- State regs
- Audit trails
- Retention and destruction schedules
Operational behavior
- Batch jobs and cutoffs
- SLA timing
- Reporting windows
- Monitoring and alerting expectations

You’re also rebuilding:

Thousands of small compromises and design decisions that exist because:
- humans are messy
- governments are messy
- reality is messy

That’s the complexity cost.
That’s why the number isn’t $2M.

5. Business Disruption Cost (The Part Everyone Ignores)

The $20M estimate is mostly build cost.

Now layer in disruption cost:

While you rebuild:
- The old system isn’t standing still.
- Customers still need:
  - enhancements
  - fixes
  - support
- Regulatory landscapes keep changing.

So you’re either:

Splitting focus:
- half the team keeping the old world alive,
- half building the new world,

or:

Going into a quasi-feature freeze:
- and hoping customers tolerate stagnation for 3–4 years.

Business disruption shows up as:

Slower feature delivery
Reduced customer satisfaction
Higher churn risk
Lost deals (because you can’t credibly promise improvements while you’re buried in a rebuild)

Even small percentages here matter:

If you lose just one major contract mid-rebuild because you’re distracted:
- That can be millions in lifetime value gone.
And if the rebuild slips (and it will), the disruption stretches out.

The opportunity cost alone over a multi-year rebuild can add millions more to the effective price tag.

6. The Technical Debt of Rewrites

People fantasize:

“We’ll rewrite it and get rid of all this technical debt.”

Reality:

You’re trading known debt for unknown debt.

Fresh rebuild debt includes:

New bugs
- The old system’s bugs are largely known and compensated for.
- The new system will ship with charming surprises.
Missing nuance
- You will forget to port certain behaviors.
- A tiny subtleness in the old logic may be critical to one big customer.
Integration regressions
- External systems depended on quirks you didn’t even know existed.
- Now they fail in novel ways.
Performance cliffs
- You had years of real-load tuning in the old world.
- You’ll spend years rediscovering the hot paths in the new one.
New stack risk
- If you also go “modern stack”:
  - now you’re paying the learning curve tax
  - plus your own implementation bugs
  - plus ecosystem churn risk

Rewrites don't erase tech debt. They re-roll the dice with higher stakes.

Rebuild risks

7. Why Non-Technical Owners Say "Just Rewrite It"

Because from the outside, they see:

Outdated UI
Complaints about “legacy”
Slow dev velocity
Engineers grumbling

And they jump to:

“It’d be faster and cheaper to start fresh.”

What they’re missing:

The value isn’t in the UI.
The value isn’t even in the tech stack.

The value is in:

Business rules
Integrations that finally stay up
Edge cases that no longer explode
Trust built with regulators and customers

Most owners:

Have never personally lived through a multi-year rewrite disaster.
Underestimate compounding complexity.
Overestimate how “simple” their system is.

So $20M sounds like:

ego,
posturing,

instead of what it is:

A rough estimate of how much reality costs when you try to recreate it.

8. Real-World Rewrite Failures (Pattern, Not Gossip)

You’ve seen this movie:

Someone declares the legacy system “unfixable.”
Leadership gets sold a “modernization” vision.
Budget: $X million, timeline: 12–18 months.
New system:
- is late,
- is incomplete,
- misses core use cases.
Old system:
- can’t be shut off,
- gets patched in panic mode,
- now must integrate with the half-baked new system.

Net result:

More systems
More complexity
More cost
More pain

Sometimes they never fully decommission the old platform.
They end up with two half-working systems instead of one solid one.

That’s the reality $20M is hinting at:

“You think this is a $2–5M cleanup. It’s not.
You’re staring at a multi-year, multi-departmental transformation project.”

9. When a Rewrite Is the Right Call

To be clear:
“Never rewrite” is just as dumb as “always rewrite.”

Rewrites are justified when:

The existing architecture structurally cannot support what’s next
- Example:
  - fundamentally wrong data model
  - hard limits you can’t realistically refactor around
- You’ve tried serious refactoring and still hit walls.
The system actively harms the business
- Outages are constant.
- Changes are glacial and dangerous.
- Talent to maintain it simply doesn’t exist anymore.
You have a credible, staged plan
- Strangler pattern:
  - carve out modules one at a time
- Parallel run where needed:
  - old and new side-by-side until proven
- Realistic governance:
  - someone is responsible for:
    - risk management
    - migration
    - communication

The question is never:

“Is it old?”

The question is:

“Is the total cost (engineering + disruption + opportunity)
of a rebuild lower than the cost of continuing to evolve what we have?”

You can’t answer that with vibes.
You need numbers and honest risk assessment.

10. What I Want Business Owners to Actually Learn From $20M

Here’s the punchline:

1. Your existing system is probably worth far more than you think.

Not because:

the code is pretty,
or the UI is shiny,

but because:

it encodes:
- thousands of real-world decisions
- integrations that no longer blow up every week
- auditability that keeps you out of trouble

2. “Just rewrite it” is almost always a multi-million dollar sentence.

Before you go there, ask:

Have we:
- fully mapped what this system does?
- understood its edge cases?
- quantifed the risk of breaking it?

3. Demand a real cost breakdown before you buy the rewrite story.

Questions to ask:

How many people?
What roles?
For how long?
What’s the parallel run strategy?
How do we prevent revenue and contract risk during migration?
How do we guarantee we don’t ship a “prettier but dumber” version?

4. Consider “evolve and strangle” before “burn and rebuild.”

Can we:
- modularize?
- wrap?
- improve incrementally?
Can we get 80% of the modernization benefit for 20–30% of the cost?

5. Treat replacement cost as a valuation lens, not a flex.

That $20M isn’t about bragging.

It’s about:

understanding what you have,
understanding what it would cost to recreate,
and then making grown-up decisions about:

maintain vs extend vs rewrite.

If you walk away with one thing, it’s this:

Before you swing a wrecking ball at a system that quietly runs your business,
do the math.
The number might be a lot closer to $20M than you want to admit.

Context → Decision → Outcome → Metric

Context: An independently audited platform with a $20M–$35M replacement estimate, 20 years of uptime, 15+ integrations, and millions of transactions.
Decision: Avoid the rewrite trap; favor evolve/strangle patterns, adapter isolation, and staged migrations with parallel runs. Treat replacement cost as a lens for investment, not a flex.
Outcome: No full rewrites in two decades; modernization happened incrementally with minimal downtime; valuation held because evidence showed how costly replacement would be.
Metric: Zero rebuilds; high renewal rates; modernization delivered via phased migrations rather than big-bang failures that often cost $2–5M and then another $3–5M to fix.

Anecdote: The Almost-Rewrite

A new exec wanted a “modern stack” rewrite. We priced it: 18 months, eight engineers, parallel ops risk, unknown regressions—$4–6M in best-case effort, plus contract risk. Instead, we strangled the worst parts: wrapped integrations, refactored reporting, expanded schemas, and added feature flags. Twelve months later, the UI was modernized, ops were calmer, and we spent a fraction of the projected rewrite cost. The exec got modernization; the business avoided disaster.

Mini Checklist: Decide Rewrite vs. Evolve

List hard blockers (data model limits, perf ceilings) and prove refactoring can’t solve them.
Price the rewrite honestly: team size, duration, parallel run risk, and opportunity cost.
Define a strangler plan: module boundaries, adapters, migration sequencing, and cutover tests.
Require rollback paths for each migration step; if you can’t roll back, you’re gambling.