Español
English
Català
Français
Português
Italiano
Nederlands
Polski
Wenn für Ihren Go-live auf Odoo 19 ein Termin in Sicht ist, wird der technische Teil der Migration (Schema aktualisieren, Module konvertieren, Daten verschieben) meist gut von denjenigen abgedeckt, die die Migration durchführen. Was dagegen häufig aus dem Projektplan fällt, ist alles rund um diese Migration: Daten, die schon im Ausgangssystem unsauber sind, Drittmodule, die nie wirklich getestet wurden, kein Plan für den Fall, dass etwas schiefgeht, oder ein Team, das am ersten Tag nicht weiß, wo das geblieben ist, was es täglich genutzt hat. Dieser Artikel fasst als Checkliste die sechs Bereiche zusammen, die sich in echten Migrationen als entscheidend erwiesen haben.
Kernaussage: Ein Go-live scheitert fast nie an einem einzigen großen technischen Fehler, sondern an mehreren kleinen Punkten, die niemand rechtzeitig geprüft hat: ein doppelter Stammdatensatz, der einen Bericht aus dem Gleichgewicht bringt, ein Drittmodul, das «eigentlich funktionieren sollte», aber nie mit echten Daten getestet wurde, oder ein Team, das in der ersten Stunde nicht wusste, was zu tun ist, weil ihm niemand den realen Ablauf gezeigt hat. Diese Checkliste deckt die sechs Bereiche ab, die nach unserer Erfahrung bei der Einführung von Odoo den Unterschied zwischen einem ruhigen Go-live und einem Feuerwehreinsatz ausmachen.
Warum die meisten Migrationen am selben Punkt kompliziert werden
Meist ist es nicht die technische Migration selbst (die Schema-Aktualisierung oder die Modulkonvertierung), die einen Go-live aus der Bahn wirft. Meist ist es einer der sechs Bereiche dieser Checkliste, der als erledigt galt, weil «das schon besprochen wurde», aber nie mit echten Daten oder schriftlich überprüft wurde. Sie vor der Terminfestlegung durchzugehen, verlängert das Projekt nicht: Es verhindert, dass der festgelegte Termin in letzter Minute verschoben werden muss.
Die vollständige Checkliste vor dem Go-live
Sechs Bereiche, je ein Kontrollpunkt und die Begründung, warum er kritisch ist: als Tabelle aufbereitet, damit Sie sie direkt mit Ihrem Team verwenden können.
Übersichtstabelle: die 6 Bereiche, die Sie prüfen sollten, bevor Sie den Go-live freigeben
| Bereich | Kontrollpunkt | Warum es kritisch ist |
|---|---|---|
| Stammdaten | Kontakte, Produkte, Preislisten, Steuervorlagen und Salden geprüft, ohne Duplikate und verwaiste Datensätze | Ein falsch migrierter Stammdatensatz fällt nicht im Moment der Migration auf: Er fällt Wochen später in einer Rechnung oder einem Bericht auf, wenn der Ursprung kaum noch zu finden ist |
| Drittmodule | Jedes installierte Modul (OCA oder proprietär) existiert in Version 19, wurde im Staging installiert und mit einem realen Anwendungsfall getestet | Ein Modul, das auf seiner Produktseite «als kompatibel geführt» wird, ist nicht dasselbe wie ein Modul, das mit Ihren Daten und Ihrem realen Ablauf getestet wurde |
| Staging-Umgebung | Kopie der Produktion mit echten Daten (keine Demodaten), in der mindestens ein realer Zyklus durchlaufen wurde: Auftrag, Rechnung, Zahlungseingang, Bestand, Bericht | Fehler mit Demodaten bilden Fehler mit echten Daten fast nie ab: Volumen, Formate, Grenzfälle |
| Rollback-Plan | Geprüftes Backup und ein dokumentiertes, erprobtes Verfahren für die Rückkehr zum alten System | Ohne einen erprobten Plan wird ein unvorhergesehenes Problem in den ersten Stunden der Produktion zu einem Betriebsstillstand ohne klaren Ausweg |
| Wartungsfenster | Zeitfenster mit geringem Verkehr festgelegt und dem Team sowie gegebenenfalls den Kunden mitgeteilt, mit Puffer über der geschätzten Dauer | Ein Go-live ohne klares Fenster lässt Benutzer im System arbeiten, während migriert wird, was das Risiko von Inkonsistenzen vervielfacht |
| Schulung des Teams | Jeder Benutzer hat im Staging die realen Aufgaben seines Arbeitsplatzes durchgeführt: Er hat nicht nur eine Demo gesehen | Der erste Produktionstag ist nicht der Zeitpunkt, um das System von Grund auf zu lernen |
Die sechs Bereiche im Detail
1. Saubere Stammdaten
Bevor ein Go-live-Termin festgelegt wird, sollte jemand aus dem Team (nicht nur, wer die Migration durchführt) doppelte Kontakte, Produkte ohne Code oder mit widersprüchlichen Preislisten sowie bei internationalem Geschäft die korrekten Steuervorlagen je Land geprüft haben, und ob die migrierten Buchhaltungssalden mit dem alten System übereinstimmen. Unsaubere Daten nach Odoo 19 zu migrieren, bereinigt sie nicht: Sie werden nur in ein neues System übertragen, in dem sie schwerer zu erkennen sind.
2. Drittmodule portiert und getestet
Jedes OCA- oder proprietäre Modul, das das Unternehmen nutzt, muss in Version 19 existieren und im Staging mit einem realen Anwendungsfall des Unternehmens installiert und getestet worden sein, nicht nur in einer sauberen technischen Installation. Es kommt häufig vor, dass man erst in der Produktion feststellt, dass ein laut Produktseite «mit 19 kompatibles» Modul bei einer bestimmten Datenkombination versagt, die vorher niemand getestet hat.
3. Staging-Umgebung mit echten Daten validiert
Das Staging taugt nicht als Validierung, wenn nur mit Demodaten getestet wird. Nötig ist eine Kopie der Produktion mit echten Daten (oder eine repräsentative Kopie), in der mindestens ein kompletter Zyklus durchlaufen wurde: einen Auftrag anlegen, abrechnen, Zahlung einziehen, Bestand bewegen und die Berichte erzeugen, die das Team jede Woche nutzt. Nur so finden Sie vor dem Go-live die Fehler, die erst bei realem Volumen und realen Fällen auftreten.
4. Rollback-Plan
Ein aktuelles Backup ist noch kein Rollback-Plan: Der Plan umfasst das geprüfte Backup (wiederhergestellt und kontrolliert, nicht nur erzeugt) und ein Schritt für Schritt dokumentiertes Verfahren für die Rückkehr zum alten System, falls der Go-live scheitert, mit den Rollen, wer die Auslösung entscheidet und innerhalb welcher Frist.
5. Wartungsfenster
Der Go-live braucht ein Zeitfenster mit geringem Verkehr, das dem Team und gegebenenfalls den Kunden rechtzeitig mitgeteilt wird, mit Zeitpuffer über der technischen Schätzung: Migrationen dauern fast immer länger als geplant. Den Wechsel vorzunehmen, während Benutzer im alten System arbeiten und migriert wird, ist eine der häufigsten Ursachen für inkonsistente Daten.
6. Schulung des Teams
Die Schulung, die einen Go-live trägt, ist weder ein allgemeines Handbuch noch eine passive Demo: Jede Person hat im Staging die konkreten Aufgaben ihres täglichen Arbeitsplatzes ausgeführt und weiß, an wen sie sich wenden kann, wenn am ersten echten Tag etwas nicht ihren Erwartungen entspricht.
Nützliche Links innerhalb von FlexigoTech
Wenn Sie lieber möchten, dass wir den gesamten Prozess übernehmen (Stammdaten, Module, Staging, Rollback und Schulung inklusive), deckt unser Service für die Migration auf Odoo 19 genau diese sechs Bereiche ab, bevor ein Go-live-Termin festgelegt wird. Und wenn Sie zusätzlich Prozesse abdecken müssen, die Standard-Odoo nicht löst (Logistik, Compliance, Marktplätze), können Sie unseren Modulkatalog ansehen, bevor Sie entscheiden, was migriert und was ersetzt wird.
Häufig gestellte Fragen
Was genau ist der Go-live bei einer Migration auf Odoo 19?
Der Go-live ist der Moment, in dem die migrierte und im Staging getestete Datenbank zum realen Produktionssystem wird: der Punkt, an dem das Team auf Odoo 19 zu arbeiten beginnt und das alte System getrennt oder eingefroren wird. Er ist kein isoliertes technisches Ereignis, sondern der Abschluss eines Validierungsprozesses (Daten, Module, Umgebung, Rückfallplan und geschultes Team), der Wochen früher hätte beginnen sollen.
Wie lange vor dem Go-live sollte die Staging-Umgebung bereitstehen?
Mit ausreichend Puffer, um vor der Terminfestlegung mindestens einen kompletten Testzyklus mit echten Daten, nicht mit Demodaten, abzuschließen: einen Auftrag anlegen, abrechnen, Zahlung einziehen, Bestand bewegen und die Berichte erzeugen, die das Team jede Woche nutzt. Wenn in diesem Zyklus Probleme auftreten, braucht es Zeit, sie zu beheben und den Test zu wiederholen. Je früher das Staging einsatzbereit ist, desto weniger Druck lastet also auf dem endgültigen Termin.
Was passiert, wenn ein Drittmodul nicht auf Odoo 19 portiert ist?
Wenn das Modul in Version 19 nicht existiert oder zwar existiert, aber niemand es mit echten Daten getestet hat, sollte es in der Checkliste nicht als erledigt abgehakt werden, auch wenn der Anbieter es als kompatibel bewirbt. Die Optionen sind: es vor dem Go-live selbst im Staging mit einem realen Fall testen, es durch eine native Alternative oder ein gleichwertiges Modul ersetzen oder genau diese Funktion zurückstellen, ohne den Rest der Migration zu blockieren.
Ist ein Rollback-Plan Pflicht, wenn im Staging alles gut getestet wurde?
Ja. Das Staging bildet nie 100 % der Produktionsbedingungen ab (reales Volumen gleichzeitiger Benutzer, laufende externe Integrationen, Lastspitzen). Der Rollback-Plan (geprüftes Backup und dokumentiertes Verfahren für die Rückkehr zum alten System) verhindert daher, dass ein unvorhergesehenes Problem in den ersten Stunden zu einem Betriebsstillstand ohne klaren Ausweg wird.
Woran erkenne ich, ob mein Team wirklich bereit für den Wechsel ist?
Wenn jede Person, die Odoo 19 am ersten Tag nutzen wird, im Staging und mit echten Daten die konkreten Aufgaben ihres Arbeitsplatzes durchgeführt hat (kein allgemeines Handbuch und keine passive Demo) und weiß, an wen sie sich wenden kann, wenn etwas nicht ihren Erwartungen entspricht. Eine theoretische Sitzung ohne Praxis in der realen Umgebung reicht fast nie aus, um den ersten Produktionstag zu tragen.
Was wir dazu tun
Sollen wir Ihre Migrations-Checkliste vor dem Go-live prüfen?
Wir helfen Ihnen, die sechs Bereiche anhand Ihres realen Falls (Daten, Module, Staging, Rollback, Fenster und Team) durchzugehen, bevor Sie den Termin festlegen. Schreiben Sie uns an comercial@flexigobe.com oder rufen Sie an unter +34 616 809 504.