ERP-Migration ohne Downtime: Kontrollierter Wechsel von PlentyONE zu Odoo
Der Shop bleibt online. Das ist die kurze Antwort, und sie hält, solange eine Bedingung erfüllt ist: Der Vollimport findet Wochen vor dem Stichtag statt, nicht am Go-Live-Wochenende.
Was am Stichtag übrig bleibt, ist ein finaler Delta-Abgleich von wenigen Minuten. Alles andere ist zu diesem Zeitpunkt längst importiert, validiert und mehrfach testweise durchlaufen. Wo dieser Zuschnitt fehlt, wird aus dem Cut-over ein Big-Bang-Wechsel ohne Rückfallebene.
Dieser Beitrag zeigt den technischen Ablauf: was vorher passiert, was am Stichtag passiert und welche Architekturentscheidung „Zero Downtime“ überhaupt erst tragfähig macht.
Welche Betriebsrisiken entstehen beim ERP-Wechsel?
Während der gesamten Migrationsphase bleibt PlentyONE bis zum finalen Cutover durchgehend das führende System für den laufenden Betrieb – es findet keine vorzeitige oder schrittweise Verlagerung der Systemführerschaft statt. Diese klare zeitliche Trennung verhindert Inkonsistenzen durch parallel geführte Master-Datensätze.
Die eigentlichen Risiken entstehen an anderer Stelle: Bestellungen, die während der Umschaltung eingehen; Bestände, die sich kurz vor dem Cutover noch ändern; Preise, die aktualisiert werden, während der Import bereits läuft; und ein Checkout, der nicht von der Antwortzeit eines gerade migrierenden ERP-Systems abhängen darf.
Ein zusätzliches, oft übersehenes Risiko betrifft externe Integrationen: Zahlungsdienstleister, Versandanbieter und Marktplatz-Anbindungen laufen während der Migration unverändert weiter und erwarten konsistente Status-Updates aus dem Shopsystem. Wird die Synchronisation zwischen ERP und Frontend während der Umstellung unterbrochen, können diese Drittsysteme veraltete oder widersprüchliche Informationen erhalten – ein Risiko, das in der Planung ebenso berücksichtigt werden muss wie der reine Checkout-Betrieb.
Migration vor dem Stichtag vorbereiten
Der umfangreiche Vollimport von Produkten, Kunden und historischen Daten findet Wochen vor der eigentlichen Umschaltung statt – nicht am Go-Live-Wochenende selbst. Für Massendaten werden validierte Datensätze gebündelt (zum Beispiel 500 Kunden oder Produkte pro Batch) und über die Odoo-API in einem Rutsch übertragen, statt sie einzeln zu verarbeiten.
Der konkrete ETL-Prozess ist idempotent programmiert: Wiederholte Verarbeitung eines Datensatzes erzeugt dabei keine Dubletten. Das ist keine technische Nebensächlichkeit, sondern die Voraussetzung dafür, dass Testläufe wiederholt werden können, ohne das Zielsystem nach jedem Lauf zurücksetzen zu müssen.
Diese Reihenfolge folgt einer festen, konsistenzsichernden Logik: Zuerst werden Kategorien importiert, gefolgt von Herstellern und Attributen. Erst danach entstehen die eigentlichen Produkt-Templates und schließlich die spezifischen Produktvarianten. Wird diese Reihenfolge nicht eingehalten – etwa weil Varianten vor ihrem Elternprodukt importiert werden –, bricht der Import an dieser Stelle ab, statt einen unvollständigen Datensatz zu erzeugen. Produktbilder und technische PDF-Dokumente werden bewusst getrennt und asynchron übertragen, um die Dauer der Kernmigration nicht unnötig durch große Binärdaten zu verlängern.
Bestellungen während des Cut-over puffern
Dynamische Geschäftsdaten wie Lagerbestände und Verkaufspreise ändern sich bis unmittelbar vor dem Go-Live kontinuierlich. Ihre Übernahme ist deshalb niemals ein einmaliger Import, sondern besteht aus einem Initialimport und nachfolgenden Delta-Synchronisationen, die ausschließlich die seit dem Vollimport entstandenen Änderungen übertragen.
Für eingehende Bestellungen empfiehlt sich eine asynchrone Architektur über eine Message Queue: Eine neue Bestellung wird in Millisekunden in die Queue geschrieben, der Checkout schließt für den Kunden sofort erfolgreich ab. Ein Connector verarbeitet die Queue im Hintergrund und überträgt die Aufträge über die API an das neue ERP-System. Schlägt die Übertragung fehl, verbleibt die Nachricht in der Queue und wird per Exponential Backoff später erneut verarbeitet – der Checkout selbst bleibt davon vollständig unberührt.
Dieses Prinzip lässt sich auch auf Preis- und Bestandsänderungen übertragen: Auch kundenindividuelle B2B-Preise, Staffelrabatte und Einkaufspreise werden über strukturierte Preislisten übertragen; jegliche Änderungen fließen anschließend über dieselbe Queue-Architektur asynchron in das Frontend zurück, statt den Checkout direkt und synchron zu beeinflussen.
Zero-Downtime-Deployment
„Zero Downtime“ sollte nur dort behauptet werden, wo eine konkrete Architektur das auch tatsächlich trägt – nicht als pauschales Versprechen. Die Grundlage dafür ist die konsequente Entkopplung von Checkout und ERP-Kommunikation über die beschriebene Queue-Architektur: Solange der Checkout nicht synchron auf eine ERP-Antwort warten muss, bleibt er auch dann verfügbar, wenn das ERP-System selbst gerade im Umschaltprozess ist.
Go-Live validieren: Die Cut-over-Strategie
Die Migration gliedert sich in zwei vollständig getrennte Phasen: den umfangreichen Vollimport Wochen vor der Umschaltung und die kurze, finale Delta-Synchronisation direkt am Go-Live-Tag. Der konkrete Ablauf:
- Schreibsperre im ERP: Das Altsystem wird für den finalen Abgleich schreibgeschützt. Das Shopware-Frontend bleibt dabei erreichbar – eingehende Bestellungen laufen in die Queue und werden nach der Umschaltung verarbeitet.
- Finaler Delta-Sync: Ausschließlich die Änderungen, die seit dem Vollimport entstanden sind, werden synchronisiert.
- Validierung: Automatisierte Konsistenzprüfung von Bestands-, Preis- und Bestelldaten.
- Umschaltung: Nach erfolgreicher Validierung und einem vollständigen End-to-End-Test erfolgt die formelle Freigabe – Odoo übernimmt als führende Instanz, die gepufferten Bestellungen werden abgearbeitet.
- Monitoring: Ein dokumentierter Rollback-Plan sichert den gesamten Prozess zusätzlich ab, falls nach der Umschaltung Auffälligkeiten auftreten.
Diese kurze, kontrollierte Umschaltphase – typischerweise wenige Minuten statt Stunden – unterscheidet einen sauber geplanten Cut-over von einem riskanten „Big Bang“-Wechsel ohne Rückfallebene. Sie betrifft ausschließlich die ERP-Ebene: Eine unterbrechungsfreie Ersetzung des ERP-Systems selbst ist technisch nicht möglich, der Shop bleibt davon aber unberührt.
Besondere Sorgfalt verlangt die Bestandsübernahme: Odoo verwaltet den aktuellen Lagerbestand ereignisbasiert, weshalb Bestände nicht einfach als neue Datensätze angelegt, sondern über eine systemseitige Inventur übernommen werden – das sichert eine nachvollziehbare, revisionssichere Historie. Negative Bestände werden vor der Migration identifiziert und je nach individueller Lagerstrategie übernommen, korrigiert oder gesperrt.
Welche konkreten Fehler in dieser Phase am häufigsten zu Problemen führen – von unvollständigen Testmigrationen bis zu fehlender Retry-Logik –, beschreiben wir in PlentyONE Odoo Migration Fehler. Wie der Erhalt Ihrer organischen Sichtbarkeit während desselben Prozesses abgesichert wird, zeigt SEO Migration Shopware 6.
Der Cut-over ist der letzte Schritt eines Prozesses, der Wochen vorher beginnt. Was ihm vorausgeht, zeigt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zum Go-Live ohne Downtime
Wie lange dauert die eigentliche Umschaltung beim Cut-over?
In einer sauber vorbereiteten Migration typischerweise wenige Minuten – die Zeit für den finalen Delta-Abgleich und die abschließende Validierung. Betroffen ist dabei nur die ERP-Ebene; der Shop bleibt durchgehend erreichbar. Der eigentliche Datenaufwand liegt ohnehin Wochen vorher im Vollimport.
Was passiert, wenn nach der Umschaltung ein Problem auffällt?
Ein dokumentierter Rollback-Plan gehört zu jedem seriösen Cut-over-Konzept. Je nach Art des Problems kann entweder gezielt nachkorrigiert oder im Extremfall auf das Altsystem zurückgeschaltet werden – Letzteres ist der Grund, warum PlentyONE bis zum finalen Cutover durchgehend als Master-System weiterläuft.
Können während der Umschaltung eingehende Bestellungen verloren gehen?
Nein. Der Checkout bleibt erreichbar; eingehende Bestellungen werden über die Queue gepuffert und nach der Umschaltung automatisch nachverarbeitet. Genau dafür ist die asynchrone Architektur ausgelegt.
Quellen
Die Aussagen zur Inventur-basierten Bestandsübernahme in Odoo basieren auf der offiziellen Dokumentation: Odoo 19 – Inventory adjustments.
Cut-over planen lassen
Ein risikoarmer Go-Live ist kein Zufallsprodukt, sondern das Ergebnis eines präzise geplanten Cut-over-Konzepts für Ihre konkrete Systemlandschaft. Genau das erarbeiten wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie Ihre Cut-over-Strategie technisch planen – kostenfrei und unverbindlich.
Jetzt Go-Live-Planung anfordern
„Wir können es uns nicht leisten, dass unser Shop auch nur für Stunden ausfällt.“ Muss er auch nicht. Was am Stichtag tatsächlich passiert, ist ein Delta-Abgleich von wenigen Minuten. Alles andere lief Wochen vorher, im laufenden Betrieb, ohne dass ein Kunde etwas davon gemerkt hat.
„Unser Bestellvolumen an Aktionstagen ist besonders hoch – ist unser Cut-over dann riskanter?“ Der Cut-over-Zeitpunkt lässt sich bewusst außerhalb von Lastspitzen planen. Zusätzlich sorgt die Queue-basierte Architektur dafür, dass auch bei hohem Bestellvolumen keine Nachricht verloren geht, sondern kontrolliert nachverarbeitet wird.
„Wie stellen wir sicher, dass unser Team im Ernstfall reagieren kann?“ Ein dokumentierter Rollback-Plan legt vorab fest, wer im Ernstfall welche Entscheidung trifft – statt improvisierter Reaktionen unter Zeitdruck am Go-Live-Wochenende.
✔ kostenlos ✔ unverbindlich ✔ dokumentierter Rollback-Plan ✔ Antwort innerhalb von 24 Stunden
Daniel Vogel
Daniel Vogel ist der technische Leiter (Head of Development) der HQ GmbH. Mit seiner tiefen Expertise in Systemarchitektur und Core Web Vitals führt er das In-House-Entwicklerteam bei anspruchsvollen E-Commerce-Projekten. Sein Spezialgebiet sind komplexe Replatforming-Szenarien, insbesondere die sichere Migration von Magento oder Shopify zu zukunftssicheren Shopware-Plattformen.
Darüber hinaus ist er der operative Lead für technische Notfall-Umzüge und Krisenmanagement. Wenn bestehende Systeme unter Last zusammenbrechen oder veraltete Code-Strukturen das Wachstum blockieren, konzipiert und implementiert er rettende, hochperformante Architekturen.
