ERP migration without downtime: Controlled switch from PlentyONE to Odoo
The shop will remain online. That's the short answer, and it will hold true 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 adjustment of just a few minutes. Everything else has long since been imported, validated, and tested multiple times. Where this level of detail is missing, the cut-over becomes a big-bang change with no fallback option.
This article shows the technical process: what happens beforehand, what happens on the deadline, and which architectural decision makes “Zero Downtime” viable in the first place.
What operational risks arise during an ERP migration?
Throughout the entire migration phase, PlentyONE remains the leading system for ongoing operations until the final cutover – there is no premature or gradual transfer of system leadership. This clear temporal separation prevents inconsistencies caused by parallel master datasets.
The real risks arise elsewhere: orders received during the switchover; inventory levels that change shortly before the cutover; prices that are updated while the import is already underway; and a checkout process 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 operate 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 transition, these third-party systems may receive outdated or contradictory information – a risk that must be considered in the planning just as much as the pure checkout operation.
Prepare for migration before the deadline
The comprehensive import of products, customers, and historical data takes place weeks before the actual switchover – not on the go-live weekend itself. For large amounts of data, validated datasets are bundled (for example, 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 generate duplicates. This is not a minor technical detail, but rather the prerequisite for being able to repeat test runs without having to reset the target system after each run.
This sequence follows a fixed, consistency-ensuring logic: Categories are imported first, 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 process terminates at that point instead of generating an incomplete dataset. Product images and technical PDF documents are deliberately transferred separately and asynchronously to avoid unnecessarily extending the core migration time with large amounts of binary data.
Buffering orders during the cut-over
Dynamic business data such as inventory levels and sales prices change continuously until just before go-live. Therefore, their transfer is never a one-time import, but consists of an initial import and subsequent delta synchronizations that transfer only the changes that have occurred since the full import.
For incoming orders, an asynchronous architecture using a message queue is recommended: A new order is written to the queue in milliseconds, and the checkout process is completed successfully for the customer immediately. 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 processed again later using exponential backoff – the checkout process itself remains completely unaffected.
This principle can also be applied to price and inventory changes: Customer-specific B2B prices, tiered discounts and purchase prices are also transmitted via structured price lists; any changes then flow back asynchronously to the frontend via the same queue architecture, instead of directly and synchronously influencing the checkout.
Zero-downtime deployment
"Zero downtime" should only be claimed where a concrete 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 doesn't have to wait synchronously for an ERP response, it remains available even when the ERP system itself is undergoing a switchover process.
Validating the go-live: The cut-over strategy
The migration is divided into two completely separate phases: the comprehensive full import weeks before the switchover and the short, final delta synchronization directly on the go-live day. The specific process is as follows:
- Write lock in ERP: The legacy system will be write-protected for the final synchronization. The Shopware frontend will remain accessible – incoming orders will be queued and processed after the switchover.
- Final Delta Sync: Only changes made since the full import will be synchronized.
- Validation: Automated consistency check of inventory, price and order data.
- Switching: After successful validation and a complete end-to-end test, formal release takes place – 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 irregularities occur after the switchover.
This short, controlled transition phase – typically a few minutes rather than hours – distinguishes a well-planned cutover from a risky "big bang" migration without a fallback option. It affects only the ERP level: A seamless replacement of the ERP system itself is technically impossible, but the online store remains unaffected.
Particular care is required when transferring inventory: Odoo manages current stock levels based on events, which is why stock levels are not simply created as new data records, but rather transferred via a system-generated inventory count – this ensures a traceable, auditable history. Negative stock levels are identified before migration and, depending on the individual inventory strategy, transferred, corrected, or blocked.
We describe which specific errors most frequently lead to problems in this phase – from incomplete test migrations to missing retry logic – in PlentyONE Odoo migration errorHow your organic visibility is maintained during the same process is shown. SEO Migration Shopware 6.
The cutover is the final step in a process that begins weeks in advance. Our overview shows what precedes it. Migration from PlentyONE to Odoo.
Frequently asked questions about going live without downtime
How long does the actual switchover take during a cutover?
In a well-prepared migration, this typically takes only a few minutes – the time for the final delta reconciliation and validation. Only the ERP level is affected; the shop remains accessible throughout. The actual data processing effort takes place weeks beforehand during the full import.
What happens if a problem is noticed after the switchover?
A documented rollback plan is an integral part of any reputable cutover concept. Depending on the nature of the problem, targeted corrections can be made, or, in extreme cases, the system can be reverted to the old system – the latter being 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 in the queue and automatically processed after the switchover. That’s precisely what the asynchronous architecture is designed for.
Sources
The statements regarding inventory-based inventory 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 cutover concept tailored to your specific system landscape. This is exactly what we develop as part of our service. free, non-binding e-commerce audits.
✔ Free of charge ✔ No obligation ✔ Documented rollback plan ✔ Response within 24 hours
We cannot afford for our shop to be down for even a few hours.
He doesn’t have to. What actually happens on the cut-off date is a delta comparison lasting a few minutes and the migration of the ERP system. Everything else happened weeks beforehand, during normal operations, without any customer noticing.
Our order volume is particularly high on promotional days – does this make our cut-over riskier?
The cutover time can be deliberately scheduled outside of peak load periods. Additionally, the queue-based architecture ensures that even with high order volumes, no message is lost but is processed in a controlled manner.
How do we ensure that our team can react in an emergency?
A documented rollback plan determines 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.
