Odoo Community upgraden mit OpenUpgrade

Odoo Community bringt keinen Migrationsweg zwischen Hauptversionen mit; der Upgrade-Dienst von Odoo S.A. gehört zum Enterprise-Abonnement. Die offene Alternative ist OpenUpgrade, ein Projekt unter dem Dach der Odoo Community Association (OCA), mit Analyse, Framework und Migrationsskripten für den Sprung auf die nächste Hauptversion. Dieser Artikel zeigt den Weg am Beispiel 18.0 nach 19.0, mit Befehlen, Prüfabfragen gegen die Datenbank und einer Fehlerliste.

Was Sie vorab brauchen

• Shell-Zugang auf dem Server, auf dem Odoo und PostgreSQL laufen, und eine Datenbankrolle mit Lese- und Schreibrecht an der Odoo-Datenbank.
• Den Quelltext der Zielversion (hier Odoo 19.0) und eine Python-Umgebung, die genau diese Version ausführt.
• Die beiden OpenUpgrade-Module openupgrade_framework und openupgrade_scripts aus dem Zweig der Zielversion, erreichbar über den addons-path; in die Datenbank installiert werden sie nicht.
• Die Bibliothek openupgradelib, aus dem Master-Zweig des Quelltext-Repositorys installiert in dieselbe Python-Umgebung wie die Zielversion.
• Eine Sicherung von Datenbank und Filestore an einem Ort, den der Odoo-Server nicht erreicht (Backup-Strategie für Odoo).
• Ein Zeitfenster für mehrere Testläufe; die Dokumentation rechnet damit, dass Sie Daten aufräumen und den Lauf wiederholen.
• Kenntnisse auf der Kommandozeile und in SQL: Odoo-Instanzen beider Versionen starten und den odoo-Befehl mit Optionen aufrufen.

Welchen Versionssprung OpenUpgrade abdeckt

Jeder OpenUpgrade-Zweig migriert genau einen Schritt: Der Zweig 19.0 hebt eine Datenbank von 18.0 auf 19.0. Mehrere Versionen gehen nur nacheinander, das Überspringen einer Version wird nicht unterstützt.

Am 14. Oktober 2026 war 19.0 das höchste abgedeckte Ziel. Der Zweig 20.0 war zwar angelegt, enthielt aber erst das Grundgerüst ohne die beiden Module und ohne Migrationsskripte (letzter Stand: Initial-Commit vom 28. September 2026). Eine Datenbank auf 19.0 wartet also auf die Abdeckung des nächsten Schritts oder auf selbst entwickelte Skripte; vor der Entscheidung den Zweigstand erneut prüfen.

Für jeden Schritt listet die Abdeckungstabelle (Coverage Analysis) jedes offizielle Modul mit einem von drei Status: Done, Skripte liegen fertig bei; Nothing to do, die Analyse ergab nichts zu tun; leerer Status, noch nicht abgedeckt. In der Tabelle für 18.0 nach 19.0 trugen am 14. Oktober 2026 von 653 Einträgen 101 den Status Done, 179 Nothing to do und 373 keinen Status (eigene Zählung). Die Dokumentation warnt: Fehlen Skripte für installierte Module, kann die Migration scheitern oder die Datenbank inkonsistent hinterlassen. Bei Modulen ohne Status lohnt ein Blick in die offenen Pull-Requests des Repositorys, dort liegen Arbeiten im Entwurf.

Der offizielle Weg ist ein anderer: Der Upgrade-Dienst von Odoo S.A. gehört zum Enterprise-Abonnement und wechselt nach der Dokumentation ausdrücklich nicht die Edition (Odoo auf eine neue Version heben). Eine Community-Datenbank bleibt also bei OpenUpgrade, beim Datenexport in eine neue Installation oder beim Wechsel zu Enterprise auf gleicher Version mit anschließendem Dienst-Upgrade.

Schritt für Schritt: die Migration vorbereiten und ausführen

Schritt 1: Installierte Module erfassen

Verbinden Sie sich lesend mit der Datenbank und lesen Sie das Modulregister aus:

SELECT name, latest_version, state
FROM ir_module_module
WHERE state = 'installed'
ORDER BY name;

Die Tabelle ir_module_module ist das Modulregister von Odoo; der Server schreibt beim Installieren die Versionskennung in das Feld latest_version. Jedes Modul aus der Liste braucht später ein Migrationsskript, eine Analyse oder eine bewusste Entscheidung; eigene Module und Module aus dem Apps-Store stehen in derselben Tabelle.

Schritt 2: Abdeckung und Lücken bewerten

Prüfen Sie für jedes Modul aus Schritt 1 die Abdeckungstabelle des Zielzweigs. Bei Done und Nothing to do ist nichts weiter nötig. Bei leerem Status öffnen Sie die Datei openupgrade_analysis.txt im Ordner openupgrade_scripts/scripts/Modulname des Zielzweigs; sie zeigt, welche Felder, Modelle und Datensätze sich zwischen den Versionen geändert haben. Liegt kein Skript und kein Entwurf vor, schreiben Sie es selbst oder verschieben Sie den Termin. Die Migration läuft auch ohne Modulskript durch, das Ergebnis für genau dieses Modul ist dann aber ungeprüft.

Für eigene Module und OCA-Module gilt ein anderer Ort: Ihre Migrationsskripte liegen im migrations-Ordner des jeweiligen Moduls, in Unterordnern je Version, mit Dateien, deren Namen mit pre-, post- oder end- beginnen. Der Odoo-Migration Manager führt sie aus, wenn die installierte Modulversion niedriger ist als die Versionsbezeichnung des Ordners. Jedes eigene Modul muss außerdem in einer lauffähigen Fassung für die Zielversion vorliegen.

Schritt 3: Zielversion, Module und Bibliothek bereitstellen

Richten Sie eine Instanz der Zielversion ein und legen Sie die beiden OpenUpgrade-Module in deren addons-path, etwa als zusätzlichen Pfad in der Konfigurationsdatei. Installieren Sie die Bibliothek in der Python-Umgebung der Zielversion:

pip install git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib

Laden Sie das Framework als serverweit geladenes Modul, in der Konfigurationsdatei unter dem Abschnitt options:

[options]
server_wide_modules = web,openupgrade_framework

Ist openupgrade_scripts über den addons-path erreichbar, setzt das geladene Framework die Option –upgrade-path automatisch auf den Ordner der Migrationsskripte. Bei einem Lauf über mehrere Versionen exportieren Sie zusätzlich die Zielversion als Umgebungsvariable (export OPENUPGRADE_TARGET_VERSION=19.0); OpenUpgrade überspringt damit Zwischenschritte, die nur in der Zielversion nötig sind.

Schritt 4: Sicherung anlegen und Kopie migrieren

Sichern Sie Datenbank und Filestore und spielen Sie die Sicherung unter neuem Namen ein, etwa als datenbank_v18_kopie. Die Migration läuft nur gegen diese Kopie; die Produktivdatenbank bleibt unverändert, bis alle Prüfungen bestanden sind. Die OpenUpgrade-Dokumentation nennt die Sicherung als zwingende Voraussetzung vor dem Start.

Schritt 5: Migrationslauf ausführen

Starten Sie den Odoo-Befehl der Zielversion mit den von der Dokumentation empfohlenen Optionen:

odoo-bin -c odoo.conf -d datenbank_v18_kopie \
  --update all --stop-after-init \
  --load=base,web,openupgrade_framework \
  --logfile=odoo_upgrade.log

Der Lauf aktualisiert alle Module, führt dabei die pre-, post- und end-Skripte aus und beendet sich selbst. Rechnen Sie mit mehreren Anläufen: Die Dokumentation erwartet, dass Sie Datenprobleme bereinigen und erneut starten.

Schritt 6: Ergebnis verifizieren

Prüfen Sie nach jedem Lauf mit diesen Abfragen und Blicken (Administratorrechte am Datenbankserver):

Prüfung	Abfrage oder Ort	Erwartung
Version des Basismoduls	SELECT latest_version FROM ir_module_module WHERE name = 'base';	beginnt mit 19.0
Kein Modul in einem Übergangszustand	SELECT name, state FROM ir_module_module WHERE state NOT IN ('installed', 'uninstalled');	keine Einträge mit to install, to upgrade oder to remove; sie zeigen einen abgebrochenen oder unvollständigen Lauf
Protokoll auf Fehler	Logdatei nach ERROR und Traceback durchsuchen, außerdem nach Meldungen, dass OpenUpgrade das Löschen eines Datensatzes abgebrochen hat	keine ungelösten Einträge
Altstrukturen gezählt	SELECT count(*) FROM information_schema.tables WHERE table_name LIKE 'openupgrade_legacy_%';	Zahl notieren; sie ist der Ausgangspunkt für die spätere Bereinigung

Die information_schema-Ansichten sind der vom PostgreSQL-Standard vorgesehene Weg, Tabellennamen abzufragen. Das Zählen der Altstrukturen dient der Kontrolle: OpenUpgrade belässt ersetzte Tabellen und Spalten bewusst mit dem Präfix openupgrade_legacy_ in der Datenbank, damit spätere Migrationsschritte und Korrekturen darauf zurückgreifen können.

Schritt 7: Funktion testen, freigeben, aufräumen

Starten Sie die Instanz mit der migrierten Kopie und führen Sie Ihre Kernprozesse Probe für Probe aus, denselben Katalog wie bei einem Go-live (Abnahmetest für Odoo). Erst wenn alle Prüfungen bestanden sind, zeigt die Instanz auf die migrierte Datenbank.

Wenn die Datenbank eine Zeit stabil läuft, räumen Sie auf: Mit einem Bereinigungsmodul aus dem OCA-Projekt server-tools entfernen Sie die openupgrade_legacy_-Tabellen und -Spalten, und ein vollständiges vacuum von PostgreSQL gibt den Platz frei. Die Daten darin sind dann verwaist; das Datenmodell schützt sie nicht mehr, und ein künftiges Modul könnte denselben Tabellennamen neu belegen. Bewahren Sie die Sicherung vor der Migration auf, solange die neue Datenbank nicht stabil läuft (redaktionelle Einschätzung).

Wenn etwas nicht klappt

Prüfen Sie vor jedem Lauf diese fünf Punkte: Zweig passt zum Schritt (19.0 gegen eine 18.0-Kopie), openupgradelib in der Python-Umgebung der Zielversion installiert, openupgrade_framework geladen, openupgrade_scripts im addons-path, Arbeit nur auf der Kopie.

Symptom	Ursache	Abhilfe
Der Lauf bricht mit einem Importfehler zu openupgradelib ab	Die Bibliothek fehlt in der Python-Umgebung, die die Zielversion ausführt, oder ist veraltet	Installation aus dem Master-Zweig des Quelltext-Repositorys in genau dieser Umgebung wiederholen
Es laufen keine Migrationsskripte, Odoo aktualisiert nur Module	openupgrade_framework ist nicht geladen, oder openupgrade_scripts liegt nicht im addons-path, damit –upgrade-path gesetzt wird	Beides gemäß Schritt 3 prüfen; die geladenen Module stehen auch in der Protokolldatei
Der Lauf bricht mit einem Fehler in einem bestimmten Modul ab	Der Datenbestand passt nicht zu den Annahmen des Skripts, oder für das Modul fehlt ein Skript	Analysedatei des Moduls lesen, Daten bereinigen oder ein eigenes Skript schreiben; Absturzursache beheben, dann neu starten
Ein eigenes Modul verhindert den Start der Zielversion	Es nutzt Felder oder Schnittstellen, die die Zielversion geändert hat	Modul zuerst auf die Zielversion portieren und Datenumwandlung in seinen migrations-Ordner legen
Nach der Migration fehlen Demo-Datensätze	OpenUpgrade wandelt Datenbanken mit Demo-Daten in solche ohne Demo-Daten um, außer Sie setzen die Umgebungsvariable OPENUPGRADE_USE_DEMO=yes	Ist das Verhalten unerwünscht, Variable setzen und von der Sicherung neu starten; produktive Datenbanken ohne Demo-Daten trifft es nicht
Warnungen zur Ansichtsvalidierung im Protokoll	Während der Migration sind Ansichten erwartungsgemäß in einem Übergangszustand	Abwarten und nach dem Lauf die Ansichten in der Oberfläche prüfen; dauerhafte Fehler im Protokoll suchen

Fehlt für viele Module die Abdeckung, ist der Rest Entwicklungsaufwand: Migrationsskripte zu schreiben setzt nach der Dokumentation funktionale und technische Kenntnis des jeweiligen Moduls, SQL und die Hilfsfunktionen von openupgradelib voraus. Für den Lauf selbst verlinkt die OpenUpgrade-Dokumentation Werkzeuge, die die einzelnen Schritte automatisieren; die Fehlerprüfung, die Datenbereinigung und das Wiederholen des Laufs bleiben manuelle Aufgaben, ebenso die Abnahme.

Wann Sie Hilfe holen sollten

• Stehen mehrere Versionssprünge an, multipliziert sich der Aufwand mit jedem Zwischenschritt; die Kostenblöcke eines Upgrade-Vorhabens ordnet Odoo-Upgrade planen: Kosten, Dauer, Risiken.
• Für Module ohne Skripte brauchen Sie Entwicklungskapazität oder einen Dienstleister, der OCA-Module pflegt (OCA-Module einsetzen).
• Wer ohnehin zur Enterprise-Edition wechseln will, tut das auf gleicher Version und nutzt danach den Upgrade-Dienst (Odoo auf eine neue Version heben); die planbare Vorbereitung der Datenqualität bleibt davon unberührt.