Migration auf Odoo 19: Praxisleitfaden für Unternehmen auf Version 14–17

Ihre Version ist älter, als Sie denken

Odoo veröffentlicht jedes Jahr eine neue Hauptversion und unterstützt jeweils nur die drei aktuellsten. Diese Rechnung ist unerbittlich: Wer 2022 mit Odoo 15 live gegangen ist, betreibt seit geraumer Zeit nicht mehr unterstützte Software. Odoo 16 ist mit dem Erscheinen von 19 aus dem Supportfenster gefallen. Odoo 17 ist als Nächstes an der Reihe.

Ohne Support heißt nicht kaputt. Ihr System verarbeitet morgen früh weiterhin Aufträge. Es bedeutet aber:

• Keine Sicherheitsupdates. Im Kern gefundene Schwachstellen bleiben auf Ihrer Instanz offen.
• Keine Fehlerbehebungen. Was ausfällt, wird zum Problem Ihres Entwicklungsteams — oder unseres.
• Ein Legacy-Aufschlag. Enterprise-Kunden auf nicht mehr unterstützten Versionen kann ein zusätzlicher Betrag auf das Abonnement berechnet werden — üblicherweise mit 25 % beziffert.
• Ein schrumpfendes Modul-Ökosystem. OCA und Drittanbieter stellen Backports ein. Neue Zahlungsdienstleister, E-Rechnungsregeln und Lokalisierungs-Updates erscheinen ausschließlich für aktuelle Versionen.
• Compliance-Rückstand. Genau dieser Punkt erzwingt bei europäischen Unternehmen meist die Entscheidung. E-Rechnungspflichten, Umsatzsteuer-Meldeformate und länderspezifische steuerliche Anforderungen werden über Lokalisierungs-Updates ausgeliefert — und die zielen auf unterstützte Versionen.

Je größer der Abstand, desto teurer der Sprung. Von 18 auf 19 ist ein Projekt. Von 14 auf 19 ist ein Neuaufbau mit Datenübernahme.

Jetzt auf 19 migrieren oder auf Odoo 20 warten?

Eine berechtigte Frage, denn Odoo 20 wird für Herbst 2026 erwartet. Unsere Antwort hängt von Ihrem Ausgangspunkt ab:

Sie sind auf 14, 15 oder 16 — gehen Sie jetzt auf 19. Sie sind bereits ohne Support, und jeder Monat erhöht das Risiko. Odoo 19 ist seit September 2025 im Produktiveinsatz, die Version ist stabil, das Modul-Ökosystem hat aufgeholt, und der Support läuft derzeit bis etwa September 2028. Das verschafft Ihnen zwei ruhige Jahre, bevor das Thema wieder ansteht.

Sie sind auf 17 — planen Sie den Wechsel für dieses Jahr. Sie stehen am Rand des Supportfensters. Der Sprung auf 19 bringt Ihnen den größten Puffer pro eingesetztem Aufwand.

Sie sind auf 18 — kein Handlungsdruck. Prüfen Sie die Neuerungen der 19 gegen Ihre Roadmap und erwägen Sie, im nächsten Jahr direkt auf 20 zu gehen.

Der Reflex, „einfach auf die neueste Version zu warten", geht meist nach hinten los. Eine Version, die letzten Monat erschienen ist, hat die dünnste Abdeckung durch Drittanbieter-Module und die meisten Kanten. Eine Version hinter der Speerspitze zu migrieren, ist fast immer die günstigere und ruhigere Entscheidung.

Zwei sehr unterschiedliche Wege: Enterprise und Community

An dieser Stelle werden Migrationsbudgets besonders häufig falsch eingeschätzt — deshalb hier ganz direkt.

Odoo-Enterprise-Kunden erhalten Zugang zum offiziellen Upgrade-Service von Odoo. Sie übermitteln eine Datenbank, die Plattform gibt sie in die Zielversion konvertiert zurück, und Sie können von jeder beliebigen Version direkt auf 19 springen, ohne die Zwischenversionen durchlaufen zu müssen. Der Service ist bei gültigem Abonnement enthalten und funktioniert gut — für Standardcode.

Odoo Community hat kein Gegenstück. Es gibt weder einen offiziellen Upgrade-Assistenten noch einen Ein-Klick-Weg. Ihre realistischen Optionen:

1. OpenUpgrade — das OCA-Projekt mit Migrationsskripten. Es bewältigt Schemaänderungen und Datentransformation, läuft aber Version für Version, und individueller Code erfordert weiterhin Handarbeit.
2. Migrationstools von Drittanbietern — mehrere Anbieter verketten die Versionsschritte inzwischen automatisch.
3. Neuinstallation mit Datenexport/-import — für kleine Datenbanken mit wenigen Transaktionen manchmal die pragmatische Antwort, allerdings verlieren Sie historische Datensätze, wenn der Export nicht sorgfältig geplant ist.

Welchen Weg Sie auch wählen, eines bleibt gleich: Odoo migriert seinen eigenen Code, nicht Ihren. Ihre individuellen Module bleiben Ihre Verantwortung.

Was tatsächlich bricht

Zwischen den Versionen 16 und 19 summieren sich die Änderungen auf Hunderte von Modelländerungen, Dutzende Modellumbenennungen, Modulzusammenlegungen, Feldumbenennungen und geänderte Constraints. In der Praxis trifft das vier Bereiche:

Individuelle Module. Veraltete APIs, entfernte Methoden, umstrukturierte XML-Views, geänderte Zugriffsregeln. Jedes eigene Modell, jede geerbte Ansicht und jeder eigene Bericht muss geprüft werden. Das ist fast immer der größte Posten im Migrationsbudget — und es ist normale Entwicklungsarbeit, die kein Skript abnimmt.

Drittanbieter- und OCA-Module. Erstellen Sie vor allem anderen ein Inventar aller installierten Module und prüfen Sie, ob ein 19er-Branch existiert. Manchmal wurde das Modul in den Odoo-Kern übernommen — gute Nachricht. Manchmal ist es verwaist, und Sie brauchen Ersatz oder eine Neuentwicklung.

Integrationen. Onlineshops, Zahlungsanbieter, Lagerscanner, externe APIs, BI-Werkzeuge. Alles, was per XML-RPC oder REST mit Odoo spricht, muss gegen das neue Schema getestet werden — umbenannte Felder brechen Integrationen lautlos.

Berichte und Druckdokumente. QWeb-Templates verändern sich zwischen Versionen. Rechnungen, Lieferscheine und Etiketten sollten Seite für Seite visuell geprüft und nicht als funktionierend vorausgesetzt werden.

Eine Migration, die nicht wehtut

Der Ablauf, dem wir bei jedem Upgrade-Projekt folgen:

1. Audit. Vollständige Aufnahme installierter Module, Anpassungen, Integrationen und Datenbankgröße. Daraus entsteht die belastbare Schätzung — und hier finden wir regelmäßig Module, die seit drei Jahren niemand geöffnet hat. Ballast zu deinstallieren ist die günstigste Migrationsarbeit überhaupt.

2. Testmigration. Spielen Sie eine Produktivkopie auf einem Staging-Server ein und führen Sie das Upgrade dort aus. Die Produktivumgebung bleibt unberührt. Dieser Lauf zeigt, wie lange die Konvertierung dauert — daraus ergibt sich Ihr Wartungsfenster.

3. Code anpassen. Individuelle Module werden auf 19 portiert, versionsverwaltet, parallel zur Datenbankarbeit. Drittanbieter-Module werden ersetzt oder aktualisiert.

4. Tests mit echten Anwendern. Nicht nur „startet es" — vollständige Geschäftszyklen. Vom Angebot bis zum Zahlungseingang. Vom Einkauf bis zur Bezahlung. Vom Fertigungsauftrag bis zur Lagerbewegung. Der Monatsabschluss. Setzen Sie Buchhaltung und Lagerleitung vor das Testsystem — sie finden Dinge, die ein Entwickler nie sieht.

5. Umstellung und Betreuung. Frisches Backup, finale Migration, Go-live im geplanten Fenster — meist an einem Wochenende. Danach enge Betreuung in den ersten Tagen, wenn die Anwender auf eine veränderte Oberfläche treffen und Kleinigkeiten auftauchen.

Zeitrahmen und Kostentreiber

Kleine Datenbank mit geringer Individualisierung: typischerweise 4 bis 8 Wochen von Anfang bis Ende. Mittelständisches Unternehmen mit umfangreichen Anpassungen, mehreren Integrationen und jahrelangen Transaktionsdaten: 3 bis 6 Monate.

Die Datenbankkonvertierung selbst ist oft der schnellste Teil — eine Datenbank unter 1 GB kann in Minuten konvertiert sein. Die Kosten bestimmen der Umfang der Individualentwicklung, die Anzahl der Integrationen, wie viele Versionen übersprungen werden und wie aufwendig die fachlichen Tests sind. Nicht die Größe Ihrer Daten.

Fehler, die uns immer wieder begegnen

• Migrieren ohne Audit. Was nicht inventarisiert ist, lässt sich nicht budgetieren.
• Die Testmigration überspringen. Erst während des Go-live festzustellen, dass die Konvertierung sechs Stunden dauert, ergibt einen unschönen Samstag.
• Das Thema als IT-Projekt behandeln. Eine Migration ist eine Überprüfung der Geschäftsprozesse. Anwender müssen die neue Version vor dem Go-live sehen, nicht am Montagmorgen.
• Toten Individualcode mitnehmen. Die Hälfte der Anpassungen in einer alten Odoo-Instanz löst Probleme, die Standard-Odoo inzwischen nativ abdeckt. Die Migration ist der richtige Moment zum Aufräumen.
• Kein Rollback-Plan. Eine getestete Wiederherstellungsprozedur, nicht nur „wir haben Backups".

Wo Sie anfangen

Wenn Sie auf 14, 15, 16 oder 17 sind, ist der erste sinnvolle Schritt nicht die Wahl eines Werkzeugs — sondern zu wissen, was Sie tatsächlich haben. Ein Audit Ihrer Module, Anpassungen und Integrationen macht aus „irgendwann sollten wir upgraden" ein abgestecktes Projekt mit echtem Zeitplan und echter Zahl.

Wir übernehmen Odoo-Migrationen von Anfang bis Ende: Audit, Portierung individueller Module, Testmigrationen, Umstellung und Betreuung nach dem Go-live — für Community wie Enterprise, on-premise wie auf Odoo.sh.

Kostenloses Erstgespräch vereinbaren — wir sagen Ihnen ehrlich, wie Ihr Upgrade aussieht, auch wenn die Antwort lautet: „Warten Sie noch ein Jahr."