Ecommerce replatforming is usually described as moving your store from one selling platform to another. But if what actually hurts is stock accuracy, order handling and month-end close, the storefront is the wrong thing to move first — and the hard part of the project is deciding which system owns which data while both are running.
The triggers that actually push people to move — overselling, stock that disagrees with reality, a close that takes a week — are not storefront problems. A faster, better-converting storefront will not fix any of them. It will just carry them across.
This piece is about the other path, and specifically about the parts that are genuinely hard.
If your concern is preserving search traffic through the move, that is a different problem with a different playbook — we cover it separately in preventing traffic and revenue loss during an ecommerce migration. This piece assumes you have that covered and deals with operations.
Key takeaways
- Replatforming is not always a storefront decision. If the pain is stock, orders and reconciliation, the system of record is what’s moving.
- The hardest question is ownership during the overlap. While both systems run, exactly one of them must own each object — product, price, stock, customer, order, invoice.
- Cutover has a dependency order. Stock must be authoritative before order capture moves; order capture before fulfilment; fulfilment before invoicing.
- The stop-sell window is real and nobody plans it. There is a moment when you take your last accurate stock count, and a period where you are selling against it.
- Orders straddling go-live need an owner — which system picks, ships, invoices and accepts the return.
- Go-live is not “the site is up.” It is “orders, stock and cash reconcile between the two systems.”
Which layer actually needs to move
Before choosing a platform, work out which layer is causing the pain, because the answer changes what you are buying.
Presentation problems look like slow pages, poor conversion, a theme you cannot merchandise, a checkout that leaks customers. These are storefront problems, and replatforming the storefront solves them.
Operational problems look like the same unit sold twice, stock counts nobody trusts, a month-end close that takes a week, staff reconciling between two screens as a daily job. These live in the system of record. Moving the storefront leaves them exactly where they were.
Diagnose which one you have before you choose what to move. If it is presentation, replatform the storefront. If it is operations, the storefront may not need to move at all — and the project you are actually running is a different one.
Who owns what while both systems are running
This is the single most important table in the project, and the one most likely to be missing from your plan.
Running old and new in parallel for a period is standard practice. What usually goes unsaid is which system is authoritative for which object during that window — and that ambiguity is where the expensive failures live. Two systems that both think they own stock will oversell. Two systems that both issue invoice numbers will produce a duplicate.
Decide this per object, in writing, before anything moves:
| Object | Question to settle |
|---|---|
| Product and catalogue | Which system do staff create new products in? |
| Price and price lists | Where is a price change made, and what pushes it? |
| Stock on hand | Which count is the one you would trust to sell against? |
| Customer records | Where does a new customer land, and what deduplicates? |
| Orders | Which system captures, and which fulfils? |
| Invoices and credit notes | Which system issues the number, and in what sequence? |
| Returns in flight | Which system accepts a return against an old order? |
Every row needs exactly one answer, and every person touching the system needs to know it. “We’ll sort it out as we go” is how you end up reconciling two ledgers by hand at month-end.
What must move before what
Cutover is usually planned as a flat checklist. In practice it is a dependency chain, and getting the order wrong causes the failures people blame on the software.
- Stock has to be authoritative first. Until one system holds a count you would sell against, nothing downstream is safe to move.
- Then order capture. You cannot move where orders are taken until you trust the stock they are checked against.
- Then fulfilment routing. Picking, packing and carrier selection depend on orders being captured somewhere stable.
- Then invoicing. You cannot invoice reliably against orders that are still moving between systems.
- Then period close. Only once invoicing is stable can you close a month cleanly.
Each step is blocked by the one above it. In our experience this is where projects that looked well-planned come apart — a team moves invoicing early because finance is keen, and spends the next two months reconciling against orders that are still in transit.
The stop-sell window nobody plans
At some point you take your last accurate stock snapshot in the old system. From that moment until the new system is live and counting, you are selling against a number that is quietly going stale.
Three decisions to make deliberately rather than discover:
- When do you take the snapshot? Ideally at the lowest-volume point in your week, and after a count rather than from a system figure you have not verified.
- How long can you sell against it? That is your exposure window. The longer it runs, the more oversell risk you carry.
- What buffer are you holding? Many operations hold back a small safety margin on fast-moving lines through the window rather than sell to the last unit.
If you sell scarce or fast-moving stock, the stop-sell window is the single largest operational risk in the project, and the one most often left unplanned.
Orders that straddle go-live
An order taken the day before cutover has a whole life ahead of it — pick, pack, ship, invoice, possibly return.
Decide in advance which system carries it. Both answers are workable; the failure is not choosing.
Let the old system finish them. Cleaner accounting, because the order stays with the invoice and the credit note that may follow. The cost is running two fulfilment processes side by side, and staff needing to know which screen an order lives on.
Migrate them mid-life into the new system. Simpler day-to-day for the warehouse. The cost is that partial states — half-shipped, part-refunded, awaiting stock — are exactly the records that migrate badly.
Whichever you choose, write down the cutoff timestamp and make sure the warehouse knows it. The most common version of this failure is not a technical one; it is a picker looking in the wrong system and an order sitting unshipped for four days.
The financial close that straddles the move
This is the part that falls out of most migration plans, and the thing finance will ask about first.
Settle these before go-live:
- Invoice number continuity. Does the new system continue the sequence or start fresh, and can your accountant live with the answer?
- Open receivables. Invoices raised in the old system but unpaid at cutover — which system chases and reconciles them?
- Credit notes against old invoices. A return in month two against an invoice from month one needs somewhere to go.
- Tax jurisdictions and rates. These need to be right in the new system before the first invoice, not after.
- The straddling period itself. If you cut over mid-month, someone has to close a month that lived in two systems.
Cutting over at a period boundary costs you scheduling flexibility and saves you a genuinely painful reconciliation. In our experience it is worth the wait.
Define go-live as reconciliation, not uptime
A successful launch is usually defined as the site being up, fast, and converting. Those matter, and they are also the easy part to verify.
The harder and more useful acceptance test is whether the two systems agree:
- Do order counts match between old and new for the cutover period?
- Does stock on hand reconcile to a physical count, not just to the other system?
- Does the cash position agree — payments captured, invoices raised, credit notes issued?
A store that is up but cannot reconcile has not gone live; it has started accruing a problem. Set these three checks as the actual exit criteria and hold the project to them.
What it costs and how long it takes
In our experience an Odoo-based operational replatform runs from roughly $5,000 to $100,000 (USD), and the widest variable is how much of the configuration your own team absorbs rather than your size. Teams that learn the system and configure it themselves typically sit at $5,000–$10,000 and land in around four to eight weeks. Teams that hand it over entirely typically sit at $10,000–$100,000 and run three to six months, because discovery becomes a real project phase. We break the drivers down in what an Odoo ecommerce implementation actually costs.
The items that move the number most on an operational move specifically:
- Data quality in the system you are leaving. Migration cost tracks quality, not row count.
- How many objects genuinely need to move, versus which can be left behind as history.
- Whether you have someone who knows all your workflows. One person who can answer definitively is worth more to the budget than any module decision.
- Whether you cut over at a period boundary or reconcile a split month by hand.
Published replatforming costs almost always describe storefront moves, which is a different scope from moving the system of record. Compare them carefully rather than directly.
We worked through a real move of this shape — configurable products, trade pricing, freight — in our WooCommerce to Odoo migration case study and the broader ERP integration case study behind it.
When not to do this
If your storefront is genuinely the problem — slow, badly converting, hard to merchandise — then replatform the storefront, and the standard guides serve you well.
If you are on one channel with straightforward fulfilment and reconciliation is a monthly task rather than a daily one, you are early. Better tooling on your existing stack will carry you further than most ERP conversations suggest.
If nobody internally can answer process questions definitively, fix that before you start. Not because the project is impossible without it, but because it will cost several times more and you will own less of the result at the end.
The honest trigger for an operational replatform is not revenue. It is when the same reconciliation problem reappears every month and nobody can fix it inside the current system.
Frequently asked questions
What is ecommerce replatforming?
Moving an online business from one platform to another. The term usually refers to the storefront — swapping one selling platform for another. It can equally mean moving the system of record for stock, orders and accounting, with the storefront staying where it is.
Should I replatform the storefront or the back office?
Diagnose which layer actually hurts. If the pain is presentation, conversion or merchandising, move the storefront. If it is stock accuracy, order handling or month-end close, those are back-office problems and a new storefront will not fix them.
What is the biggest risk when replatforming?
In our experience it is ambiguity about which system owns which data while both are running. Two systems that both believe they own stock will oversell; two that both issue invoice numbers will duplicate one. Settle ownership per object, in writing, before anything moves.
What order should a replatform happen in?
Stock must be authoritative before order capture moves, order capture before fulfilment routing, fulfilment before invoicing, and invoicing before you attempt a period close. Each step is blocked by the one above it.
What happens to orders placed just before go-live?
Either the old system finishes them, which keeps accounting clean but means running two fulfilment processes, or you migrate them mid-life, which is simpler for the warehouse but risks partial states migrating badly. Pick one, write down the cutoff timestamp, and make sure the warehouse knows it.
When should we cut over?
At a period boundary if you can. Cutting mid-month means closing a month that lived in two systems, which is the most avoidable painful task in the whole project.
How do we know the replatform succeeded?
Not by the site being up. By whether order counts match between systems for the cutover period, stock reconciles to a physical count, and the cash position agrees on payments, invoices and credit notes.
Working out which layer actually needs to move
The diagnosis matters more than the platform choice. It takes someone looking at where your data disagrees with itself and what your close actually costs you each month.
Talk to us about your replatform →
About the author
Nguyen Tran is the founder of Ministers.io. He has spent five years working on Odoo ERP implementations — five delivered directly and more than twenty advised on — across ecommerce, retail, manufacturing, and maintenance, repair and operations (MRO).
