Moving to a new e-commerce platform almost always starts with the same guide: export your data, map your URLs, set up 301 redirects, check your canonicals. All of that is correct, and all of it is the easy part.
In practice, things go wrong somewhere else. They go wrong in the weeks when you are running two systems side by side and they disagree about the same reality. Which stock figure is the real one? Which system is allowed to send that email? Who knows that the return has already arrived?
Why the standard guide isn't enough
Most migration guides are written by agencies that sell migrations. That doesn't make them unreliable, but it does make them one-sided: they describe the part of the migration the agency carries out and hands over. Data out, data in, redirects on, invoice out.
That part is technical work with a clear end point. You can check whether it worked: is the product there, does the old URL return a 301, did the title come across. Go or no-go.
The part nobody describes is the period afterwards. Your old system is still running, because you don't yet dare switch it off. Your new system is running alongside it. And as long as both are live, you have two sets of records that each believe they are right. That isn't a technical problem you fix with a script. It's an organisational problem you fix with sequence, and with agreements about who owns the truth.
The inventory nobody makes
Before you start, you make a URL inventory. Everyone knows that. But make a second list alongside it, and that one matters more: which systems write to the same truth?
Walk through your entire stack and note, for each system, not what it does but what it changes. Not "Klaviyo sends email" but "Klaviyo decides whether a customer gets an email and records that they received it". Not "the warehouse system displays stock" but "the warehouse system reduces stock when something is picked".
The moment two systems write to the same field, you have a migration risk. At Grill Bill there were more of those than we expected. Stock was touched by the webshop, the warehouse system, the bol.com integration and manual corrections. Four writers on one number.
That list determines your sequence. Systems with a single writer can be moved in any order. Systems with multiple writers move as a whole, in one go, with a hard cut-over. Skip that and you get exactly what this article is about.
Moving to a new e-commerce platform happens in phases, not overnight
The playbook above runs in eight phases, and the three that are missing from most guides are precisely the three that cost money: the integrations, the test order, and the moment you cancel your old system. We cover those separately below.
One principle runs through all of it. Anything with a single writer can move gradually. Anything with multiple writers, such as stock, orders and email, moves on a single day. That day is your go-live, and it's the only genuinely tense day in the whole project.
The integrations that don't come with you
Migrating products and customers is a matter of moving data. Integrations are not: you have to rebuild them, and some of them can't be brought across at all.
- Your payment provider. A new integration means new webhooks. Don't just test whether a payment succeeds, but whether the status update comes back. An order stuck on "pending" while the money is already in is something you'll hear about from the customer.
- Recurring mandates and subscriptions. Direct debit mandates and stored payment tokens are tied to your old account with the provider. If you run subscriptions or repeat purchases, this is the heaviest part of your entire migration and it deserves its own plan.
- Your invoice numbering. It has to run on. A new platform that cheerfully starts again at 1 will cause you a problem at the next audit.
- Shipping labels and the returns portal. Including the question of how you label a parcel that was ordered on the old platform.
- Feeds and marketplaces. Google Merchant Center, bol.com, your Meta catalogue. All of them point at URLs that are about to change.
- Measurement and consent. Analytics, your consent tool, the pixels. Get them ready before go-live, or you'll lose your baseline at exactly the moment you need it.
- Reviews. Collected reviews sit with your review provider, not in your shop. Reconnect them and match on EAN, not on product name.
The one-penny test order
There is exactly one check that counts, and it isn't a tick box on a list. Place a real order on the new platform, with a real payment of one penny, and follow it all the way through: does the order arrive, is the payment status right, does the confirmation email go out, is the invoice correct, does the label come out of the shipping integration, and can you then return and refund it?
Every step you skip here, you'll rediscover through a customer. Run this test with at least three kinds of product: a straightforward one, one with variants, and something awkward, such as a gift card, a digital product or a bundle. Those are the three places where it breaks.
Passwords don't come across
Customer accounts migrate fine. Passwords usually don't: platforms store them encrypted in their own format, and that format is rarely interchangeable. So you can't move them, and you certainly don't want them sitting somewhere in readable form along the way.
That means you make a decision before go-live, not after. Either you send everyone a reset email on the day of the switch, or you catch the first login attempt with a friendly screen explaining why things are different. What you shouldn't do is discover this on the morning you go live.
Handing over the data from WooCommerce
For WooCommerce shops the handover runs through our own WordPress plugin, neura-wp-woo-sync. You install it in the existing shop and it reads products, customers and orders straight out of the WooCommerce database. No home-made CSV export, then, and no manual field mapping you have to get right again every time you repeat it. It has a separate migration tab where you can move and verify each part in turn.
That makes it repeatable, and repeatable is what you want. You rarely get a migration completely right on the first attempt. The plugin exists for exactly that reason: we noticed we were doing the same manual work on the second migration as on the first.
Keeping your rankings
This is the part people fear most, and the part that goes wrong least, provided you do it boringly:
- Set your staging environment to noindex the moment you start building it. A second indexable version of your shop is the most expensive mistake available to you in week two.
- Map every existing URL, including how it performs: traffic, rankings, backlinks.
- Map them one to one onto the new structure and put the 301 redirects live on the day of the cut-over, not the day after.
- Don't forget the sold-out and discontinued products. That's the classic mistake: those pages look worthless, but they often carry links and traffic. Redirect them to a comparable product or to the parent category, not to the homepage.
- Lower your DNS TTL a day in advance. That turns the switch into minutes instead of hours, and the same goes for rolling back.
- Update your internal links to the new URLs. A working redirect is fine, but a link that points straight at the destination is better.
- Submit a new sitemap and keep a close eye on indexing for two to four weeks.
What broke
On the day of the cut-over, the stock count for one SKU was three units off the physical count. A small difference, and instructive for exactly that reason.
The cause: a bol.com return was still marked "in transit" in the old system while the box was physically already in the warehouse. The new system had counted the parcel, the old one hadn't. Both systems were right according to their own records. There was no bug.
This is why the cut-over has to be a hard break rather than a gradual transition. As long as two systems are both tracking where a parcel is, you get differences you cannot debug, because nothing is broken. All you can do is decide who is right from now on.
In practice: count physically on the day of the switch, set that figure as the truth, and revoke the old system's write access the same day. Not the week after.
Three points where you must be able to fall back
Plan your fallback points before you start, not when things go wrong:
- After the customer data import. Nothing has switched over yet. Falling back costs you a deleted import.
- Just before the cut-over. This is your last real way out. After it you've done a physical count you won't undo, and there are orders in the new system that can't come back.
- Before you move your advertising. Pausing campaigns and putting them back costs a day, not a week.
After the cut-over, falling back is no longer a technical action but a second migration in reverse. Know that, and make the decision deliberately.
When you're allowed to cancel the old system
Later than you think, and it's the dullest saving you can postpone. Your old platform can only go off once the last return window on an order placed there has closed, once your warranty and complaint records are readable elsewhere, and once your accounting no longer needs the closed financial year.
Budget for two to three months of overlap. During that period, do revoke write access; the old system should only be readable. A system you keep running out of caution is precisely the system that quietly pulls your records apart.
What it delivered
At Grill Bill we replaced twelve separate tools: Klaviyo, Trengo, Sendcloud, Pipedrive, Hootsuite and Mailchimp, plus six other places where work was sitting. Task management, product information management, the brand kit, EAN management, gift cards including physical ones, and the integrations themselves. We wrote that migration up in detail in the post-mortem of twelve tools becoming one.
The most interesting figure isn't the saving, it's the zero. In the 2023 season, Grill Bill burned €1,700 of ad budget on a product that was already sold out. Nobody did anything wrong. The stock level lived in one system and the campaign in another, and nothing made them talk to each other. That's exactly the kind of loss that never appears in a business case, because you only see it once it's gone.
The €1,310 a month saving is easy to calculate. So are the five hours of manual work per peak week. The improvement in ROAS is harder to attribute to a single cause, and we won't pretend it's entirely down to the migration. If you want to know what your own stack costs, you can work it out here, or put your current platform side by side with Neuramerce.
Where we are now
We've done three migrations and we want to move our own ten websites this year. The fourth is under way, and we deliberately picked the hardest one we could find: NomadFire, a complex WooCommerce shop with dozens of plugins, a course environment, recipe content and several languages. It has to be live by the end of September.
We're doing that not because it's easy, but because every migration that hurts exposes something that makes the next one easier.