Die Antwort in Kürze
Für eine Odoo Migration werden Datenquellen inventarisiert, Zielobjekte und Verantwortliche festgelegt, Dubletten bereinigt und Zuordnungen dokumentiert. Mehrere Testmigrationen prüfen Vollständigkeit und Folgeprozesse. Ein Odoo Versionsupgrade ist davon zu unterscheiden: Es hebt eine bestehende Odoo-Datenbank auf eine neuere Version.
Eine Migration übernimmt nicht die Vergangenheit – sie bereitet den künftigen Betrieb vor
Die wichtigste Migrationsentscheidung lautet nicht, wie alle Daten importiert werden, sondern welche Daten im neuen System tatsächlich benötigt werden. Aktive Stammkunden, offene Vorgänge, Bestände und relevante Historie haben unterschiedliche Zwecke. Dubletten, veraltete Adressen und unvollständige Artikel sollten nicht automatisch übernommen werden. Bereinigung ist fachliche Arbeit und benötigt verantwortliche Personen aus den jeweiligen Bereichen.
Mapping beschreibt mehr als Spaltennamen. Einheiten, Steuern, Preislisten, Varianten, Beziehungen und Status müssen fachlich zum Zielprozess passen. Mehrere Testimporte helfen, Transformationen zu stabilisieren und Laufzeiten zu kennen. Nach jedem Lauf werden Kontrollsummen, Stichproben und kritische Beziehungen geprüft. Technisch importiert bedeutet erst dann erfolgreich, wenn Nutzer reale Vorgänge damit fortsetzen können.
Für den Umstellungszeitpunkt braucht es einen Cutover-Plan. Er legt Datenstopp, finalen Export, Import, Abgleich, Freigabe und Rückfallentscheidung fest. Nicht migrierte Historie erhält ein kontrolliertes Archiv mit Zugriff und Aufbewahrungsende. So bleibt das neue System übersichtlich, ohne rechtliche oder operative Nachweispflichten zu verlieren.
Migration abnahmefähig machen
- Auswahl und Bereinigung vor dem Import
- Fachliches Mapping von Werten und Beziehungen
- Mehrere Testläufe mit Kontrollsummen
- Cutover-, Archiv- und Rückfallkonzept
Systemmigration und Versionsupgrade unterscheiden
Bei einer Systemmigration wechseln Daten und Prozesse aus einem Fremdsystem oder mehreren Quellen nach Odoo. Dabei müssen Datenmodelle, Begriffe und Abläufe neu zugeordnet werden. Ein Versionsupgrade bewegt dagegen eine bestehende Odoo-Datenbank auf eine neuere unterstützte Version.
Beide Vorhaben brauchen Tests, haben aber andere Risiken. Bei der Migration stehen Datenqualität und Mapping im Mittelpunkt. Beim Upgrade müssen zusätzlich individuelle Module, technische Abhängigkeiten und Änderungen der neuen Version bewertet werden.
1. Datenquellen und Eigentümer inventarisieren
Am Anfang steht eine vollständige Liste: ERP, Warenwirtschaft, CRM, Buchhaltung, Shop, Dateien, Datenbanken und persönliche Excel-Listen. Für jede Quelle werden Inhalt, Format, Qualität, Volumen, Aktualität und verantwortliche Fachperson dokumentiert.
Die fachliche Verantwortung darf nicht allein bei der IT liegen. Vertrieb entscheidet, welche Kundenmerkmale relevant sind; Lager und Einkauf prüfen Artikel, Einheiten und Lieferantenbezüge; Finanzen bewertet offene Posten und historische Anforderungen.
2. Entscheiden, was wirklich migriert wird
Nicht jede Altlast gehört in das neue System. Aktive Stamm- und Bewegungsdaten, offene Vorgänge und gesetzlich oder operativ benötigte Historie werden priorisiert. Alte Detaildaten können in einem revisionssicheren Archiv verbleiben, wenn sie im Tagesgeschäft nicht benötigt werden.
Diese Auswahl reduziert Aufwand und verbessert die Nutzbarkeit. Sie muss jedoch dokumentiert und mit Aufbewahrungs-, Auskunfts- und Reporting-Anforderungen abgestimmt werden.
- Aktive Kunden, Lieferanten und Produkte
- Offene Angebote, Aufträge und Bestellungen
- Bestände, Chargen und Seriennummern
- Offene finanzielle Vorgänge nach abgestimmtem Konzept
- Historie nur mit klarer Nutzung oder Pflicht
3. Bereinigen und Mapping dokumentieren
Dubletten, fehlende Schlüssel, uneinheitliche Einheiten, veraltete Adressen und freie Textwerte sind typische Probleme. Bereinigung sollte möglichst in der Quelle oder in einem kontrollierten Transformationsprozess erfolgen – nicht durch spontane Korrekturen während des finalen Imports.
Ein Mapping-Dokument beschreibt, welches Quellfeld in welches Odoo-Feld gelangt, wie Werte umgerechnet werden und welche Pflichtfelder ergänzt werden. Auch Beziehungen zwischen Kunden, Kontakten, Produkten, Varianten und Belegen müssen erhalten bleiben.
4. Testmigrationen mit echten Prozessen prüfen
Eine technische Erfolgsmeldung bedeutet nur, dass Daten geladen wurden. Fachliche Tests prüfen, ob mit ihnen gearbeitet werden kann: Lässt sich aus einem migrierten Kunden ein Auftrag erzeugen? Stimmen Einheiten und Steuern? Ist Bestand am richtigen Ort? Funktionieren Suche, Varianten und Belegbeziehungen?
Mehrere Testläufe sind normal. Jeder Lauf erhält messbare Abnahmekriterien, eine Fehlerliste und eine Entscheidung darüber, ob Quelle, Mapping, Konfiguration oder Prozess angepasst werden muss.
5. Cutover und Go-live vorbereiten
Der Cutover-Plan legt fest, wann Altsysteme eingefroren werden, welche Delta-Daten noch übernommen werden, wer den finalen Import prüft und ab wann Odoo führend ist. Rückfallkriterien, Kommunikationswege und Supportbesetzung gehören ebenfalls dazu.
Kurz vor dem Start werden keine neuen Datenregeln mehr erfunden. Kritische Abweichungen müssen entweder behoben oder mit einem transparenten manuellen Übergangsprozess abgesichert werden.
Checkliste für die Abnahme
Die Freigabe sollte fachlich, technisch und organisatorisch erfolgen.
- Datensummen und Stichproben stimmen
- Pflichtfelder und Beziehungen sind vollständig
- Kernprozesse funktionieren mit migrierten Daten
- Berechtigungen und Datenschutz sind geprüft
- Cutover, Support und Verantwortlichkeiten sind bestätigt
- Archivzugriff und Alt-System-Abschaltung sind geregelt
Datenqualität messbar abnehmen
Vollständigkeit wird mit Kontrollsummen, Stichproben und Beziehungen geprüft. Anzahl aktiver Kunden, offene Aufträge, Bestandswerte und Pflichtfelder sollten zwischen Quelle, Transformationsstufe und Ziel nachvollziehbar sein.
Zusätzlich prüfen Fachbereiche Nutzbarkeit: Sind Einheiten korrekt, Kontakte auffindbar, Preislisten zugeordnet und offene Vorgänge ausführbar? Technisch importiert bedeutet nicht fachlich akzeptiert.
- Kontrollsummen je Objekt
- Stichprobe kritischer Datensätze
- Beziehungen und Referenzen
- Pflichtfelder und Wertebereiche
- Abnahme durch benannte Fachverantwortliche
Archiv, Löschung und Datenschutz
Nicht migrierte Historie braucht einen kontrollierten Aufbewahrungsort mit Zugriffsregeln, Suchmöglichkeit und definiertem Ende. Ein altes System unbegrenzt weiterlaufen zu lassen, ist selten ein gutes Archivkonzept.
Personenbezogene Daten werden nach Zweck, Aufbewahrung und Rechtsgrundlage bewertet. Testumgebungen benötigen angemessenen Schutz; produktive Daten sollten nicht unkontrolliert in Schulungs- oder Entwicklungsinstanzen kopiert werden.
Zum Abschluss
Häufige Fragen zum Thema
Wie viele Testmigrationen sind notwendig?+
Es gibt keine feste Zahl. Üblich sind mehrere Iterationen, bis technische und fachliche Abnahmekriterien reproduzierbar erfüllt werden.
Müssen alle historischen Daten nach Odoo?+
Nein. Historie sollte nur übernommen werden, wenn sie operativ, analytisch oder rechtlich benötigt wird. Ein geeignetes Archiv kann für ältere Daten sinnvoller sein.
Was ist der Unterschied zwischen Odoo Migration und Upgrade?+
Migration meint meist den Wechsel aus einem anderen System nach Odoo. Ein Upgrade aktualisiert eine bestehende Odoo-Datenbank auf eine neuere Version.