Guide · E-commerce & Platforms
Replatform without breaking the business.
A replatform is open-heart surgery on a body that has to keep running. The store stays open while you rebuild it. We have carried the pager through one of these at scale, headless, on a live revenue line. Here is the order we would do it in, and the honest reasons to wait.
This guide, in 7 parts
The risk is the migration, not the platform.
Buying a better platform is the easy decision. Moving a live business onto it without dropping orders, losing search traffic, or double-charging customers is the hard one, and it is where the money goes.
Migration is repeatedly the riskiest part of the whole effort: the most-cited survey of large enterprises found more than 80% of data migration projects ran over time or over budget. We have seen aggregators put the over-budget figure near 64%; we flag that as directional, not a hard primary.
What is not in doubt is the stake. With e-commerce now near 17% of US retail sales, a storefront that goes dark is not an incident on a status page, it is revenue you do not get back.
« The store has to stay open while you rebuild it. That one constraint dictates the entire order. »
First, the honest test most agencies will not give you.
A replatform is the project. For most agencies it is also the revenue, so the advice to wait rarely arrives. We will give it. If any of these is true, stop and fix the underlying thing first. A replatform will not solve it, it will inherit it and charge you for the privilege.
- You cannot name the number this fixes. If there is no specific revenue, conversion, margin or speed figure that is capped by the current platform, you are buying a rebuild, not a return. Write the number down first, or do not start.
- The real problem is the org, not the stack. Slow releases are often a process and ownership problem wearing a platform costume. A new platform inherits the old way of working. Fix who decides and how you ship before you change what you ship on.
- You are inside ninety days of your peak season. Whatever your peak is, the window before it is for hardening and freezing, not cutting over. Replatform after the peak, never into it.
- Nobody owns the running of the new system after launch. If there is no named operational owner for day-two, you are funding a launch, not a platform. The project ends the day traffic moves, and that is the day the work begins.
- Your data is a mess and you plan to clean it during the migration. Migrating dirty data into a clean platform gives you a clean platform full of dirty data. Clean it first, in place, or scope the cleanup as its own piece of work with its own number.
- The whole case rests on the word headless. Headless is an architecture choice with real costs, not an outcome. If the only answer to why is the architecture, the case is not ready. Going headless adds an integration surface, and integration is where these projects slip.
None of these is a reason to never replatform. They are reasons to not replatform yet. Clear them, and the project that was going to overrun becomes one that ships.
What to migrate last, not first.
The instinct is to migrate the real thing first: customers, orders, the live data that feels like the business. That instinct is exactly backwards. The order below moves from the data that breaks quietly to the data that breaks on a live customer, so that by the time anything customer-facing moves, everything underneath it is already proven. Five phases. The hardest, most personal data goes last.
The platform skeleton, with nothing live on it
Stand up the new stack empty: the catalog model, the cart, checkout, the API layer, the CMS, the deploy pipeline. No traffic, no real orders, no SEO at stake. This is where you find out the platform cannot do something you assumed it could, while the cost of finding out is still zero. Most teams skip straight to data because data feels like progress. The skeleton is where the project is actually won or lost.
Reference data and the catalog, read-only
Products, categories, prices, media, the things that change slowly and break loudly. Migrate them, render them, and diff the new storefront against the old one page by page. Get the catalog correct and visible before a single customer or a single order depends on it. A wrong price or a missing variant here is a bug. The same mistake after cutover is a refund and a chargeback.
URLs, redirects and the SEO surface
Map every old URL to a new one and put the 301 redirects in before launch, not after. This is the single most common way a replatform quietly destroys the business: the site works, checkout works, and organic traffic falls off a cliff in week two because the redirect map was an afterthought. For a large catalog this is thousands of routes. Treat it as a deliverable with an owner, not a switch you flip at the end.
Integrations: payments, tax, ERP, OMS, fulfilment
The connectors to the systems that take money and move stock are the hardest part and the least visible in a demo. Integration is consistently named as a top cause of transformation slowdown, and it is where timelines actually go to die. Migrate these once the storefront they plug into is stable, so that when an integration misbehaves you know it is the integration and not everything at once.
Live customer state: accounts, sessions, carts, order history, subscriptions
Migrate the things that are different for every customer dead last, when everything they touch is already proven. Passwords and tokens, saved carts, loyalty balances, in-flight orders, active subscriptions. This is the data that, if you get it wrong, logs a customer out, empties their cart, or bills them twice.
It is also the data most teams migrate first because it feels like the real thing. Migrate it first and every later mistake lands on a live customer. Migrate it last and most mistakes never reach one.
Why a big-bang cutover is how you lose a peak season.
A big-bang cutover moves everything on a single date. It is attractive because it looks decisive and it fits a launch that has been promised up the chain. It is dangerous because it removes the two things that save a migration: a halfway state and a way back. When the first serious bug appears, and on a project this size one always does, there is no partial rollback. You are debugging live, on revenue, with everyone watching.
Do it the other way. Cut over in slices that match the order above, each on a base that already works, with a rollback at every step. Stand the skeleton up. Prove the catalog. Lock the redirects. Bring integrations across one at a time. Move live customer state last, in waves, watching the numbers.
And freeze. Whatever your peak is, the run-up to it is for hardening, not cutting over. The calendar is a hard constraint, not a preference: a cutover into a peak that goes wrong does not cost you a sprint, it costs you the quarter that pays for the year.
« You do not need a system that never fails. You need to catch the failure before it reaches a customer. »
The six ways these projects break.
Every one of these is avoidable, and every one of these is common. Name them before you start, because you will not name them mid-incident.
The big-bang cutover
Everything moves on one date, usually for a launch that cannot slip. There is no halfway state and no clean way back, so the first serious bug is now a business incident on live traffic. This is the single most expensive way to learn what you missed, and it is how teams lose a peak season.
The redirect cliff
URLs change, the redirect map is incomplete or late, and organic traffic collapses in the weeks after launch while everyone is still celebrating that the site is up. The store works perfectly and the revenue still falls, because the customers cannot find it.
Integration drift
Payments, tax, ERP and fulfilment connectors are wired late and tested less than the storefront, because they do not show up in a demo. They break in production, where they hold money and stock, and they are named again and again as the top cause of these projects running long.
The data-first trap
The team migrates live customer state early because it feels like the real work, then spends the project firefighting carts, logins and order history on real customers. The order is backwards: the most customer-sensitive data should move last, not first.
Scope you cannot see
A replatform quietly becomes a redesign, a re-architecture and a re-org at once, because all three were easy to bolt on. Three risky changes are now entangled in one launch, and you can no longer tell which one broke.
The orphaned platform
It launches, the partner rolls off, and nobody owns day-two. Small issues compound, nobody has the runbook, and within a quarter the shiny new platform is the new legacy nobody wants to touch.
When to bring us in.
You can run a lot of this yourself, and you should. The order above is not a secret, it is just discipline most plans drop under deadline. Bring us in when the project is already slipping and you need to find out why before you spend more, when the integration layer is where it is stuck, or when you are about to cut over on a live revenue line and want operators who have carried the pager through one of these.
We have done it: a headless e-commerce replatform at scale, on a real storefront, with the order and the freeze that kept it from losing a season. We tend to ask one question early that decides everything else. If the constraint is really how the floor works rather than the stack it runs on, we will tell you, even though it is a smaller engagement for us. That is the honest version, and it is the one that holds.
See E-commerce and platform builds, and the Hub Map, which is how we locate the real problem before anyone commits to a platform.
Replatform on the calendar?
No deck, no gate. A working session on your real migration plan, with the operators who would run the cutover, and an honest read on whether the order and the timing hold.
Frequently asked.
Our replatform is taking too long. What is usually the cause?
Almost always the integrations and the data, not the storefront. The storefront demos well and gets the attention, so it gets finished first. The connectors to payments, tax, ERP and fulfilment, and the migration of live customer state, are harder, less visible, and consistently named as the top cause of slowdown. If your project is slipping, look there before you add people to the front end.
Is headless commerce riskier to migrate to?
It carries a specific risk: more moving parts. Headless splits the storefront from the commerce engine and the content layer, which buys flexibility and adds an integration surface, and integration is exactly where these projects slip.
It is the right choice for some businesses and an expensive one for others. The deciding question is never is headless better, it is what number does this architecture move that a simpler one cannot. If you cannot answer that, you are not ready to go headless yet.
Big-bang cutover or phased migration?
Phased, in almost every case where revenue is live. A big-bang cutover moves everything on one date with no halfway state and no clean rollback, so your first serious production bug becomes a business incident. Phasing lets you prove the catalog, then the redirects, then the integrations, then live customer state, each on a stable base, and keep a way back at every step. Big-bang is how a peak season gets lost.
How do we protect SEO and traffic through a replatform?
Treat the URL and redirect map as a named deliverable from day one, not a task at the end. Map every old URL to its new home, put the 301s in before launch, keep your structured data and your fastest pages intact, and diff the new site against the old one page by page. The redirect cliff, where the store works but organic traffic collapses, is the most common silent failure of a replatform and the most avoidable.
When should we not replatform at all?
When you cannot name the number it fixes, when the real problem is how the organisation works rather than the platform, when you are inside the run-up to your peak season, or when nobody will own the system after launch. A new platform inherits your old way of working. If the constraint is the org and not the stack, a replatform spends a lot of money to move the same problem onto newer infrastructure.