Legacy Rewrite Math: How Projects Bleed Time and Money”

Because nothing says productivity like doubling your budget and standing still.

2025-09-15

Note: this is a fragment of a other article about rewriting legacy systems. Here we’re only sketching out how much a rewrite could cost. No recommendations — those live in the main piece. This section is just about the numbers.

Introduction

I’m about to shamelessly lie to you and juggle numbers, pretend the team is made up of developers only, and conveniently ignore management, testing, and basically everything else. We’ll simplify mercilessly.

Still, the overall results will be roughly as written here.
Don’t get your hopes up: if we try to refine the math model, no miracle will appear. A month longer, a month shorter — irrelevant.

We’re just going to take a peek down the rabbit hole and see how deep it goes — like Alice once did.

Initial Data

Let’s keep the picture pretty and the numbers round.

• We have a project. It’s a true legacy beast — the kind we all love to hate — and we want to rewrite it into something shiny and new.
• Project age: 10 years.
• Throughout all this time, 4 people have been working on it, producing about 600 hours a month.
• Total accumulated effort: 72,000 person-hours.
• And while we rewrite, the project doesn’t freeze — it keeps growing: +600 hours every single month.

Does the Codebase Keep Growing?

One might object: “But maybe those +600 hours each month are just bugfixes and support? Then we could ignore them.”

Maybe. Truth is, we don’t really know how those hours are being spent. It could be all bugfixes and maintenance just to keep the project afloat. Or it could be 600 hours of shiny new features every month.

The irony? This knowledge won’t save us. Even if we knew, the rewrite team wouldn’t be able to cleanly separate fixes from new functionality anyway. They’d still have to wade through every one of those 600 hours of monthly changes — at minimum analyzing and deciding what to do with them.

👉 So let’s take it as a given: the project grows by +600 hours every month.
Life is pain.

Who’s Going to Rewrite?

We’ve defined the scope; now let’s decide who’s going to do the rewriting.

The obvious but wrong option is: “Let the current developers rewrite it.”

Nope. You can’t just divert those 4 developers from what they’re doing. They’re the ones keeping the product moving forward, and if you switch them to rewriting, that’s pure opportunity cost. Meaning the business loses everything they could’ve delivered during that time: support, bugfixes, new features.

In short, the product stalls while the company keeps paying salaries for work that delivers no direct value.

❌ Not acceptable — keep those 4 on their current tasks.

👉 To rewrite, you’ll need to bring in new developers. At least the same number — another 4 developers, dedicated solely to rewriting.

Rewrite Speed

Yes, rewriting is always faster than greenfield development.

But how much faster?

• ×2 (plausible),
• ×4 (debatable),
• ×6 (very doubtful 🦄),
• ×8 (pure fantasy 🦄).

And note: those last two “dream teams” would be rewriting, in a single month with 4 people, the amount of code that originally took 3,600–4,800 person-hours to create. That’s already pure magic 🦄.

Scenarios and Timelines

Team of 4 (new, dedicated to rewriting)

Even in our imaginary dream🦄 scenarios (×6 and ×8), the timelines are still unacceptable.

So what happens if the rewrite team is doubled to 8 people?

Team of 8 (new, dedicated to rewriting)

Remember, those last two cases (×6 and ×8 with 8 developers) are pure magic 🦄.

Meanwhile, the budget compared to current development costs has already tripled.

Conclusion

I’ll spare you the exact words that would be used by the owner, the CFO, and other people who actually care about money.

P.S. In a more accurate model, the situation isn’t just worse than these sketches show — it’s considerably worse.