Sequencing a composable migration so it can be cancelled at any point

The composable pitch is straightforward enough — separate the front end from the commerce engine, swap components as needed, stop being hostage to one vendor's release schedule. The pitch is fine. The sequencing is where most programmes come apart.

The failure mode is always the same

A team decides to go composable, picks four vendors at once, and disappears for eleven months. Somewhere around month seven the sponsor changes, the budget gets re-examined, and there is nothing shippable to point at. The programme is cancelled with all of the cost and none of the benefit.

The fix is not better project management. It is choosing an order where every step is independently worth doing, so that stopping after any of them still leaves you ahead.

Storefront first, always

The customer-facing front end moves first for three reasons. It is where the performance wins are, which means it is where the revenue case is. It can run against your existing backend through the platform's storefront API, so nothing behind it has to change. And it can be rolled out per route, which means the blast radius of a mistake is one page template rather than the whole business.

We ship the new front end on the least commercially sensitive route first — usually content or category pages, never checkout — and split traffic to it gradually. If the numbers are worse, the rollback is a config change.

Then search, then content, then checkout

Search comes second because it is the component with the clearest measurable ceiling on the incumbent platform, and because it is genuinely swappable without touching order data. Content comes third: moving to a headless CMS is disruptive to editorial workflow, so it needs the front end to already be stable.

Checkout comes last, if it comes at all. Plenty of businesses reach the end of a composable programme and decide their platform's checkout is fine. That is a legitimate outcome, and it is only available to teams that did not move checkout first.

What we insist on before starting

• A traffic-splitting mechanism at the route level, live in production, before any migration work begins.
• Performance budgets defined and enforced in CI, so "faster" is a number rather than a feeling.
• A written rollback procedure for each step, rehearsed at least once.
• An agreed measure of success per step that is not "the migration completed".

None of this is exciting. All of it is the difference between a composable programme that ships and one that becomes a cautionary slide in someone's conference talk.