Why We Don't Recommend Rewriting Legacy From Scratch

Big Bang — the most expensive way to fail a project

"Let's just rewrite everything from scratch. Clean code, modern stack, no legacy mess."

Sounds tempting. We hear this from clients all the time. Usually after a developer said "it's easier to rewrite than to figure it out."

The Big Bang approach (rewriting the entire system at once) has three fatal flaws:

1. The business can't wait

While you're building a new system for six months, the business runs on the old one. Bugs don't get fixed, features don't get added — "why bother, we're rewriting anyway." The business slows down, competitors move ahead, and the new system ships six months late.

2. You lose business logic

Legacy code isn't just "bad code." It's 5-10 years of accumulated business rules, edge cases, and tax nuances. Even if the code looks terrible, it works correctly 99% of the time. Rewriting from scratch, you'll reliably reproduce maybe 70% of the logic. The remaining 30% will surface in production after launch.

3. Team motivation collapses

Big Bang is a marathon with no finish lines. First 3 months are great. Then "when will it be ready?" starts. By month 6, the team is burning out. By month 12, half have quit.

> Real example: A CRM rewrite for a distributor. Planned for 8 months. Delivered in 22 months. Budget tripled. First six months after launch spent fixing missing business logic bugs.

Strangler Fig Pattern — modular replacement

At AKDEV, we use an approach called the Strangler Fig pattern. In nature, a fig tree grows around a host tree, gradually enveloping it until the host dies off. The same works for legacy systems.

The idea: don't rewrite the whole system at once. Replace it module by module, one at a time, until the old system is no longer needed.

How it works in practice

Put a proxy layer (API gateway / reverse proxy) in front of the legacy system

2. Pick one module — the most critical, or the simplest

3. Rewrite it alongside the legacy system

4. Route traffic to the new module through the proxy

5. Verify it works

6. Repeat for the next module

After N iterations, the entire system is replaced. Zero downtime. Zero lost transactions.

Why it works

• Business keeps running — each module is replaced independently

• Minimal risk — if the new module fails, the proxy routes traffic back to the old one

• Visible progress — a working result every 2-4 weeks

• Controlled budget — you can stop at any point, the system is already working

• Business logic preserved — the old module serves as living documentation

Case study: modular legacy replacement

One of our projects involved replacing an old accounting system that had been running for over 5 years. Dozens of reports, government integrations, business logic nobody documented because "it just works."

We split the system into 4 modules and replaced them one by one.

• The first module was built quickly, but it didn't sync back with the old system. The procurement team had to work in two systems in parallel until we fixed the integration.

• One module stayed in the old version longer than planned — the external service it integrated with changed its API, and we had to rewrite twice in six months.

• After switching inventory management, stock levels diverged in the first week. Turns out the old system had a nightly cost recalculation everyone had forgotten about.

The system was replaced in 6 months. No full business shutdown. No data loss. But with compromises: one module stayed in hybrid mode (old + new), synchronization needs maintenance, and the accounting team cursed us a few times over diverging stock levels — until we fixed it.

The modular approach didn't make the project perfect. It made it manageable. We could fix problems one at a time instead of dealing with the fallout of a single big release.

> Key takeaway: Legacy replacement isn't a sprint — it's a series of trade-offs. The modular approach doesn't promise it'll be easy. It promises it'll be controlled. For a business, that matters more.

Modular replacement roadmap

Phase 1: Audit (1-2 weeks)

• Map all modules of the current system

• Identify dependencies between modules

• Pick the first candidate for replacement (independent and either critical or simple)

• Set up the proxy layer

Phase 2: First module (2-4 weeks)

• Build the new module with the same API contracts

• Test in isolation

• Route traffic through the proxy

• Monitor for a week

Phase 3: Cascade (2-4 months, parallel)

• Replace remaining modules

• Each module is a separate cycle: build → test → switch → monitor

Phase 4: Completion

• Remove legacy infrastructure

• Document the new architecture

• Hand off to the client's team

When does Big Bang actually make sense?

We're honest: there are cases where Big Bang works better:

The system is under 20,000 lines of code — easier to rewrite than to build a proxy layer

2. There's no working legacy — e.g., project documentation or a prototype

3. Complete business process change — if the new product is so different that incremental migration doesn't make sense

But in 90% of cases, modular replacement wins.

Conclusion

Rewriting legacy isn't a technical problem. It's a business problem. Your goal isn't "perfect code" — it's a working system with minimal risk.

Modular replacement (Strangler Fig) gives you a new system without downtime, without data loss, and without team burnout. It's boring, it's unheroic, but it works.

At AKDEV, we've done this on dozens of projects. If you have a legacy system that's "begging to be rewritten" — don't rush. Start with an audit and one module.