Retail technology decisions have a gravitational pull towards the big replacement. The current estate is old, the integrations are fragile, and a single modern platform promises to make all of it somebody else’s problem.
Then it takes eighteen months, the business changes twice during it, and the thing that goes live is a slightly newer version of the same estate.
Why the big-bang keeps failing
Not incompetence. Structure:
Everything has to land together. Storefront, EPOS, stock, fulfilment and marketing all migrate at once, so nothing delivers value until all of it does. Risk concentrates instead of dispersing.
Trade does not pause. The estate being replaced is still running the business, still needs changes, and now needs them twice — once in the old system and once in the new.
The knowledge is in the exceptions. Twenty years of pragmatic decisions live in the current integrations. A rebuild rediscovers them one at a time, usually in production, usually in November.
Decide what stays
The more productive question is which systems you are keeping for the next five years. Almost always some are genuinely fine — the ERP works, the EPOS is serviceable, the fulfilment partner is contracted. What is actually painful is usually narrower: the storefront, one integration, and the reporting.
Naming what stays converts an open-ended programme into a bounded one. It also changes what you build: adapters and a clean contract, rather than a migration.
Build the seams
Where systems meet, put something you own:
- A contract between systems, versioned, so a supplier’s change is absorbed in one place rather than felt in four.
- An authoritative record for the things that cross boundaries — product, customer, order — that the systems reference.
- Observability at the joins. Most retail incidents are integration failures found by customers because nothing was watching.
Do that and replacing any single system later becomes a normal project rather than a programme, because the rest of the estate talks to your contract, not to it.
The version that works
Change one thing, in production, with the rest still running. Then the next. Each step delivers something and each is reversible. It is less satisfying than a clean architecture diagram and it is far more likely to still be true in three years.
We build this way as a matter of course — around what is staying as much as what is changing — because in most estates the systems that are staying outnumber the ones that are going.
One caveat
Occasionally the whole thing genuinely does need replacing: unsupported software, a vendor exiting, a compliance deadline. That is a real case and worth doing properly.
It is just far rarer than the number of programmes launched on the assumption.
Weighing up a replatform? Get in touch — we would rather talk you out of one you do not need. More on our retail work.