Odoo auf eine neue Version heben: Ablauf

Die Odoo-Dokumentation trennt zwei Vorgänge, die im Alltag oft durcheinandergehen. Ein Update ersetzt den Quellcode innerhalb derselben Version und lässt die Datenbank unverändert. Ein Upgrade baut Struktur und Inhalt der Datenbank für eine neue Hauptversion um und ist nach den Worten der Dokumentation irreversibel. Um den zweiten Vorgang geht es hier.

Was Sie vorab brauchen

• Die Zielversion: Die Support-Übersicht nennt je Hauptversion, bis wann sie Standard-Support hat; welche Versionen heute zulässig sind, steht unten unter den Fristen.
• Eine Liste Ihrer Apps und Anpassungen, getrennt nach Standard-Apps, Studio-Anpassungen und eigenen Modulen; den ersten beiden Gruppen gilt der Upgrade-Dienst, eigenen Modulen nur mit Wartungsvertrag.
• Zugang je Hostingmodell: Datenbankmanager bei Odoo Online, Reiter Upgrade im Odoo.sh-Projekt, Serverzugang und Master-Passwort im eigenen Betrieb.
• Eine Sicherung außerhalb des Systems (Backup-Strategie für Odoo).
• Ein Zeitfenster mit geringer Nutzung, denn während des Produktiv-Upgrades ist die Datenbank nicht erreichbar.
• Key-User für den Test und eine Person, die abnimmt (Key User für Odoo schulen).

Der Upgrade-Weg hängt am Hostingmodell

Wer den Vorgang anstößt und was ein Fehlschlag kostet, unterscheidet sich je Hostingmodell. Die Tabelle gibt die Upgrade-Dokumentation 20.0 wieder; die Leistungen des Upgrade-Dienstes beschreibt Odoo im Rahmen des Enterprise-Abonnements.

Angabe	Odoo Online	Odoo.sh	Eigener Server (On-Premise)
Anstoß	Datenbankmanager: Verwaltungsoptionen (Manage) öffnen, dort Upgrade; im Dialog Zielversion, Benachrichtigungsadresse und Zweck (Purpose) Test oder Production	Reiter Upgrade im Projekt, für Produktions- und Staging-Zweige	Auf dem Rechner der Datenbank: python <(curl -s https://upgrade.odoo.com/upgrade) test -d <Datenbank> -t <Zielversion>
Testlauf	Eine Kopie läuft in der Zielversion; den Link schickt Odoo per E-Mail, die Testdatenbank erscheint auch im Datenbankmanager	Die letzte tägliche Produktionssicherung geht an die Upgrade-Plattform; jede Commit-Übergabe spielt die aktualisierte Sicherung ein und aktualisiert die eigenen Module, Protokoll unter ~/logs/upgrade.log. Ohne eigene Module entfällt dieser Modus: Die upgegradete Datenbank ist fertig, sobald die Plattform sie übertragen hat	Dasselbe Skript mit dem Parameter test; das Ergebnis ist ein Paket aus dump.sql und einem Filestore-Ordner, den Sie mit dem produktiven zusammenführen
Während des Produktiv-Upgrades	Die Datenbank ist nicht verfügbar, bis der Vorgang fertig ist	Die Datenbank ist während des ganzen Vorgangs nicht verfügbar; er startet mit dem nächsten Commit auf dem Produktionszweig, ohne eigene Module sofort	Änderungen nach dem Hochladen der Kopie fehlen im Ergebnis; nutzen Sie die Datenbank nicht weiter
Weg zurück	Nicht möglich: ein Zurück auf die vorige Version schließt die Dokumentation aus. Laden Sie vorher eine Sicherung herunter	Scheitert der Vorgang, lädt die Plattform den letzten erfolgreichen Stand zurück. Nach einem Erfolg legt sie eine Sicherung vor dem Upgrade an; der Reiter Backups führt die Sicherungen des Produktionsservers, sieben tägliche und vier wöchentliche, rund einen Monat. Drei weitere monatliche Sicherungen liegen auf eigenen Sicherungsservern; herunterladen oder wiederherstellen lassen sie sich nur über den Odoo-Support	Ihre eigene Sicherung: Das Upgrade ist irreversibel, zurück kommen Sie über die alte Datenbank auf der alten Installation

Zwei Punkte hängen daran. Beim Upgrade wandert eine Kopie Ihrer Datenbank zur Upgrade-Plattform, bei eigener Installation ausdrücklich durch Sie hochgeladen. Die Nutzungsbedingungen halten fest, dass die Datenbank personenbezogene Daten enthalten kann, Odoo S.A. sie auf Weisung des Kunden über diesen Dienst verarbeitet und der Kunde Verantwortlicher bleibt. Im Anwendungsbereich der DSGVO gehört der Vorgang in das Verzeichnis von Verarbeitungstätigkeiten des Verantwortlichen (Art. 30 Abs. 1 DSGVO); die Ausnahme des Abs. 5 für Unternehmen mit weniger als 250 Mitarbeitern greift nicht, wenn die Verarbeitung ein Risiko birgt, nicht nur gelegentlich erfolgt oder besondere Datenkategorien einschließt. Der Test bleibt Ihre Aufgabe: Die Bedingungen legen ausdrücklich dem Kunden auf, die umgebaute Datenbank zu prüfen, die Wirkung neuer Funktionen zu beurteilen und fremde Module anzupassen. Mehrere Testanforderungen sind zulässig.

Wie weit dürfen Sie zurückliegen?

Auf Odoo Online ist das Upgrade Pflicht: bei einer Hauptversion alle zwei Jahre, bei einer Zwischenversion (SaaS- oder Online-Version) wenige Wochen nach dem Erscheinen der nächsten Version. Odoo kündigt einige Wochen vorher an; reagieren Sie nicht, führt Odoo es zum Termin selbst aus. Auf Odoo.sh folgt nach drei Jahren Standard-Support ein Fenster von zwei Jahren für das Upgrade, wieder mit Benachrichtigung durch Odoo. Betreiben Sie Odoo selbst, können Sie auf einer Version bleiben, empfohlen ist das nicht: Nach drei Jahren endet der Standard-Support; Extended Support kostet Aufpreis und ist für eigene Installationen in jeder Version erhältlich, für Odoo Online nicht.

Auch die Zielversion ist nicht frei wählbar, und zwei Regeln greifen ineinander. Die Support-Übersicht erlaubt ein Upgrade auf jede Hauptversion, die noch Standard-Support hat oder deren Standard-Support seit weniger als sechs Monaten abgelaufen ist; dieselbe Seite hält aber ausdrücklich fest, dass bei einem Widerspruch der Enterprise-Abonnementvertrag gilt und sie diesen nicht ändert. Für den Upgrade-Dienst des Abonnements begrenzt Ziffer 4.3 das Ziel auf eine neuere abgedeckte Version (Covered Version), und Ziffer 2 definiert diese als die drei zuletzt veröffentlichten Hauptversionen. Für eine Enterprise-Datenbank ist die Zielversion damit eine neuere der drei zuletzt veröffentlichten Hauptversionen. Stand Oktober 2026 sind das die Versionen 20 (erschienen im September 2026, Standard-Support geplant bis September 2029), 19 und 18. Version 17 hätte nach der Sechs-Monats-Regel der Support-Übersicht noch bis März 2027 Zeit, liegt aber außerhalb der abgedeckten Versionen und ist damit kein Ziel des Upgrade-Dienstes mehr. Die Stufen je Version führt Odoo-Versionen: Support und Upgrade-Rhythmus aus.

Wer älter als die drei zuletzt veröffentlichten Hauptversionen liegt, zahlt zusätzlich: Der Enterprise-Abonnementvertrag (Version 13 vom 24. September 2026) definiert in Ziffer 2 die Covered Versions als die drei zuletzt veröffentlichten Hauptversionen; liegt die Datenbank älter, fällt nach Ziffer 5.1 einmal pro Jahr ein Zuschlag von 25 Prozent des Jahrespreises an, frühestens sechs Monate nach der Veröffentlichung einer neuen Hauptversion. Beispielrechnung: Mit Version 20 sind 20, 19 und 18 abgedeckt, eine Datenbank auf Version 17 kann den Zuschlag damit ab März 2027 auslösen. Eine Community-Installation ohne Abonnement trifft er nicht.

Schritt für Schritt: das Upgrade durchführen

Schritt 1: Zielversion und Zeitfenster festlegen

Prüfen Sie auf der Support-Übersicht, welche Hauptversion als Ziel zulässig ist und ob Ihre Anpassungen dort mitgehen. Ein Upgrade wechselt nicht die Edition, wechselt nicht das Hostingmodell und ersetzt keine Migration aus einem anderen ERP. Legen Sie dann das Zeitfenster fest: Wählen Sie einen Zeitpunkt mit geringer Nutzung und regeln Sie, wie die Arbeit während des Ausfalls läuft.

Schritt 2: Testdatenbank anfordern

Fordern Sie zuerst eine Testdatenbank an, je Hostingmodell nach der Tabelle oben. Bei eigener Installation kann nur die Person, die angefragt hat, das Ergebnis herunterladen; die Kopie kommt ohne Filestore, Sie führen ihn mit dem produktiven zusammen, bevor Sie testen. Enthält die Datenbank eigene Module, ist ein Upgrade erst möglich, wenn es sie für die Zielversion gibt; die Dokumentation rät, Testanforderung und Anpassung der Modulquellen parallel laufen zu lassen. Prüfen Sie, dass die angeforderte Version die Zielversion ist.

Schritt 3: Eigene Module und Anpassungen vorbereiten

Eigene Module sind nach der Dokumentation alle Erweiterungen des Standardcodes, die nicht mit Studio gebaut wurden. Für sie gilt ein eigener Ablauf: Entwicklungen stoppen (Fehlerbehebungen ausgenommen), jede Anpassung gegen die Funktionen der Zielversion prüfen und Redundanz entfernen, das Modul zuerst in einer leeren Datenbank der Zielversion installierbar machen, dann im upgegradeten Testlauf. Für umbenannte Felder, Modelle und externe IDs setzen Sie Upgrade-Skripte ein, sonst gehen Daten verloren. Studio-Anpassungen deckt der Upgrade-Dienst ab, solange Studio installiert ist und das Abonnement läuft. Auf Odoo Online entfällt dieser Schritt: Die Dokumentation nennt Odoo Online unvereinbar mit eigenen Modulen und Modulen aus dem Apps-Store, dort bleiben Standard-Apps und Studio-Anpassungen.

Schritt 4: Testdatenbank durchprüfen

Testdatenbanken sind neutralisiert: geplante Aktionen und ausgehende E-Mails sind abgeschaltet, Zahlungsanbieter und Versanddienste stehen auf Testbetrieb, die Bank-Synchronisierung ist aus. Prüfen Sie Ansichten, Berichte, Vorlagen, Übersetzungen, Filter und Exporte, dann Ihre Kernprozesse in der Reihenfolge des Betriebs: Einkauf mit Wareneingang, Verkauf bis zur Rechnung, Gutschrift, Website-Bestellung und die Verbindungen zu Fremdsystemen. Was die Testdatenbank nicht abdeckt, prüfen Sie nach dem Upgrade in der Produktivdatenbank. Fehler beheben Sie vor der Umstellung; melden können Sie sie über die Support-Seite mit der Auswahl „An issue related to my future upgrade (I am testing an upgrade)“.

Schritt 5: Probe fahren und freigeben

Upgrade-Skripte und Datenbestand verändern sich weiter. Fordern Sie kurz vor dem Termin eine frische Testdatenbank an und fahren Sie den Ablauf erneut; die Dokumentation empfiehlt eine vollständige Probe am Tag vor der Umstellung. Halten Sie fest, welcher Teststand geprüft wurde und wer offene Punkte bis wann schließt (Abnahmetest für Odoo). Erst danach setzen Sie den Termin fest und informieren die Anwender.

Schritt 6: Produktivdatenbank umstellen

Stellen Sie den Zweck von Test auf Production, bei eigener Installation den Parameter production. Bei Odoo.sh startet der Vorgang mit dem nächsten Commit auf dem Produktionszweig, ohne eigene Module sofort; sind eigene Module vorhanden, wird er nur abgeschlossen, wenn deren Aktualisierung gelingt. Bei eigener Installation führen Sie den Filestore mit dem produktiven zusammen, bevor Sie die neue Version ausrollen. Nutzen Sie die Datenbank während des Vorgangs nicht: Was Sie nach dem Hochladen der Kopie erfassen, fehlt im Ergebnis.

Schritt 7: Nach dem Upgrade nacharbeiten

Der Upgrade-Bericht hängt an der Bestätigungs-E-Mail und steht im Discuss für die Gruppe Administration/Einstellungen bereit. Er nennt unter anderem abgeschaltete Ansichten; aktivieren oder entfernen Sie sie. Einstellungen aus dem Testlauf sind nicht mitgewandert, denn ein Merge von Staging nach Produktion überträgt nur den Code: Setzen Sie sie erneut oder führen Sie sie als XML-Datendatei im Zweig mit. Schulen Sie die Änderungen für Ihre Anwender und planen Sie in den ersten Tagen Zeit für Rückfragen ein.

So prüfen Sie das Ergebnis

• Die Produktivdatenbank arbeitet in der Zielversion, und die Anwender kommen mit ihren Rollen hinein.
• Der Upgrade-Bericht ist gelesen; jede dort abgeschaltete Ansicht ist aktiviert oder bewusst entfernt.
• Je Kernprozess ist mindestens ein echter Vorgang nach dem Upgrade durchgelaufen, von der Bestellung bis zur Gutschrift.
• Anhänge öffnen sich, Berichte und Exporte laufen.
• Die Punkte, die die Testdatenbank nicht abdecken konnte, haben einen Termin in den ersten Tagen nach dem Upgrade.
• Die Sicherung vor dem Upgrade liegt an einem Ort, den der Odoo-Server selbst nicht erreicht.

Wenn etwas nicht klappt

Symptom	Ursache	Abhilfe
Das Upgrade-Skript bricht mit einem Netzwerkfehler ab	Der Rechner erreicht die Upgrade-Plattform nicht: nötig sind TCP 443 und ein beliebiger Port zwischen 32768 und 60999	Die Firewall-Regel ergänzen; die Dokumentation nennt beide Anforderungen
Im Test kommen keine E-Mails an, echte Zahlungen laufen nicht	Die Testdatenbank ist neutralisiert: ausgehende Mailserver abgeschaltet, Zahlungsanbieter und Versanddienste im Testbetrieb	Für Zahlungen die Zugangsdaten des Testbetriebs verwenden; nach dem Upgrade in der Produktivdatenbank prüfen. Für die Bank-Synchronisierung beim Anbieter Sandbox-Zugangsdaten anfragen
Ein eigenes Modul lässt sich nicht installieren	Es nutzt Felder, Ansichten oder Methoden, die die neue Version geändert hat	Modul an die Zielversion anpassen und für umbenannte Felder Upgrade-Skripte schreiben
Auf Odoo.sh wird keine Testdatenbank ausgeliefert	Die Quellen der eigenen Module sind noch nicht auf der Zielversion	Den Quellcode zuerst anpassen und die Anforderung dann wiederholen
Nach dem Upgrade fehlen Ansichten	Fehlerhafte Ansichten wurden beim Upgrade abgeschaltet	Den Upgrade-Bericht lesen und die Ansichten aktivieren oder entfernen

Wann Sie Hilfe holen sollten

• Bei eigenen Modulen und Schnittstellen gehört die Anpassung zu der Stelle, die sie gebaut hat: Ohne Wartungsvertrag ist sie nicht Teil des Upgrade-Dienstes. Studio-Anpassungen deckt der Dienst nur ab, solange Studio installiert ist und das Abonnement läuft.
• Für einen Server im eigenen Haus gehören Betrieb, Sicherung und Firewall in die Hand Ihrer Technik oder eines Dienstleisters (Odoo auf eigenem Server).
• Bei einer Community-Datenbank ohne Enterprise-Abonnement beschreibt Odoo Community mit OpenUpgrade upgraden den Weg über die OCA-Bibliothek.
• Fällt der Termin in einen Abschluss oder in eine Außenprüfung, stimmen Sie ihn mit Ihrer Steuerberatung ab (Steuerberater zusammenarbeiten).
• Starten Sie nicht ohne erfolgreichen Testlauf: Die Dokumentation nennt Anwender, die sich nicht umstellen können, Betriebsunterbrechungen und eine Website, die nicht richtig arbeitet, als mögliche Folgen.