Odoo 17 auf 19 upgraden mit OpenUpgrade

Kurz vorweg - was ein Odoo-Upgrade auf 19 wirklich bedeutet

OpenUpgrade ist der Open-Source-Upgrade-Pfad der OCA (Odoo Community Association). Es liefert Migrations-Analysen und Scripts, die dein Datenbank-Schema und deine Daten von einer Odoo-Major-Version auf die nächste heben - für die Standardmodule von Odoo SA. Das Repo liegt öffentlich auf github.com/OCA/OpenUpgrade.

Wichtig fürs Erwartungsmanagement: OpenUpgrade ist kein Knopf, den du drückst. Der offizielle Automatik-Service von Odoo ist eine andere Sache (dazu gleich mehr), und OpenUpgrade nimmt dir zwar den Core-Teil ab, aber nicht die Arbeit an deinen eigenen Modulen, Tests und der Sequenz. Der ehrliche Kern: Ein Upgrade auf Odoo 19 ist Handwerk, kein Automatismus. Wer das versteht, plant richtig - wer es unterschätzt, migriert im Blindflug.

Konkret installierst du für einen Lauf zwei Module in den Addons-Path der Zielversion: openupgrade_framework und openupgrade_scripts. Dazu kommt die Helper-Lib openupgradelib, jeweils in der aktuellen GitHub-Version. Die Zielversion klonst du dir direkt aus dem Repo:

git clone https://github.com/OCA/OpenUpgrade.git --branch 19.0 /opt/openupgrade

Zwei Dinge musst du vorweg wissen, weil sie den ganzen Rest bestimmen: Dein Upgrade-Weg hängt von deiner Edition ab (Community oder Enterprise), und du kannst Versionen nicht überspringen. Beides schauen wir uns jetzt der Reihe nach an.

Community vs. Enterprise - warum dein Upgrade-Weg von der Edition abhängt

Der Weg von Odoo 17 auf 19 ist nicht für alle gleich. Er hängt davon ab, ob du Community oder Enterprise fährst - weil Odoo den bequemen Automatik-Service nur an Enterprise-Kunden ausliefert.

Odoos offizieller Upgrade-Service unter upgrade.odoo.com migriert automatisiert. Aber: Die dahinterliegenden Scripts sind nicht Open Source und nur mit aktiver Odoo-Enterprise-Subscription nutzbar. Community-Nutzer haben diesen Service nicht. Für Community läuft das Upgrade über OpenUpgrade oder eigene ETL-Scripts - manuelle, Community-getragene Arbeit. Genau hier liegt der eigentliche Schmerz, um den es in diesem Guide geht.

Edition	Upgrade-Weg	Kosten	Support
Community	OpenUpgrade (OCA) oder eigene Scripts	Software gratis, Aufwand fällt an	Community / dein Team / Dienstleister
Enterprise	upgrade.odoo.com (automatisiert)	in der Subscription	Odoo SA, Scripts nicht offen

Wenn du auf der Community Edition sitzt, ist OpenUpgrade der realistische Pfad. Für Community-Edition-Hosting ist das der Standardweg - und der Grund, warum eine saubere Upgrade-Strategie bei Community mehr zählt als bei Enterprise, wo dir Odoo den Lauf abnimmt.

Der Sequenz-Zwang: 17 -> 18 -> 19, kein Überspringen

Du kannst nicht direkt von 17 auf 19 upgraden. Jeder OpenUpgrade-Branch migriert nur von der direkt vorigen Major-Version. Ein Sprung 17 -> 19 existiert nicht - du gehst Schritt für Schritt.

So sieht die Sequenz konkret aus:

1. 17 -> 18 mit dem OpenUpgrade der Zielversion 18. Erst wenn diese Datenbank sauber läuft und getestet ist, geht es weiter.
2. 18 -> 19 mit dem OpenUpgrade der Zielversion 19. Wieder mit Test, bevor irgendetwas produktiv wird.

Jeder Schritt braucht das OpenUpgrade der jeweiligen Zielversion. Das Überspringen einer Version wird schlicht nicht unterstützt.

Risiko-Callout: Wer versucht, eine Zwischenversion zu überspringen, hat keine passenden Scripts und riskiert eine inkonsistente Datenbank. Es gibt keinen unterstützten Shortcut. Plane zwei Migrations-Läufe ein, nicht einen - das ist bei einem Upgrade über mehrere Versionen der Normalfall, nicht die Ausnahme.

Wenn du wissen willst, welche Odoo-Version noch Support bekommt, lohnt sich der Blick vor der Planung: Odoo 19 ist die 2025er-Version und die ideale Zielversion, Odoo 18 (2024) wird unterstützt, Odoo 17 (2023) läuft aus. Odoo pflegt in der Regel die drei aktuellsten Major-Versionen und veröffentlicht jährlich ein Major-Release - danach gibt es keine Security-Fixes mehr.

Die Coverage-Falle bei einer frischen Odoo-Version

OpenUpgrade-Scripts sind bei einem neuen Odoo-Release nicht sofort vollständig. Das ist die Falle, in die man tappt, wenn man direkt nach dem Release upgraden will: Die Scripts für deine Module gibt es vielleicht noch gar nicht.

Ein Blick in die Historie macht das greifbar: Für Odoo 17 (Release Oktober 2023) war das grundlegende “base”-Modul erst rund ein Jahr später (Oktober 2024) fertig. Ein Jahr - für das Fundament, auf dem alles andere aufsetzt.

Die OCA hat den Prozess inzwischen umgestellt. Ein kleines Experten-Team (unter anderem Hunki Enterprises, Tecnativa, Forgeflow und GRAP) arbeitet auf Vertragsbasis daran. Das Ziel: eine minimal nutzbare Version rund im Januar, also etwa drei Monate nach dem Odoo-Release. Der Aufbau für v19 läuft als OCA-Crowdfunding in sogenannten “Lots”, die nacheinander abgearbeitet werden:

Lot	Modulbereich
1	base
2	product
3	account
4	stock
5	sale_management & point_of_sale
6	purchase & mrp
7	hr
8	project
9	website

Der Scope entwickelt sich mit den Beiträgen - was heute abgedeckt ist, hängt vom Fortschritt der Lots ab. Für dich heißt das konkret: Prüfe vor jedem Produktiv-Upgrade den Live-Stand der Scripts für deine eigenen Module. Der Stand steht im Scripts-Verzeichnis und in docsource/modules180-190.rst im 19.0-Branch. Die Coverage hängt von deinem Modul-Set ab - eine Standard-Buchhaltungs-Instanz ist früher dran als eine mit Projekt- und HR-Modulen.

Was OpenUpgrade NICHT macht - Custom- und Drittanbieter-Module

OpenUpgrade deckt die Standardmodule von Odoo SA ab. Deine Custom-Module und alle Drittanbieter- oder OCA-Module migrierst du selbst - mit eigenen Migrations-Scripts und Anpassungen an Feldern und Views. Das ist in der Praxis meist der größte Aufwandsposten, nicht der Core-Lauf.

Die typischen Bruchstellen, an denen es beim Upgrade knirscht:

• Deprecated Felder: Felder, die es in der neuen Version nicht mehr gibt und deren Daten irgendwo hinmüssen.
• Umbenannte Modelle: Modelle heißen anders, und dein Code sowie deine Daten referenzieren noch den alten Namen.
• Geänderte Views: XML-Views, die auf Elemente zeigen, die es so nicht mehr gibt.

Für jede dieser Stellen brauchst du eine eigene Migrationslogik. Genau deshalb ist die Aufwandsschätzung ohne Blick auf dein konkretes Modul-Set nichts wert: Zwei Instanzen auf derselben Odoo-Version können völlig unterschiedlichen Aufwand bedeuten, je nachdem wie viel Custom-Code und wie viele Drittanbieter-Module dranhängen.

Der getestete Ablauf - Testmigration auf Staging zuerst

Nichts geht live, bevor es auf Staging bewiesen ist. Ein Upgrade ohne vorherige Testmigration ist ein Blindflug - deshalb steht die Staging-Probe am Anfang, nicht am Ende. So läuft ein sauberer Upgrade-Ablauf - egal, ob du ihn selbst fährst oder dein Odoo-Partner ihn übernimmt:

1. Bestandsaufnahme: Version, Module, Datenmenge und Anpassungen aufnehmen. Erst wenn klar ist, was wirklich auf der Instanz läuft, lässt sich der Aufwand schätzen.
2. Testmigration auf Staging: Das Upgrade läuft zuerst auf einer echten Staging-Instanz durch. Nichts geht live, bevor es dort sauber passt.
3. Go-live: Geplantes Umschalten mit minimaler Downtime - inklusive DNS, Mail und Zertifikaten.
4. Nachlauf: Monitoring, Backup-Probe und Feinschliff nach dem Umschalten.

Ein Punkt, den man leicht übersieht: die Backup-Probe. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, keine Sicherheit. Deshalb wird die Wiederherstellung geprüft, nicht nur das Backup selbst.

Das Hosting-Setup hilft dabei: Bei erpdock spiegelt die Staging-Instanz die Produktion, und der Odoo-Core-Git-Ref wird pro Instanz gepinnt (Pin/Unpin). Upgrades laufen dadurch kontrolliert je Instanz - nicht global über alle. So testet ihr das Upgrade auf einer echten Kopie, statt an der Produktiv-Datenbank zu basteln - unabhängig davon, wer den Lauf am Ende durchführt.

Selbst machen oder machen lassen?

Die ehrliche Antwort: Es kommt auf dein Modul-Set und deine Zeit an. OpenUpgrade ist Open Source und kostenlos - die Software kostet dich nichts. Der Aufwand steckt woanders: in der Vorbereitung, der Migration deiner Custom-Module, dem Prüfen der Coverage und dem Testen.

Selbst machen ergibt Sinn, wenn du eine überschaubare Standard-Instanz hast, die passenden OpenUpgrade-Scripts für deine Module bereits vorliegen und du das Wissen im Team hast, um die zwei Migrations-Läufe (17 -> 18 -> 19) plus deine Custom-Module sauber durchzuziehen und zu testen.

Machen lassen kannst du es über einen Odoo-Partner, der die eigentliche Upgrade-Arbeit übernimmt. Was erpdock beisteuert, ist das Hosting: dein Odoo läuft EU-souverän, inklusive Staging-Instanz zum Testen - keine Kopie-Bastelei. Du hast keinen Partner? Frag bei uns an - wir bringen dich mit einem passenden Odoo-Partner zusammen. So oder so testet ihr auf einer echten Staging-Kopie, nicht an der Produktiv-Datenbank.

Wenn dein Upgrade zugleich ein Hoster-Wechsel ist, solltest du vorab die Datenhoheit beim Hoster-Wechsel klären - Migration und Datenhoheit gehören zusammengedacht. Den Gesamtüberblick - Migrationswege, Downtime-Planung und was vor jedem Umzug zu klären ist - findest du im Leitfaden Odoo migrieren und upgraden.

FAQ

Kann ich direkt von Odoo 17 auf 19 upgraden? Nein. OpenUpgrade migriert immer nur von der direkt vorigen Version. Du gehst 17 -> 18 -> 19, jeden Schritt einzeln, mit dem OpenUpgrade der jeweiligen Zielversion.

Ist OpenUpgrade kostenlos? Ja, es ist Open Source und wird von der OCA getragen. Der Aufwand steckt nicht in einer Lizenz, sondern in der Vorbereitung, den Custom-Modulen und den Tests.

Warum bietet Odoo selbst kein kostenloses Community-Upgrade? Der offizielle Service unter upgrade.odoo.com ist Enterprise-only, und seine Scripts sind nicht offen. Community-Nutzer sind deshalb auf OpenUpgrade oder eigene Scripts angewiesen.

Wie lange dauert ein Odoo-Upgrade? Das hängt von deinem Modul-Set und deinem Custom-Code ab. Der große Posten ist die Migration der Custom-Module und das Testen - nicht der eigentliche Core-Lauf von OpenUpgrade.

Muss ich vor dem Upgrade prüfen, ob OpenUpgrade meine Module unterstützt? Ja. Die Coverage hängt vom Fortschritt der OCA-Lots und deinem Modul-Set ab. Prüfe vor dem Produktiv-Upgrade den Stand der Scripts im 19.0-Branch (Scripts-Verzeichnis und docsource/modules180-190.rst) für genau deine Module.