There are only three ways forward. Extend what you have, rebuild it, or hold as you are. Every quote you’ll ever receive is one of those three in different clothes.
This is written for the person who signs, not the person who codes. You don’t need to read the code to choose well. You need to know what each option buys, what it quietly costs, and who benefits from recommending it.
If you’re not yet sure the system has been outgrown at all, start with the signals — they show up in the business before they show up anywhere technical. This piece is about what comes after: you know something has to give, and three people have told you three different things.
Extend: right more often than developers admit, wrong in one specific way
Almost any system can be extended. That’s what makes this option dangerous. “Can it be done” is always yes, so it’s the wrong question.
The right question is what each change does to the next one. In a sound system, work compounds: the module you add this year makes next year’s cheaper, because the foundations expected it. In a system that’s the wrong shape, every change gets threaded around behaviour that shouldn’t be there, and the next change costs more than this one did.
Extending the first kind is investment. Extending the second is rent. You pay for a rebuild in instalments, and at the end you don’t own one.
You can tell which you have without opening the code. Ask whoever maintains the system whether the change they’re quoting makes the following change easier, harder or neither. A maintainer who answers that question straight is worth keeping. One who answers “depends” every time is answering it too.
Rebuild: a new project, not a better version of the old one
The word suggests you’ll get what you have, but sound. That’s not what happens. A rebuild is a new software project, carrying all the risk the first one carried, plus two it didn’t: your live data has to move, and the business has to keep running on the old system while the new one grows up beside it.
There’s a third cost that never appears in the quote. The old system knows things nobody else does. Rules argued over years ago and settled in code. The special case for the customer who orders differently. The reason a record can’t be deleted after despatch. A rebuild has to rediscover all of it, and whatever gets missed turns up later, in production, in front of someone.
When rebuilding is right: when the model underneath is wrong. The system assumes one site, one currency, one way of pricing, and you stopped being that company years ago. No list of changes fixes a wrong assumption in the foundations.
Two things to watch in any rebuild proposal. First, a rewrite into a new stack “while we’re at it”. If nobody can say what the new framework buys your business, it’s buying the developer a nicer CV. Second, a plan with no section on data migration and no description of the switchover. That’s not a plan. It’s a brochure.
And a rebuild is rarely all or nothing. Usually one part of the system carries most of the strain, and that part can move out while the rest stays where it is. If a proposal only offers total replacement, ask why.
Hold: a decision, not the absence of one
Holding is legitimate, and it’s the cheapest option on the table. It’s also the one nobody will sell you, which is exactly why it needs saying out loud: sometimes the right answer is to do nothing yet.
But there’s a difference between holding and drifting, and it fits on one page. Holding means writing down what would have to happen for the answer to change — a growth threshold, the person who maintains the system leaving, a regulation landing, a market you decide to enter — and a date on which you’ll look again. Drifting is the same inaction without the page. The first is a position. The second is how companies end up choosing under pressure, on the day the system finally breaks, when every option left is worse than the ones they had.
If you hold, spend the time on the things that cost little now and a fortune later: make sure you actually hold the source code, the credentials, and an inventory you could hand to a stranger. A held system with its continuity in order is a postponed decision. A held system without it is a bet.
How to buy this decision well
You’re not choosing an option in the abstract. You’re choosing a proposal from someone. So judge the proposals.
Anyone who says “rebuild” before understanding what the business does hasn’t earned the answer. The recommendation should come after the questions about your operation, not before them.
Ask for the answer in writing, split three ways: what stays, what changes, in what order, and what happens to your data at each step. If one of the three options is dismissed in a sentence, ask for a longer sentence.
Then ask one more: if the budget were half, what would you do first? The answer tells you which part of the system is genuinely under strain. That’s the piece of information everything else in this decision hangs on.
The next step
If you’re weighing these three against each other, describe the system and where it hurts at get a proposal. You’ll have a written answer within 48 hours: which of the three it is, and why.