You probably don’t need to start again.
The instinct when systems stop fitting is to replace all of it. That is usually the most expensive route available and the one most likely to fail halfway.
When a business finally accepts its systems are holding it back, the first proposal on the table is almost always total replacement. Rip it out, start clean, build the thing properly this time.
It is the most expensive option, it carries the most risk, and it throws away a decade of accumulated decisions that were mostly correct. Big replacement programmes fail regularly, and they usually fail late, after the money is spent.
Some of what you have is good
Buried in most systems that no longer fit is a set of things that work well. A process that has been refined over years. A data structure that turned out to be right. A report everyone depends on that took three iterations to get correct.
Total replacement discards those along with the problems, and then rediscovers them one at a time over the following eighteen months, usually via complaints.
Replacing everything means relearning, at full cost, all the things you already got right.
What we would look at first
Where people move data by hand between systems. Every one of those is a seam where something could join up.
- Which parts nobody will touch, and why. Fear is a reliable indicator of where the real fragility sits.
- What the CMS is being asked to hold that is not content.
- Which processes exist because of a software limitation rather than a business reason. Those are often years old and nobody remembers the constraint that caused them.
- What genuinely works and should be left alone.
Scope before you commit
A proper scoping exercise costs a fraction of a project and routinely changes what gets built. Sometimes it concludes that the sensible move is smaller than anyone expected. Occasionally it concludes the current system is fine and the problem is a process.
Either of those outcomes is worth paying for. The expensive mistake is committing to a large project based on a general feeling that things are not working.
Replace in pieces
Where replacement is right, it rarely needs to happen all at once. Take the part causing the most friction, replace that, run it alongside what exists, prove it works. Then take the next one.
It is slower on paper than a single programme. In practice it lands, because each stage delivers something usable and nothing depends on a switchover date eighteen months out.
If you take one thing
Before commissioning anything, get someone to map what you actually have and where the friction genuinely is. Not what the org chart says, what people actually do on a Tuesday. Most of the value in a systems project is decided before any of it gets built.
Three more
worth the time.
Travel is the clearest example, but the pattern holds in any sector: systems that used to take years to build are now a different size of problem entirely.
Your traffic can fall while your visibility rises. That sounds like agency nonsense until you look at where the answers are actually being read.
How we build new things has changed considerably. Who looks after the things we have already built has not, and will not for a long time yet.