ODOO COMMUNITY UPGRADE
Der Sprung auf eine neue Odoo-Hauptversion ist kein Update: Er ist eine Umwandlung Ihrer Datenbank in nur eine Richtung, und nichts, was Sie falsch machen wollen. Hier steht, wie wir das für Sie übernehmen — ein neues System auf unseren eigenen Servern, Ihr bestehendes bleibt unberührt, während wir arbeiten — und darunter die konkreten Befehle, die ein Entwickler ausführen würde.
Der Unterschied, auf den es ankommt
Odoo benutzt zwei Wörter, die gleich klingen und es nicht sind. Ein Update bringt Ihnen die neueste Fassung der Software, die Sie bereits einsetzen. Ein Upgrade bringt Ihre Datenbank auf eine neue Hauptversion (18 auf 19 oder 19 auf 20) und wandelt die Daten selbst um. Es geht nur in eine Richtung: einen unterstützten Weg zurück gibt es nicht, und es ist keine Lizenzänderung, kein Wechsel der Edition und kein Wechsel des Hosting-Anbieters.
Drei Dinge sollten Sie wissen, bevor jemand Ihr System anfasst.
Es geht immer nur eine Hauptversion auf einmal. Ein Sprung von 17 auf 20 sind drei Migrationen, nicht eine: 17 → 18, 18 → 19, 19 → 20. Eine Version zu überspringen ist im gesamten Odoo-Ökosystem kein unterstützter Weg.
Er wird an einer Kopie gemacht, nie an der laufenden Datenbank. Alle, die darüber geschrieben haben (die eigene Dokumentation von Odoo, das OpenUpgrade-Projekt der OCA und jeder Praktiker, den wir gesehen haben), beginnen mit einem Backup und arbeiten an einer Zweitkopie. Sie erfahren, was kaputtgegangen ist, an der Kopie und nicht vor Ihren Kunden.
Ihre eigenen Anpassungen sind der Teil, der Arbeit macht. Ein Modul, das für Ihr Geschäft gebaut wurde, zieht nicht von selbst mit: Sein Code muss auf die Zielversion gebracht werden, und Umbenennungen, die sonst Daten kosten würden, brauchen eigene Migrationsskripte. Die Odoo-Dokumentation sagt es unverblümt: Ein Upgrade ist blockiert, bis es Ihre individuellen Module für die Zielversion gibt.
Und dann der Weg selbst. Odoo verkauft einen Upgrade-Pfad für Enterprise; für Odoo Community ist die Open-Source-Antwort das OpenUpgrade-Projekt der OCA. Die OpenUpgrade-Dokumentation stellt fest, dass die Odoo Community Edition Migrationen zwischen Hauptversionen nicht unterstützt, und hält fest, dass OpenUpgrade die Lösung ist, die der Gründer von Odoo selbst dafür empfiehlt. Es ist ein echtes Projekt, gepflegt von der Community-Vereinigung, und es ist der Weg, den ein Entwickler auf einer Community-Datenbank nutzt.
Der Weg von ODOO4projects
Nichts davon müssen Sie selbst tun. Wenn Ihr Geschäft auf Odoo Community läuft und Sie die Version wechseln wollen, ohne jemanden einzustellen, der die Reihenfolge auf dieser Seite abarbeitet, machen wir stattdessen Folgendes.
Sie eröffnen ein Support-Ticket und sagen uns, was Sie haben. Wir sehen uns zuerst Ihre Datenbank an (ihre Version, ihre Anpassungen, ob wir sie überhaupt bewegen können) und sagen Ihnen, was wir finden. Dann senden wir Ihnen einen Link zu einem sicheren Formular, über das Sie Ihre Datenbank hochladen. Sobald wir sie haben, richten wir Ihnen einen neuen Server auf unserer eigenen Infrastruktur ein und übergeben Ihnen die Zugangsdaten. Ihr bestehendes System läuft die ganze Zeit weiter, weil wir es nicht anfassen: Wir arbeiten an der Datenbank, die Sie uns gesendet haben, und an dem neuen Server, den wir gebaut haben.
Wenn Sie lieber erst eine Zahl sehen möchten: Welchen Tarif Sie brauchen, hängt von den Modulen ab, die Sie nutzen, und die Tarife finden Sie hier — Tarife ansehen. Das Upgrade selbst ist auf dieser Seite nicht bepreist; wir melden uns bei Ihnen, nachdem wir Ihre Datenbank angesehen haben.
Genau dieser letzte Punkt ist der ganze Grund für diesen Weg. Bei unserem Service migrieren Sie nicht abends nach Ladenschluss Ihre laufende Datenbank. Sie sehen sich ein zweites System an, in einer neuen Version, mit Ihren Daten darin, und können beide vergleichen, bevor Sie irgendetwas entscheiden.
Unser Migrationsservice dokumentiert Unterstützung für Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases; Patch-Releases wie 18.1 oder 17.2 werden nirgends in unserem Service unterstützt. Ist Ihre Datenbank älter als 17, helfen wir Ihnen trotzdem, sie auf ein unterstütztes Release zu bringen, aber erst nach einer Prüfung auf Kompatibilität. Neue Instanzen auf unseren Servern können auf Odoo 19 oder Odoo 20 angelegt werden. Wenn Sie gezielt auf 20 wollen, sagen Sie es im Ticket: Die Version, zu der Sie gehen, zählt mehr als die, auf der Sie sind.
Auf der KI-Seite ist hier ein Fall, den wir tatsächlich veröffentlicht haben. Rechnungen von Hand von einer Odoo-Instanz in eine andere zu kopieren ist langsam und leicht falsch, also haben wir es stattdessen mit einem Workflow gemacht: Datensätze aus einem Odoo-19-System in ein neues Odoo-20-System geschrieben, angetrieben von einem Automatisierungs-Workflow und einem MCP-Server, der auf das neue System zeigt. Drei Regeln machten es sicher (Rechnungsnummer und Datum ändern sich nie, der Kontakt wird nachgeschlagen statt geraten, das Produkt wird nachgeschlagen statt geraten) und eine harte Vorgabe: Fehlt ein Kontakt oder ein Produkt, bricht der Lauf laut ab, statt einen Fast-Doppelgänger anzulegen. Bevor wir es auf den Rest losließen, haben wir eine Rechnung von Anfang bis Ende geprüft: Nummer, Datum, Kontakt, Positionen.
Eines verwischen wir nicht, denn es ist der Unterschied zwischen uns und einem Verkäufer. Der MCP-Server, den wir in unserer eigenen Verwaltungskonsole mitliefern, macht Hosting-Operationen. Er startet einen Server neu, lädt ein Modul hoch, fügt eine Domain hinzu oder prüft sie, verwaltet Backups und liest eine Logdatei; das ist die veröffentlichte Liste, und sie ist eine echte Erleichterung, wenn Sie einen KI-Assistenten nutzen. Er ist keine Datenmigrations-Engine, und wir beschreiben ihn auch nicht als eine. Die Importarbeit oben wurde mit einem Automatisierungs-Workflow und einem MCP von Drittanbietern erledigt; die KI machte den mühsamen Teil und wurde von einem Menschen geprüft, genau wie es sein soll.
Und die ehrliche Grenze, in den Worten des Projekts, das sich damit am besten auskennt. Die OpenUpgrade-Dokumentation nennt die Export-und-Import-Alternative und benennt ihren Preis klar: Sie retten nur einen Teil Ihrer Daten, und insbesondere erhalten Sie nicht die Historie und die Verknüpfungen zwischen den Datensätzen, zum Beispiel die Rechnungen je Kunde. Das ist das Risiko jedes Weges, der Dokumente in ein neues System verschiebt, und deshalb stellen Sie uns, wenn Sie diesen Weg mit uns gehen, vor Ihrer Freigabe eine Frage: Welche Datensätze werden in der neuen Datenbank sein und welche nicht? Wir möchten lieber, dass Sie sie stellen, als dass Sie sie annehmen.
Der dokumentierte Weg
Das ist die Reihenfolge, auf die sich die Odoo-Dokumentation, das OpenUpgrade-Projekt und die aufgezeichneten Workshops einig sind. Nichts davon ist unseres und nichts davon ist geheim: Es ist der dokumentierte Weg, in der Reihenfolge, in der er gegangen wird.
So sieht es ehrlich aus: Die Vorbereitung ist der lange Teil, die Migration selbst der kurze, und die Kopie ist das, was Sie kaputtmachen dürfen.
Für Ihre Entwickler
Wenn Sie Odoo Community selbst betreiben und das lieber im Haus erledigen möchten, statt es uns zu überlassen, sind das die Befehle. Sie sind aus der jeweiligen Dokumentation übernommen, und bei jedem steht, was Sie einsetzen müssen und wovor die Quelle warnt. Nichts davon haben wir gegen Ihre Datenbank ausgeführt, und kein von uns veröffentlichter Befehl läuft auf unseren eigenen Servern: Unser Service beginnt mit einem Support-Ticket, nicht mit einem Terminal.
Odoo dokumentiert eine Upgrade-Plattform, die für On-Premise-Installationen über die Kommandozeile funktioniert. Die Odoo-Dokumentation stellt fest, dass die Migrationsskripte, die sie ausführt, nicht Open Source sind und zu Enterprise gehören; die Plattform selbst aber bringt eine selbst gehostete Datenbank auf die neue Version.
# upgraded TEST database
python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
# production upgrade
python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>
# general help
python <(curl -s https://upgrade.odoo.com/upgrade) --help
Ersetzen: <your db name> ist die Datenbank auf der Maschine, auf der Sie den Befehl ausführen, und <target version> ist die Version, zu der Sie wechseln — 17.0, 18.0 oder 19.0, entsprechend dem Versionsauswahlfeld auf unserer eigenen Tarifseite.
Was die Odoo-Dokumentation neben diesen drei Zeilen verlangt, weil davon abhängt, ob sie funktionieren: Das Skript braucht die üblichen Linux-Befehle auf der Maschine; der Systembenutzer, der es ausführt, braucht Zugriff auf Ihre PostgreSQL-Datenbank (die übliche PostgreSQL-Client-Umgebung, etwa .pgpass); und die Maschine muss die Upgrade-Plattform auf TCP 443 und auf einem Port im Bereich 32768-60999 erreichen, ein Firewall kann also eine Ausnahme brauchen. Die Kopie, die Sie hochladen, wird ohne Filestore übermittelt, deshalb muss der Produktiv-Filestore in die aktualisierte Datenbank zusammengeführt werden, bevor Sie sie testen. Der Download enthält dump.sql und einen Filestore-Ordner, und nur wer das Upgrade angefordert hat, kann das Ergebnis herunterladen.
# 1. OpenUpgrade for the TARGET version (the branch is the target major version)
git clone --depth 1 --branch <TARGET>.0 https://github.com/OCA/OpenUpgrade.git
# 2. helper library — the line the OpenUpgrade docs use
pip install "git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib"
# 3. put the clone on the add-ons path of the <TARGET> Odoo config
# addons_path = <your own addons>,</abs/path>/OpenUpgrade
# 4. migrate the copy of the database
<odoo-bin> -c /etc/odoo/<TARGET>.conf \
-d <DB> \
--upgrade-path=/abs/path/OpenUpgrade/openupgrade_scripts/scripts \
-u all --stop-after-init \
--load=base,web,openupgrade_framework
# 5. finish: a plain update, no migration parameters
<odoo-bin> -c /etc/odoo/<TARGET>.conf -d <DB> -u all --stop-after-init
Vier Dinge ersetzen: <TARGET> ist die Ziel-Hauptversion (17, 18 oder 19 — nicht die Version, von der Sie kommen); <DB> ist die Kopie, die Sie migrieren, nie die laufende Datenbank; <odoo-bin> ist die Binärdatei der Zielversion, und wie sie heißt, hängt davon ab, wie Sie Odoo installiert haben (odoo-bin, odoo oder das Docker-Äquivalent); und beide absoluten Pfade sind Ihre eigenen — der Add-ons-Pfad und der Ort des OpenUpgrade-Klons.
Zwei Details aus der eigenen Dokumentation des Projekts, die man mitnehmen sollte: Der openupgrade_framework-Teil dieses Befehls ist eine Reihe von Patches, die unter anderem verhindern, dass Odoo die Spalten und Tabellen von Feldern löscht, die es nicht mehr gibt — einer der Wege, auf denen eine Migration Daten verliert. Und die Umgebungsvariable OPENUPGRADE_USE_DEMO=yes behält die Demodaten in der migrierten Datenbank, wenn Sie sie wollen.
# Odoo's own code-rewrite command (it runs the scripts in odoo/upgrade_code)
<odoo-bin> upgrade_code --from <FROM> --to <TO> --dry-run
Ersetzen Sie <FROM> und <TO> durch die beiden Hauptversionen (zum Beispiel 18 und 19). Führen Sie es zuerst mit --dry-run aus. Die eigene Befehlsreferenz von Odoo nennt diesen Befehl ein „Best-Effort“-Werkzeug und warnt, dass er „keine Silberkugeln“ ist: Er schreibt um, was er kann, und hinterlässt Ihnen eine Liste dessen, was ein Mensch noch ändern muss. Das Gegenstück der OpenUpgrade-Community für Modulcode ist odoo-module-migrator, das INFO für automatische Änderungen, WARNING für prüfenswerte Dinge und ERROR für Dinge protokolliert, die gar nicht funktionieren. Beide Werkzeuge berichten; keines denkt.
# stop the service while you work (packaged install; the Odoo docs show this pattern)
sudo service odoo<TARGET> stop
# database dump (PostgreSQL's own tool)
sudo -u postgres pg_dump -Fc -d <DB> -f /path/backup/<DB>.dump
# restore a dump into a fresh database
sudo -u postgres createdb -O <DB_OWNER> <DB_NEW>
sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
# the filestore lives under Odoo's data directory:
# default on Unix: $XDG_DATA_HOME or ~/.local/share/Odoo or /var/lib/Odoo
# filestore path: <data_dir>/filestore/<DB>Ersetzen Sie die Datenbanknamen, den Eigentümer, den Backup-Pfad und das Filestore-Datenverzeichnis durch Ihre eigenen; der Filestore enthält die Anhänge und Dokumente, auf die Ihre Datensätze zeigen, und eine Datenbank, die ohne ihn wiederhergestellt wird, ist eine Datenbank mit fehlenden Dateien. Das sind die dokumentierten Verfahren von PostgreSQL und Odoo, nicht unsere: Wir veröffentlichen keinen Befehl, der auf unseren eigenen Servern läuft, weil unser Service mit einem Ticket beginnt.
Eigenleistung
Ein gemieteter Server ist billig. Das ist die kleinste Zahl in dieser Entscheidung. Odoo Community selbst ist kostenlos: Eine Lizenz pro Benutzer werden Sie auf diesem Weg nirgends finden, weil Community keine hat.
Was in dieser Zahl nicht steckt, ist der Mensch. Ein Upgrade auf Ihrem eigenen Server heißt: Jemand installiert die neue Version, bringt den Migrationscode auf den richtigen Pfad, portiert die Module, die Ihr Geschäft tatsächlich nutzt, lässt die Migration laufen, bis das Log nicht mehr meckert, prüft, ob Kunden, Aufträge und Rechnungen noch da sind, räumt auf, was die Migration hinterlassen hat, und macht das Ganze dann zu einem passenden Zeitpunkt noch einmal auf der Produktivdatenbank. Die Odoo-Dokumentation sagt, das Update erledigt am besten die Person, die Odoo ursprünglich eingerichtet hat. Auf einem gemieteten Server sind das Sie oder jemand, den Sie pro Stunde bezahlen, und keine dieser Zeilen steht auf der Rechnung. Das ist die Hälfte der Rechnung, die niemand ausdruckt, und die Hälfte, die in Ihren Abenden landet.
Wir werden Ihre Stunden nicht beziffern, weil wir sie nicht gemessen haben und eine Marketingzahl schlechter wäre als keine. Was wir sagen, ist der Teil, bei dem es nicht wirklich ums Geld geht: Während Sie diese Arbeit machen, machen Sie nicht die Arbeit, für die man Sie bezahlt, und wenn die Migration falsch ist, erfahren Sie es von einem Kunden.
Klare Antworten
Nein. Ein Update bringt Ihnen die neueste Fassung der Software, die Sie bereits einsetzen. Ein Upgrade bringt Ihre Datenbank auf eine neue Hauptversion (18 auf 19 oder 19 auf 20) und wandelt die Daten selbst um. Es geht nur in eine Richtung: einen unterstützten Weg zurück gibt es nicht, und es ist keine Lizenzänderung, kein Editionswechsel und kein Hosting-Wechsel.
Nein. Es geht immer nur eine Hauptversion auf einmal: 14 auf 15 auf 16 auf 17 auf 18 auf 19 auf 20. Eine Version zu überspringen ist kein unterstützter Weg. Unser eigener Migrationsservice dokumentiert Unterstützung für Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases, keine Patch-Releases; ältere Datenbanken brauchen zuerst eine Kompatibilitätsprüfung, die mit einem Support-Ticket beginnt.
Das ist die richtige Frage, und die ehrliche Antwort lautet: Es hängt vom Weg ab. Der OpenUpgrade-Weg — eine Versionsmigration auf Ihrem eigenen Server — nimmt die Datenbank mit und erhält die Historie und die Verknüpfungen zwischen den Datensätzen. Die OpenUpgrade-Dokumentation warnt, dass der andere Weg, Dokumente in ein neues System zu verschieben, nur einen Teil Ihrer Daten rettet und die Historie und die Verknüpfungen zwischen den Datensätzen verliert, zum Beispiel die Rechnungen je Kunde. Unser Service baut Ihnen eine neue Datenbank und bringt Ihre Daten hinein; unser Weg ist also der, nach dem Sie fragen sollten: Bitten Sie uns vor Ihrer Freigabe, genau aufzulisten, welche Datensätze in der neuen Datenbank sein werden und welche nicht. Wir möchten lieber, dass Sie sie stellen, als dass Sie sie annehmen.
Nicht von allein. Ein Modul, das für Ihr Geschäft geschrieben wurde, braucht seinen Code auf der Zielversion, und Umbenennungen, die sonst Daten kosten würden, brauchen eigene Migrationsskripte. Die Odoo-Dokumentation ist hier deutlich: Ein Upgrade ist blockiert, bis es eine Version Ihrer individuellen Module für die Zielversion gibt. Module, die mit Odoo ausgeliefert werden, und Module der Community-Vereinigung bringen ihre eigenen Migrationsskripte mit; Ihre nicht, und die muss jemand schreiben.
Für den Upgrade-Service veröffentlichen wir weder Preis noch Dauer, und wir erfinden hier auch keine. Was wir veröffentlichen, ist der Anfang: Sie eröffnen ein Support-Ticket, wir prüfen Ihre Datenbank auf Kompatibilität und melden uns bei Ihnen. Wenn Sie es gegen die Eigenleistung abwägen, ist der ehrliche Vergleich nicht die Servermiete, sondern Ihre eigenen Stunden, die auf keiner Rechnung auftauchen.
Um die Befehle im technischen Abschnitt auszuführen, ja; oder jemanden, der sich im Terminal mit PostgreSQL auskennt. Damit wir es übernehmen, nein: Genau das ist der Sinn des Service. Sie senden die Datenbank, wir bauen das neue System auf unserer Infrastruktur, und Sie erhalten die Zugangsdaten.
Ja, und das sollten Sie. Wer die Arbeit macht, migriert zuerst eine Kopie; das ist die erste Regel des ganzen Prozesses, in der Odoo-Dokumentation wie im OpenUpgrade-Projekt. Und die migrierte Kopie ist das, was Sie prüfen, bevor mit dem System, auf dem Ihr Geschäft läuft, irgendetwas passiert. Unser Service folgt demselben Prinzip: Wir bauen das neue System auf unseren eigenen Servern, und Sie vergleichen es mit dem alten.
Ja, genau dafür ist unser Migrationsservice da. Sie eröffnen ein Support-Ticket, wir senden Ihnen ein sicheres Formular zum Hochladen Ihrer Datenbank, richten Ihnen einen neuen Server auf unserer Infrastruktur ein und stellen die Zugangsdaten bereit. Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases; ältere nach einer Kompatibilitätsprüfung.
Sie eröffnen ein Support-Ticket, wir prüfen Ihre Datenbank auf Kompatibilität und melden uns bei Ihnen.