Sunk Cost Fallacy in Engineering: Why Old Technology Slows You Down

The Engineer's Trap

Your company built a monolithic backend 5 years ago in Java.

It works. But:

CTO says: "Rewrite in Node.js and PostgreSQL."

But the engineering lead says: "We have 500k lines of Java code. Do not waste that investment."

That is sunk cost fallacy. And it is killing your velocity.

The Cost of Sunk Code

Example 1: The Monolith Problem

Situation:

Sunk cost thinking:

"We have 500k lines of Java. That is a $2M investment (500 engineers × $4k per line of code)."

But that is sunk. It should not factor into the decision.

Real decision:

Math:

Rewrite ROI: Positive after 18 months, then compound wins.

Example 2: The Wrong Database

Company uses MongoDB because it was trendy when they started.

Now they need SQL queries, joins, transactions.

Sunk cost thinking:

"We have 100M documents in MongoDB. We cannot migrate."

Reality:

The numbers:

Stay with MongoDB? That is a $500k per year ongoing cost.

Example 3: The Old Framework

Company built a web app in Backbone.js in 2015.

It works. But React/Vue is faster.

Sunk cost thinking:

"We have 200k lines of Backbone. Total rewrite would waste that."

The truth:

Cost analysis:

Rewrite cost: $400k (3 months, 2 engineers)

Payback: 1.25 years

Then: $320k savings per year, forever

When the Sunk Cost Argument Fails

The "500k Lines of Code" Argument

Engineer: "We have 500k lines of Java. That is years of work. We cannot throw it away."

CEO: "Okay, but let me ask: Is any of it actually good?"

Most legacy code:

Truth: You would probably keep 100k lines (the good 20%), rewrite 400k.

Not "throw away." Repurpose.

The "We Already Invested" Argument

Engineer: "We invested $2M in this architecture."

Right response: "That $2M is gone. Question is: what should we do for the next $2M?"

Past investment = sunk. Irrelevant. Future profit = what matters.

The Real Cost of Old Technology

Velocity Cost

Old tech: 1 feature per sprint
New tech: 3 features per sprint

Over 3 years:
Old tech: 150 features
New tech: 450 features

Market impact: 3x feature gap = losing to competitors

Hiring Cost

Old tech (Backbone, Struts, Monolith):
- 5% of job market wants to work on it
- Hiring takes 3 months
- Salary premium to attract talent: +30%
- Turnover is high (people want to learn new tech)

New tech (React, Node, Microservices):
- 30% of job market
- Hiring takes 3 weeks
- No salary premium
- People stay (career development)

Cost of old tech: $100k+ per year per engineer in hiring inefficiency + turnover.

Business Cost

Feature parity with competitors: 2 years behind
Market opportunity lost: $10M+ in the case of SaaS
Brand impact: "legacy company"

When NOT to Rewrite (Legitimate Reasons)

You have low growth

If:

Then: Keep the old tech. Cost of rewrite > benefit.

The system works great

If:

Then: Maybe do not rewrite. Maintain it.

Example: Trading systems, payment systems. If they work, do not fix them.

You have no alternative

If:

Then: Work with what you have. Incremental improvements.

When TO Rewrite

1. Velocity is killing you

Signal: Features that should take 1 week take 3 weeks.

Root cause: Old architecture.

Solution: Rewrite in modern architecture.

2. Hiring is impossible

Signal: Cannot find engineers for your tech stack.

Talent market dictates: Must move to popular tech.

3. Scaling costs are exploding

Signal: Server costs grew 10x without traffic growing.

Cause: Inefficient old architecture.

Rewrite for efficiency.

4. The tech is becoming deprecated

Signal: Security vulnerabilities in old framework. No community support.

Example: Trying to hire for Flash in 2026.

Decision: Rewrite or die.

The Smart Rewrite Strategy

Do not rewrite everything at once. That is how Netscape died.

Strategy 1: Strangler Pattern

Step 1: New app runs parallel to old app
Step 2: Gradually route traffic to new app
Step 3: Retire old app piece by piece
Step 4: Go live when new is 100% feature-parity

Benefit: Low risk, rollback capability, team can work on both.

Strategy 2: Module by Module

Step 1: Identify worst module (most broken, most complex)
Step 2: Rewrite that module
Step 3: Integrate with old system via API
Step 4: Repeat for next worst module

Benefit: Progressive, team learns, risk is isolated.

Strategy 3: Service Migration

Step 1: Extract high-value service (auth, payments, search)
Step 2: Move to new tech stack
Step 3: Monolith calls it via API
Step 4: Repeat for next service

Benefit: Immediate gains in velocity for that service.

Real Cost Calculation

Is It Worth Rewriting?

Formula:

ROI = (Annual Velocity Loss + Annual Hiring Cost + Annual Scaling Cost - Rewrite Cost) / Rewrite Cost

If ROI > 50%: Rewrite
If ROI < 20%: Wait
If 20-50%: Depends on other factors

Example Calculation

Current situation:

Rewrite:

Decision: Rewrite immediately.

The Psychological Shift

Engineers have to stop thinking: "Do not waste the old code."

Start thinking: "What code should we write next?"

The old code is sunk. It is history. It is archaeology.

What matters is: What builds the future?

Conclusion

Legacy technology is expensive. Not because it is old, but because it slows you down.

Every day you use old tech to "protect" a past investment, you are actually making that investment worse.

The question is not: "Have we invested enough to keep this?"

The question is: "Is this the best tool for the next 5 years?"

If not, rewrite. The sunk cost is irrelevant.