By the time a business reaches the switch-over, the new ecommerce platform has usually been chosen. The worry has moved. It is now about the days around the change: orders still arriving from the online store, sales reps and marketplaces, stock moving in the warehouse, customer prices sitting in the ERP, and two systems that both think they are in charge.
Ecommerce replatforming succeeds or fails on that stretch of days. The new ecommerce store can be well built and still cost the business orders if open orders are lost, stock is promised twice or a wholesale customer sees the wrong price on the first morning. This article is about the decisions that shape the switch-over itself: what has to agree on day one, how to cut over, which system owns each piece of data while both are running, and how to tell that the day has come. Each choice has a trade-off, and the right one depends on how your business takes orders.
What has to agree on the first day
In any ecommerce replatforming, on the first day on the new system, a short list of things has to match what the business, the ERP and the customer expect. Everything else can be tidied in the following weeks.
Open orders and their status
Orders taken on the current platform and not yet shipped, invoiced or refunded have to be finished somewhere. Either they stay on the old system until they close, or they move to the new one with their status intact. The ERP and the warehouse have to know which system each order belongs to.
Stock levels and reservations
Stock on the new system has to equal what the warehouse holds, minus what open orders have already reserved. A reservation that exists on the old system and not on the new one is how the same unit gets sold twice.
Customer-specific prices and terms
Trade customers expect their own prices, payment terms and order minimums when they log in. These usually come from the ERP, and the new system has to show the same figures the ERP would invoice.
Gift cards and store credit
Balances have to arrive with the right amounts, and finance should be able to reconcile them against the old system on the day.
Customer accounts
Customers need to be able to log in, or to know in advance that they will set a new password. Company accounts with several buyers need each buyer’s access checked.
URLs and redirects
Every product, category and content address with traffic or links needs a redirect to its new location, tested before the switch.
The direction of every sync
For each flow between the store, the ERP, the warehouse and each marketplace, write down which system sends, which receives and which wins on conflict. Most switch-over problems trace back to a flow that pointed the wrong way for a few hours.
Questions owners ask about ecommerce migration
What is ecommerce replatforming?
It is moving a business’s online selling from its current ecommerce platform to another one, together with the data, integrations and processes around it. Moving the products, customers and orders is one part of it. The switch-over, when the new system starts taking orders, is where most of the risk sits.
Should we switch over in one weekend or run both systems for a while?
That depends on how many channels feed orders in and how tightly they are tied to the ERP. A single weekend keeps the period of two systems short. Running both lowers the size of each step but means two systems must agree for longer.
What is a freeze window?
It is a period around the switch when certain changes stop: no new products, no price changes, sometimes no orders on one channel. It keeps the data still while it moves, and it costs the business whatever it would have sold or changed during that time.
Is data migration the same as replatforming?
Data migration is one piece of it: copying products, customers, orders and balances from the old ecommerce platform to the new one and checking they arrived intact. Ecommerce replatforming also covers the integrations, the redirects, the staff routines and the switch-over day.
Which data moves once and which keeps syncing?
History usually moves once: past orders, old customer records, content. Live data keeps syncing until the old system is switched off: stock, prices, open orders and anything a channel or the ERP still updates.
How do we know we are ready to switch?
When a full rehearsal on a copy with real data has run cleanly, the checks on orders, stock and prices match, and the team knows how to step back if something fails on the day.
Ecommerce replatforming: the cutover choices and their trade-offs
One weekend, or a period of running both
A single switch over a weekend or a quiet night means one moment when the old system stops and the new one starts. The period when two systems hold live data is short, and so is the time staff spend working in both. The trade-off is that everything has to be ready at once, and a problem found on Monday morning affects every channel together.
Running both for a period, for example by moving one channel, one market or one customer group at a time, makes each step smaller and easier to reverse. It also means two systems hold live orders and stock at the same time, every sync has to work in both directions for longer, and staff need to know which system to use for which customer.
Whether to use a freeze window, and how long
A freeze keeps data still while it is copied and checked. Freezing product and price changes for a few days is common and usually costs the business little. Freezing orders on a channel stops sales on it, so the decision is about which channels can pause and for how long, and how customers are told.
What moves once and what keeps syncing
Data migration for history is usually done more than once: a first full copy for testing, then a final copy of whatever changed since, taken during the freeze. Each copy is checked the same way, with counts and a sample compared record by record.
Moving history once keeps the switch simple, and it needs a clear cut-off date so nothing falls between the two systems. Keeping live data in sync until the old system goes dark protects against gaps, and it needs someone watching every sync until that day.
| Choice | Option A | Option B | What it asks of the business |
|---|---|---|---|
| Cutover | One weekend switch | Run both for a period | Everything ready at once; or syncs and staff working across two systems for longer |
| Freeze window | Freeze products and prices only | Freeze orders on some channels too | Agreement on what can pause, and notice to customers |
| Data | Move history once | Keep live data syncing until switch-off | A firm cut-off date, and an owner for every live sync |
Which system owns each field while both are running
For as long as both systems are live, every field that matters needs one owner. Stock might be owned by the ERP and read by both stores. Customer prices might be owned by the ERP and copied to both. Order status might be owned by whichever store took the order. Write this down as a short table, field by field, and agree it with the ERP partner, the warehouse and the people who run each channel. While the current platform and the new commerce platform both take orders, the table is the reference staff use when figures disagree. When two systems both think they own a field, the result is a price, a stock count or an order status that changes depending on where you look.
Some of this is easier to get right when the new system is designed for it. When KVY rebuilt the store for Above Diamond, a luxury jewellery business in Thailand, off WordPress onto a new commerce system, more than 150,000 diamonds were synced from supplier feeds and APIs, with unchanged records skipped, the sync running apart from the store and fallbacks when a feed is down, alongside three currencies and three payment gateways. The sync was designed as its own system so the store keeps selling when a supplier feed fails. In a different setting, a Malaysian paint manufacturer, live since January 2025, keeps a snapshot of price, unit and tax on each order line at the moment of sale and holds stock reservations as their own records, so stock is never promised twice. Both are choices about which record owns what, made before the first order arrives. For a business building a system of its own, this is a large part of custom ecommerce development.
What usually goes wrong, and what it costs
Duplicated orders
An order is created on both systems, or sent to the ERP twice, because two syncs picked it up. The warehouse may ship it twice, the customer may be charged twice, and someone has to unpick it by hand.
Stock promised twice
The old and new systems each believe they have the last unit. Two customers buy it, one order cannot be filled, and the business spends goodwill explaining the delay or the refund.
Prices that differ between systems
A trade customer sees one price on the new store and is invoiced another from the ERP. Each case is small, and together they erode trust with the customers who matter most to a wholesale business.
Old syncs left running
After the switch, a sync from the old system keeps sending stock or prices to a marketplace or the ERP. For days, two sources overwrite each other, and the numbers change for no clear reason. Listing every sync and switching each one off on purpose, with a named person checking, closes this gap.
Reports that miss a day
The first month-end includes orders from both systems. If finance reports from only one, sales and tax figures for the month are incomplete. Agree before the switch which report covers which days.
Rehearse, then decide the day has come
Rehearsal is the part of ecommerce replatforming that most often gets shortened when a date is close. Run the whole switch on a copy with real data at least once, ideally more than once. Time each step. Check a sample of open orders, stock counts and customer prices against the old system afterwards, and write down what had to be fixed by hand. Agree in advance how you would step back if something fails on the day, and who makes that call.
The day has come when a rehearsal has run without manual fixes, the field-ownership table is agreed, every sync has an owner, and the people taking orders on every channel know what changes for them. Until then, the date can move, and moving it is a normal result of a rehearsal that found problems.
If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.