Back in 2000, Joel Spolsky called a full rewrite the single worst strategic mistake a software company can make. Twenty-five years later it's still mostly true, and AI has not changed that as much as people hope.
Almost every founder who calls me about an old system already has the answer they want. It's usually "let's rewrite it, this time properly". Sometimes that's right. Most of the time it's the expensive way to end up with the same problems plus a year of lost roadmap. Here's how I actually decide.
First, what's actually wrong?
Be specific about the pain, because the fix depends on it. The usual complaints fall into a few buckets.
- You can't hire for the stack, or nobody left understands it.
- You can't deploy safely, every release is scary.
- It's on an unsupported version with security holes you can't close.
- Adding a feature takes weeks when it should take days.
- It's slow or it falls over under load.
The key question hiding under all of these: is the problem the code, or the architecture and data model? Messy code you can clean up. A wrong core model you usually can't, not without real surgery.
When refactoring or hardening is the answer
If the system still makes money, the architecture is sound, and the data model is roughly right, you almost never need a rewrite. The code might be ugly, but ugly is cheap to fix compared to rebuilding. This is the case far more often than people expect. You harden the risky parts, add tests so you can change things without fear, upgrade the version, and clean up incrementally while it keeps running.
When a rewrite is actually justified
A few situations do call for it. The data model is wrong at the core and everything fights it. The stack is dead and can't be hosted or patched anymore. The product needs to do something the current shape simply can't support. Even then, a big-bang rewrite where you build for a year and flip a switch is the risky version. Replace it piece by piece instead.
The middle path most people skip
Replacing it piece by piece is what I reach for most. You build the new parts alongside the old system and move one piece at a time, until the old one is gone. The app keeps working the whole way. No feature freeze, no dramatic launch, no quarter where the business stands still. It's less satisfying than a clean slate and it's almost always the right call.
Where AI actually helps
This is the part that changed in the last two years. AI is genuinely good at the slow, mechanical work of modernization. It reads a 15-year-old codebase and explains what a function does. It generates the tests you never had, so you can refactor safely. It handles version upgrades and repetitive rewrites across hundreds of files. What it does not do is decide the architecture or recover the business rules nobody wrote down. That judgment is still yours. Used well, AI takes months off the boring parts and changes none of the thinking.
A quick decision rule
When I'm not sure, I answer four questions:
- Is the data model fundamentally wrong? If yes, lean rewrite. If no, lean refactor.
- Can you still run and deploy it safely today? If no, harden that first, before any big decision.
- Can you hire or keep people for this stack? If no, that pushes toward modernizing onto something current.
- Does it still make money? If yes, protect it, change it gradually, do not gamble it on a rewrite.
Sitting on an old system and not sure which way to go? I'll look at it, tell you straight whether to harden, modernize, or rewrite, and my team at Fingoweb can do the work.
Book a 30-minute call → Other ways to reach me