Last week I said the rewrite you were quoted probably isn't the only option, and I meant it.
But I'd be selling you something if I left it there. Sometimes rebuilding is exactly the right call. I've told clients that, and I'll tell you that, and the difference between the two situations is worth more than either answer by itself.
So that's the other half of it. Three situations where starting over is honest, one that gets mistaken for them all the time, and the part of a rebuild that's actually dangerous.
When your business moved and the software didn't
Last week I said the question to ask is whether the software still describes how your business actually works. This is what it looks like when the answer is no.
You opened a second location. You added a product line that gets sold a completely different way. You went from selling a thing once to selling a subscription. Somewhere in there, the assumptions built into your software stopped matching the company you actually run.
You can feel this one without knowing anything about code. Every change costs more than it should. Simple requests get answers like "that's not really how the system thinks about it." Your staff maintain a spreadsheet on the side that holds the real version of something the software is supposed to hold. That spreadsheet is the tell. It exists because the software is describing a business you don't have anymore.
Software is mostly a pile of decisions about how your company works. That's what makes it expensive to build and expensive to throw away. And it's also why, when those decisions stop being true, you're not maintaining an asset. You're maintaining an argument you already lost.
When the foundation isn't old, it's gone
There's a real difference between behind and abandoned, and it gets flattened into "old" constantly.
The application I upgraded last week was years behind. That sounds bad and it's fine. The framework was still alive, still getting security fixes, and the path from the old version to the current one was a known piece of work that people have done thousands of times.
Abandoned is different. That's a language version that stopped getting security patches years ago with nothing to upgrade to. It's a framework whose maintainers walked away. It's a paid component from a vendor that doesn't exist anymore, sitting in the middle of your application doing something nobody can replace without unpicking it.
The plain test is hiring. Can you find someone to work on this who isn't the person who built it? If the honest answer is that the last guy who knew it retired, you don't have a maintenance problem. You have a single point of failure that happens to be shaped like software, and every month you wait, the pool of people who can help you gets smaller.
When the data is wrong underneath everything
This is the one nobody sees coming, because it doesn't look like a software problem. It looks like the software being annoying.
If the information itself is stored badly, everything built on top is a workaround. One field holding three different things depending on who typed in it. The same customer in there four times because nothing ever stopped it. Dates as text, so nothing can be sorted or totaled without somebody cleaning it by hand first. Every screen above that mess is compensating, and you can't fix a screen that's compensating for the floor.
The one I actually did
I've been on the other side of this. A few years ago I led the rewrite of a multi-tenant platform that dealerships around the country run their day on, and it was the right call and it was still the hard road.
The old one didn't scale, it was slow, and it was riddled with bugs. Read that list again, because it's the same list from last week's post, and last week I told you that list is usually a maintenance problem. What made this one different was underneath it.
It was one large application that did everything, built on a framework the company had outgrown, and the trouble wasn't that the framework was bad. It was that every new thing the business wanted to sell had to be bolted onto a system that assumed there was only one of everything. Multi-tenant means many customers on one platform, each needing their own version of things, and that's a very difficult shape to retrofit into software that wasn't built for it. We weren't fighting bugs. We were fighting an assumption baked in years earlier, and you can't patch an assumption.
So we rebuilt it, moved off the single application into separate services, and set one rule early: every service talks to every other service the same way, through a defined interface, no exceptions. That sounds like an internal detail and it's the reason the thing can grow now. When services are allowed to reach into each other however they like, you've rebuilt the same tangle with more moving parts and worse odds.
It took about a year, and I'm not going to dress that up. A year is a long time to ask a business to fund something it can't see.
So we didn't disappear for a year. Pieces of the new platform were in front of real users within weeks of starting, and it kept going out in pieces the whole way through. Nobody waited a year for anything. That's the difference between a rebuild that works and a rebuild that becomes a story people tell at your expense, and it's worth being blunt about. If somebody proposes rebuilding your system and the plan is that you'll see it when it's done, the plan is wrong. Ask what you get in the first month.
What came out the other side is the part that justified the year. Adding a new feature went from taking months to taking weeks, and for the smaller ones less than that. Client satisfaction went up 30 percent. And reliability went up 90 percent.
That last one is a word people use loosely, so here's what we actually measured it on: how often the servers were up, how often the application timed out on somebody mid-task, and how many bug reports came in from real users. All three moved, in the same direction, and stayed there.
That's the number I'd point at. Speed is nice and features are nice, but a platform that dealerships run their day on either works when they open it in the morning or it doesn't.
What isn't a reason
It's old. It's ugly. The developer you're talking to doesn't like the language it's written in.
None of those are reasons, and the third one is worth watching for. A developer who opens by telling you it should be rebuilt in something modern is telling you about their preferences, not about your business. An ugly admin screen is a real problem with a cheap answer, and last week's post is that answer: build a new interface on the same data and leave the working parts alone.
The part of a rebuild that actually goes wrong
It isn't the code. Writing the new thing is the predictable half.
It's the data. Getting years of real records out of a loose old system and into a strict new one is where rebuilds go long, every time, because the new system has rules and the old data doesn't respect them. That work is slow and unglamorous and it's almost always underestimated, including by me, which is why I'd rather tell you that up front than explain it in week nine.
And the other one is scope. The most common way a rebuild fails is that somebody rebuilds and redesigns at the same time. Now when something behaves oddly, nobody can tell whether it's broken or just new, your staff are learning a different process while doubting the software, and there's no version of the old behavior to compare against. Rebuild first, matching what you had. Improve it after, when you can tell the two apart.
And run both for as long as you can stand it. The rebuild I just described worked partly because the old system was still sitting there the whole time, so every piece we put in front of people was a thing we could take back out. Being able to undo a decision is worth paying for, and it's the first thing dropped when a project starts running late.
The honest version
If the software no longer describes your business, if the ground it's built on has been abandoned, or if the data underneath it is wrong at the root, rebuild it. Those are real, and I'll say so.
Everything else is maintenance wearing a rewrite costume.
And one thing holds either way. If somebody tells you to rebuild before they've looked, that's still a bad sign, even when rebuilding turns out to be the right answer. Being right by accident isn't the same as knowing. Ask what specifically is wrong, and see whether the answer sounds like someone who read your software or someone who'd rather not.
