Every ecommerce team we've spoken to has a version of the same story. The platform was chosen years ago. It has been patched, extended and worked around until nobody wants to touch it. Mobile pages are slow, checkout conversion is drifting down, and changing a product description still needs a developer. Everyone agrees it has to be replaced.
And usually, someone has already tried.
When we worked with a mid-market retailer on exactly this problem, they had been promised a new platform twice before. Both attempts stalled before anything reached customers. Nothing was wrong with the technology. The projects died because the scope kept growing and the plan depended on one big switch-over day that never felt safe enough to schedule.
Here is what we do differently.
1. Fix the scope before writing code.
Replatforms attract wish lists. Since we're rebuilding anyway, why not add loyalty points, a new recommendation engine, a redesigned account area and a B2B portal? Each idea is reasonable. Together they turn a three-month project into an eighteen-month one that never ships.
We start with a short discovery — two weeks is usually enough — and write down what the first release must do: a storefront customers can browse and buy from, a catalog the product team can manage on their own, and a checkout that is at least as reliable as the old one. Everything else goes into a phase-two list, in writing, where everyone can see it.
That list matters. It's how people agree to wait. Saying "not now" works when there's a real "later".
2. Never plan a big-bang cut-over.
The riskiest moment in any migration is the moment you switch all traffic from the old system to the new one. If anything is wrong — a payment edge case, a tax rule, a shipping zone nobody remembered — every customer hits it at once.
So we don't do that. We use what engineers call the strangler-fig approach: the new platform grows around the old one and takes over piece by piece.
In practice, that means sending traffic for a few product categories to the new storefront while everything else keeps running on the old platform. Real customers browse, add to cart and pay on the new system. You watch orders, payment success rates and support tickets for those categories. When they look healthy, you move the next set across.
By the time the last category moves, the new checkout has already handled real orders for weeks. The final switch is an ordinary day.
3. Run the data migration in parallel, not once.
Products, customers, order history, stock levels, discount codes — the data move is where hidden complexity lives. Ten years of data always contains surprises: duplicate SKUs, products with no category, addresses stored in three different formats.
Rather than one large export and import, we run the migration repeatedly against a copy of live data and compare the results with the source each time. Problems show up early, while there is still time to fix them properly. On cut-over day the migration has already been run many times, so it's routine.
While both platforms are live, stock and orders have to stay in sync between them. That sync layer is temporary, but it deserves as much care as the storefront itself. Overselling stock you don't have is the quickest way to lose a customer's trust.
4. Give the catalog back to the people who own it.
One of the clearest signs of an ageing platform is that business users depend on developers for routine changes. Updating a price, adding a product image or writing a seasonal banner shouldn't need a ticket.
This is where a headless setup helps. The storefront — the part customers see — is a separate, fast front end, often built with Next.js. Products and content are managed through an admin tool that the product team uses directly. Developers work on the storefront experience; merchandisers manage what's in it. Neither has to wait for the other.
Headless isn't right for everyone. If a hosted platform with a good theme already does what you need, that's often the simpler choice. But when the catalog is large, the content changes often, or mobile speed is a real competitive issue, separating the two pays off quickly.
5. Measure mobile speed on real phones.
Most ecommerce traffic is now on mobile, and much of it is on mid-range phones over patchy connections. A store that feels instant on a developer's laptop can feel sluggish in a customer's hand.
We set performance targets at the start, measure page load on mobile before and after, and keep monitoring after launch. In the retail project above, mobile pages loaded about three times faster than on the old platform. That came from a lighter front end, optimised images and caching. There was no single trick behind it.
6. Add the clever features after the foundation.
AI-powered product search, personalised recommendations and smart bundles are all worth having. But they're only as good as the catalog data and infrastructure underneath them.
With a clean, headless foundation, these features become much easier to add without touching checkout. For the retailer, natural-language product search — where customers type what they want in their own words rather than guessing the right keyword — was planned for phase two. It actually shipped before the end of phase one, because the new architecture made it straightforward to add on its own.
The short version
A successful replatform is mostly about reducing risk. Fix the scope. Move category by category. Run the data migration many times before it counts. Give the catalog to the people who own it. Measure what customers actually experience.
If your store is running on a platform everyone is afraid to touch, book a discovery call. We'll talk through what a safe migration would look like for your catalog, your integrations and your timelines. You can also read more about our work in our case studies.