ERP Migration Without Downtime: Controlled Transition from PlentyONE to Odoo
The shop will remain online. That's the short answer, and it holds as long as one condition is met: The full import takes place weeks before the deadline, not on the go-live weekend.
What remains on the cut-off date is a final delta reconciliation of a few minutes. Everything else has long since been imported, validated, and run through multiple test cycles by this point. Where this approach is missing, the cut-over becomes a big-bang change without a fallback level.
This article describes the technical process: what happens beforehand, what happens on the cut-off date, and which architectural decision makes "zero downtime" feasible in the first place.
What operational risks arise when changing ERP systems?
Throughout the entire migration phase, PlentyONE remains the leading system for ongoing operations until the final cutover – there is no premature or gradual shift in system leadership. This clear temporal separation prevents inconsistencies caused by parallel master data records.
The real risks arise elsewhere: orders received during the switchover; inventories that change shortly before the cutover; prices that are updated while the import is already running; and a checkout that must not depend on the response time of an ERP system that is currently migrating.
An additional, often overlooked risk concerns external integrations: payment service providers, shipping providers, and marketplace connections continue to run unchanged during the migration and expect consistent status updates from the shop system. If the synchronization between the ERP and the frontend is interrupted during the conversion, these third-party systems can receive outdated or contradictory information – a risk that must be considered in the planning just as much as the checkout operation itself.
Prepare for migration before the cut-off date
The extensive full import of products, customers, and historical data takes place weeks before the actual switchover – not on the go-live weekend itself. For mass data, validated data sets are bundled (e.g., 500 customers or products per batch) and transferred in one go via the Odoo API, instead of being processed individually.
The specific ETL process is programmed to be idempotent: repeated processing of a data set does not create duplicates. This is not a technical side issue, but the prerequisite for test runs to be repeated without having to reset the target system after each run.
This sequence follows a fixed, consistency-ensuring logic: First, categories are imported, followed by manufacturers and attributes. Only then are the actual product templates created, and finally the specific product variants. If this sequence is not followed – for example, if variants are imported before their parent product – the import will stop at this point instead of creating an incomplete data set. Product images and technical PDF documents are deliberately transferred separately and asynchronously to avoid unnecessarily prolonging the core migration with large binary data.
Buffer orders during cut-over
Dynamic business data such as inventories and sales prices change continuously until immediately before go-live. Their transfer is therefore never a one-time import, but consists of an initial import and subsequent delta synchronizations, which exclusively transfer the changes that have occurred since the full import.
For incoming orders, an asynchronous architecture via a message queue is recommended: A new order is written to the queue in milliseconds, and the checkout is immediately completed successfully for the customer. A connector processes the queue in the background and transfers the orders to the new ERP system via the API. If the transfer fails, the message remains in the queue and is reprocessed later using exponential backoff – the checkout itself remains completely unaffected.
This principle can also be applied to price and inventory changes: customer-specific B2B prices, volume discounts, and purchase prices are also transferred via structured price lists; any changes are then fed back into the front end asynchronously via the same queue architecture, instead of directly and synchronously influencing the checkout.
Zero-downtime deployment
"Zero Downtime" should only be claimed where a specific architecture actually supports it – not as a blanket promise. The basis for this is the consistent decoupling of checkout and ERP communication via the described queue architecture: As long as the checkout does not have to wait synchronously for an ERP response, it remains available even when the ERP system itself is in the process of switching over.
Validating Go-Live: The Cutover Strategy
The migration is divided into two completely separate phases: the extensive full import weeks before the switchover and the short, final delta synchronization directly on the go-live day. The specific process:
- Write lock in ERP: The legacy system is set to read-only for the final reconciliation. The Shopware frontend remains accessible – incoming orders are queued and processed after the switchover.
- Final delta sync: Only the changes that have occurred since the full import will be synchronized.
- Validation: Automated consistency check of inventory, price, and order data.
- Switchover: After successful validation and a complete end-to-end test, formal approval is granted – Odoo takes over as the leading instance, and the buffered orders are processed.
- Monitoring: A documented rollback plan provides additional security for the entire process in case any anomalies occur after the switchover.
This short, controlled switchover phase – typically a few minutes instead of hours – distinguishes a cleanly planned cut-over from a risky "big bang" change without a fallback level. It exclusively concerns the ERP level: an uninterrupted replacement of the ERP system itself is technically not possible, but the shop remains unaffected.
The inventory takeover requires special care: Odoo manages the current stock on an event-based basis, which is why stocks are not simply created as new data records, but are transferred via a system-side inventory – this ensures a traceable, audit-proof history. Negative stocks are identified before migration and are transferred, corrected or blocked depending on the individual stock strategy.
We describe the specific errors that most frequently lead to problems in this phase – from incomplete test migrations to missing retry logic – in PlentyONE Odoo Migration Errors. SEO Migration Shopware 6 shows how to secure your organic visibility during the same process.
The cut-over is the final step in a process that begins weeks in advance. Our overview of the migration from PlentyONE to Odoo shows what precedes it.
Frequently asked questions about go-live without downtime
How long does the actual switchover take during the cut-over?
In a cleanly prepared migration, this typically takes only a few minutes – the time for the final delta reconciliation and the concluding validation. Only the ERP level is affected; the shop remains continuously accessible. The actual data effort is already completed weeks in advance during the full import.
What happens if a problem is noticed after the switchover?
A documented rollback plan is part of every reputable cut-over concept. Depending on the type of problem, either targeted corrections can be made or, in extreme cases, the system can be switched back to the old system – the latter is the reason why PlentyONE continues to run as the master system until the final cutover.
Can incoming orders be lost during the switchover?
No. The checkout remains accessible; incoming orders are buffered via the queue and automatically reprocessed after the switchover. This is precisely what the asynchronous architecture is designed for.
Sources
The statements regarding inventory-based stock transfer in Odoo are based on the official documentation: Odoo 19 – Inventory adjustments.
Have a cut-over planned
A low-risk go-live is not a matter of chance, but the result of a precisely planned cut-over concept for your specific system landscape. This is exactly what we develop as part of our free, non-binding e-commerce audits.
✔ Free ✔ Non-binding ✔ Documented rollback plan ✔ Response within 24 hours
We can’t afford to have our shop go down, even for a few hours.
He doesn’t have to. What actually happens on the cut-off date is a delta reconciliation of a few minutes and the conversion of the ERP system. Everything else ran weeks before, during normal operation, without any customer noticing.
Our order volume is particularly high on promotion days – is our cut-over then riskier?
The cut-over time can be deliberately planned outside of peak loads. In addition, the queue-based architecture ensures that no message is lost even with a high order volume, but is processed in a controlled manner.
How do we ensure that our team can react in an emergency?
A documented rollback plan specifies in advance who makes which decision in an emergency – instead of improvised reactions under time pressure on the go-live weekend.
Daniel Vogel
Daniel Vogel is the technical lead (Head of Development) at HQ GmbH. With his deep expertise in system architecture and Core Web Vitals, he leads the in-house development team on demanding e-commerce projects. His specialist area is complex replatforming scenarios, particularly the secure migration from Magento or Shopify to future-proof Shopware platforms.
In addition, he is the operational lead for technical emergency migrations and crisis management. When existing systems collapse under load or outdated code structures block growth, he designs and implements robust, high-performance architectures to get them back on track.
