Odoo migrieren und upgraden - ohne Datenverlust umziehen

Migration, Upgrade, Umzug - erst die Begriffe sortieren

Bevor du irgendetwas planst, brauchst du drei Begriffe sauber getrennt, weil sie oft in einen Topf geworfen werden - und weil an ihnen unterschiedlicher Aufwand hängt.

Migration meint den Umzug deiner Odoo-Instanz von einem Ort zum anderen: von odoo.sh zu einem eigenen Hoster, von einem Server auf einen anderen, von einem Land ins andere. Die Odoo-Version bleibt dabei gleich, es wandern nur Datenbank und Filestore.
Upgrade meint den Sprung auf eine neuere Odoo-Major-Version, etwa von 17 auf 18 oder von 18 auf 19. Der Ort bleibt gleich, aber Schema und Daten müssen an die neue Version angepasst werden.
Umzug ist im Alltag das Wort, das die meisten benutzen, wenn sie eigentlich eine Migration meinen - manchmal aber beides gleichzeitig: Hoster wechseln UND dabei die Version anheben.

Die folgende Tabelle sortiert das:

Begriff	Was passiert	Wann nötig
Migration	Instanz wandert an einen neuen Ort, Version bleibt	Hoster-Wechsel, Serverstandort ändern, raus aus dem Lock-in
Upgrade	Version wird angehoben, Ort bleibt	alte Version läuft aus, neue Features, Security-Support endet
Beides	Umzug und Versionssprung in einem Projekt	häufigster Fall beim Wechsel weg von einem alten Setup

Der Grund, warum diese Trennung am Anfang steht: Ein reiner Umzug ist technisch überschaubar - Daten raus, Daten rein, testen. Ein Upgrade ist Handwerk mit eigenen Fallstricken. Und wer beides gleichzeitig macht, sollte die zwei Baustellen bewusst nacheinander denken, nicht vermischen. Dieser Guide führt dich durch den ganzen Weg und verweist an den tiefen Stellen auf die Detail-Artikel.

Warum Teams von odoo.sh weg migrieren

Kern-Aussage: Die meisten Migrations-Projekte, die bei uns landen, starten nicht aus Lust auf Umzug, sondern weil odoo.sh an einer konkreten Grenze anstößt. Das sind die wiederkehrenden Gründe - sachlich, ohne Polemik:

Kein Rechenzentrum in DACH. Für viele Unternehmen in Deutschland, Österreich und der Schweiz ist der Serverstandort ein harter Einkaufs- oder Audit-Punkt. odoo.sh bietet keinen DE/AT-Standort - damit ist das Thema Datenhoheit für DACH-Kunden strukturell offen.
Nur Enterprise, keine Community Edition. Wer Odoo Community fährt, wird von odoo.sh gar nicht bedient. Das schließt einen ganzen Teil der Odoo-Nutzer von Haus aus aus.
Nur GitHub als Git-Anbieter. Teams, die auf GitLab oder Bitbucket sitzen, müssen sich anpassen - der Deploy-Workflow ist an GitHub gebunden.
Kein Root-Zugang. Keine eigenen System-Pakete, keine PostgreSQL-Extensions nach Wahl, keine tiefen Eingriffe. Für Standard-Setups reicht das, für anspruchsvollere Instanzen wird es zur Wand.
Die Kostenkurve. odoo.sh wird mit wachsender Instanz und mehr Workern spürbar teurer, und ein Teil der Posten ist im Vorfeld schwer zu greifen. Wie sich das konkret zusammensetzt, ist ein eigenes Thema - dafür gibt es den Kostenrechner und die Kostenzerlegung.

Hinter mehreren dieser Punkte steckt dasselbe Muster: Lock-in. Je enger dein Betrieb an einen einzigen Anbieter und dessen Workflow gebunden ist, desto teurer wird der Ausstieg - nicht nur in Euro, sondern in Aufwand und Risiko. Ein gesundes Setup lässt sich mit vertretbarem Aufwand verlagern: Deine Daten gehören dir, und der Weg zu einem anderen Hoster steht offen. Genau diese Beweglichkeit ist der Grund, warum eine dokumentierte, getestete Migration mehr wert ist als das Versprechen, dass ein Umzug “schon irgendwie” gehen wird.

Wenn dich einer dieser Punkte betrifft, lohnt der Blick auf die Alternative zu odoo.sh im Detail. Wichtig: Das ist keine Abrechnung mit odoo.sh - für viele Setups ist es ein solider Dienst. Es geht um die Fälle, in denen die Grenzen zum echten Problem werden, und um den geordneten Weg raus.

Welcher Weg ist deiner? Drei typische Szenarien

Kern-Aussage: Bevor du Aufwand schätzt, musst du wissen, welches der drei Szenarien du eigentlich vor dir hast. Sie unterscheiden sich deutlich im Hauptaufwand.

Szenario	Was zu tun ist	Haupt-Aufwand
Reiner Umzug (Version bleibt)	Datenbank + Filestore exportieren, auf neuem Hoster einspielen, DNS/Mail/Zertifikate umstellen	Testlauf + sauberes Go-live-Fenster
Reines Upgrade (Ort bleibt)	Versionssprung über OpenUpgrade oder den Odoo-Service, Custom-Module anpassen, testen	Custom-Migration + Tests
Umzug + Upgrade zusammen	erst umziehen und stabilisieren, dann Version anheben - oder umgekehrt, je nach Ausgangslage	Reihenfolge planen, zwei Baustellen trennen

Das mittlere und das rechte Szenario haben ihren Aufwand nicht im Transport, sondern in der Anpassung deiner eigenen Module und im Testen. Genau deshalb bringt eine Pauschal-Schätzung ohne Blick auf dein konkretes Setup nichts - zwei Instanzen auf derselben Odoo-Version können völlig unterschiedlich aufwendig sein.

Ein praktischer Rat zum kombinierten Fall: Umzug und Upgrade in einem Rutsch klingt effizient, verdoppelt aber die Fehlerquellen im selben Zeitfenster. Wenn deine Ausgangs-Instanz wackelig läuft, ist es oft ruhiger, zuerst sauber umzuziehen, den Betrieb zu stabilisieren und die Version danach in einem eigenen Schritt anzuheben.

Bevor du startest: die Vorab-Checkliste

Kern-Aussage: Die meisten Migrations-Probleme entstehen nicht während des Umzugs, sondern davor - weil eine Frage nicht geklärt wurde. Diese Punkte solltest du beantworten können, bevor du ein Projekt startest. Sie kosten dich eine Stunde und ersparen dir böse Überraschungen im Go-live-Fenster.

Welche Odoo-Version läuft aktuell, und wo willst du hin? Daraus ergibt sich, ob überhaupt ein Upgrade dazukommt und über wie viele Versionsschritte.
Community oder Enterprise? Das entscheidet über Portabilität, Upgrade-Weg und Lizenz-Fragen (siehe nächster Abschnitt).
Welche Module sind installiert - Standard, OCA, Custom? Die Custom- und Drittanbieter-Module sind der eigentliche Aufwandstreiber und der häufigste Grund für Verzögerungen.
Wie groß sind Datenbank und Filestore? Das bestimmt die Dauer von Transfer und Testläufen.
Welche Integrationen hängen dran? Mail-Versand, Zahlungsanbieter, Webshop, externe Schnittstellen - alles, was nach dem Umzug neu verdrahtet und getestet werden muss.
Wann darf die Instanz kurz stehen? Ein realistisches Downtime-Fenster für das Go-live, abgestimmt mit den Fachbereichen.
Wo sollen die Daten künftig liegen? Der Serverstandort ist eine Entscheidung, die du beim Umzug ohnehin triffst - triff sie bewusst, nicht nebenbei.

Wenn du diese sieben Fragen beantworten kannst, hast du die Bestandsaufnahme im Kopf, die jedes seriöse Migrations-Angebot voraussetzt. Wer ohne diese Antworten startet, schätzt ins Blaue - und im Zweifel zu optimistisch.

Deine Edition entscheidet mit - Community oder Enterprise

Definition zuerst: Odoo gibt es in zwei Editionen. Community ist die quelloffene Variante ohne Lizenzkosten und ohne Bindung an die Odoo-SA-Cloud. Enterprise ist die kostenpflichtige Variante mit Subscription, zusätzlichen Modulen und dem offiziellen Support von Odoo SA. Welche du fährst, bestimmt sowohl deinen Umzugs- als auch deinen Upgrade-Weg.

Beim Umzug ist der Unterschied handfest: Eine Community-Instanz kannst du frei zwischen Hostern bewegen - Datenbank und Filestore gehören dir, es hängt keine Cloud-Bindung dran. Bei Enterprise hängt die Portabilität an deiner Subscription: Die Lizenz muss auf der neuen Instanz gültig bleiben, die Enterprise-Module kommen aus dem Odoo-Ökosystem. Der Umzug an sich funktioniert, du musst nur die Subscription-Seite mitdenken.

Beim Upgrade wird der Unterschied noch deutlicher, weil Odoo den bequemen Automatik-Service nur an Enterprise-Kunden ausliefert. Für Community läuft der Versionssprung über OpenUpgrade, den quelloffenen Upgrade-Pfad der OCA. Das ist der Kern-Schmerz vieler Community-Betreiber - und ein eigenes, tiefes Thema. Wie das konkret abläuft, welche Reihenfolge zwingend ist und wo die Fallen liegen, steht im Detail-Guide Odoo 17 auf 19 upgraden mit OpenUpgrade.

Für Community-Betreiber ist der Edition-Punkt auch beim Hosting relevant: Community-Edition-Hosting bekommst du bei odoo.sh gar nicht, bei einem eigenen Hoster dagegen als Standardfall. Genau das macht Community für Datenhoheit interessant - dazu weiter unten mehr.

Der Upgrade-Teil: Versionen springen nicht

Kern-Aussage: Wenn dein Projekt einen Versionssprung enthält, musst du eine harte Regel kennen - Odoo-Versionen lassen sich nicht überspringen. Jede Datenbank wandert Major-Version für Major-Version durch die Migrationsschritte, einen unterstützten Shortcut gibt es nicht.

Das heißt: Von Odoo 17 auf 19 führt der Weg immer über 18. Der Unterschied liegt darin, wer diese Schritte fährt. Beim OpenUpgrade-Weg der Community gehst du selbst 17 auf 18, testest, und dann 18 auf 19 - jeder Schritt ist ein eigener Lauf mit dem Upgrade-Pfad der jeweiligen Zielversion. Odoos Enterprise-Service (upgrade.odoo.com) nimmt dir diese Kette ab: Du beauftragst einmal die Zielversion, die Zwischenversionen arbeitet der Service intern der Reihe nach ab. Wer bei OpenUpgrade eine Zwischenversion auslassen will, steht ohne passende Migrationsschritte da - und am Ende mit einer Datenbank, deren Konsistenz niemand mehr garantiert.

Ob ein Upgrade überhaupt ansteht, hängt an deiner aktuellen Version. Odoo bringt jedes Jahr ein Major-Release und pflegt üblicherweise nur die drei neuesten Versionen; wer aus diesem Fenster fällt, bekommt keine Security-Fixes mehr:

Version	Jahrgang	Status
Odoo 19	2025	aktuell, ideale Zielversion
Odoo 18	2024	unterstützt
Odoo 17	2023	läuft aus, Upgrade planen

Wenn du wissen willst, welche Odoo-Version noch Support bekommt, lohnt der Blick vor jeder Planung: Eine Version ohne Security-Fixes ist im produktiven Betrieb ein Risiko, das mit der Zeit wächst. Die Detailmechanik des Versionssprungs - OpenUpgrade-Module, die Reihenfolge der OCA-Lots, die Coverage-Falle bei frischen Releases - gehört in den Upgrade-Guide und würde diesen Überblick sprengen.

Was eine Migration wirklich kostet - die echten Aufwandstreiber

Kern-Aussage: Der Preis einer Migration steht nicht auf einem Schild. Er ergibt sich aus wenigen Treibern, und wenn du die kennst, kannst du eine seriöse Schätzung von einer geratenen unterscheiden.

Aufwandstreiber	Warum er zählt
Datenmenge	größere Datenbanken und Filestores brauchen längere Transfer- und Testläufe
Modul-Set	je mehr Standardmodule, desto mehr Migrationsschritte beim Upgrade
Custom-Code	eigene Module und Anpassungen migrierst du selbst - meist der größte Posten
Drittanbieter-Module	OCA- und Fremdmodule müssen zur Zielversion passen oder angepasst werden
Integrationen	Schnittstellen zu Mail, Zahlung, Webshop, externen Systemen wollen neu verdrahtet und getestet werden
Downtime-Fenster	ein enges Go-live-Fenster erhöht den Koordinationsaufwand

Auffällig ist, was NICHT der große Kostentreiber ist: der eigentliche Datentransfer. Der Core-Lauf einer Migration ist oft der kleinere Teil. Die Zeit geht in die Vorbereitung, die Anpassung deiner eigenen Module und das Testen. Deshalb ist jede Schätzung ohne Blick auf dein konkretes Setup wertlos.

Trenn dabei zwei Kostenarten, die gern vermischt werden: die einmaligen Migrations- und Upgrade-Kosten (Vorbereitung, Custom-Migration, Tests, Go-live) und die laufenden Hosting-Kosten danach. Ein günstiger Umzug, der dich anschließend in ein teures Hosting-Modell setzt, ist keine Ersparnis - und umgekehrt kann ein etwas höherer Migrationsaufwand sinnvoll sein, wenn er dich dauerhaft aus einer Kostenfalle holt. Rechne die Migration deshalb nie isoliert, sondern zusammen mit dem, was der Betrieb danach kostet.

Für eine erste Einordnung kannst du deinen Migrationsaufwand vorab schätzen - das ersetzt keine Bestandsaufnahme, gibt dir aber ein Gefühl für die Größenordnung, bevor du in ein Gespräch gehst.

Ohne Datenverlust: Testmigration, Staging, Backup-Probe

Kern-Aussage: Datenverlust bei einer Migration ist kein Schicksal, sondern die Folge eines fehlenden Testlaufs. Ein sauberer Ablauf beweist die Migration einmal komplett, bevor irgendetwas produktiv wird. So sieht dieser Ablauf aus:

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 und der Weg festlegen.
Testmigration auf Staging. Der komplette Umzug - und, falls dabei, das Upgrade - läuft zuerst auf einer echten Staging-Instanz durch. Nichts geht live, bevor es dort sauber passt und geprüft ist.
Go-live. Geplantes Umschalten mit minimaler Downtime, inklusive DNS, Mail und Zertifikaten. Kein spontaner Sprung, sondern ein vorbereitetes Zeitfenster.
Nachlauf. Monitoring, Backup-Probe und Feinschliff nach dem Umschalten. Die ersten Tage nach dem Go-live sind Teil des Projekts, nicht das Ende.

Der Punkt, den man übersieht: die Backup-Probe. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, keine Sicherheit. Zu einem ehrlichen Ablauf gehört, die Wiederherstellung tatsächlich zu prüfen - nicht nur zu wissen, dass ein Backup existiert. Das ist der Unterschied zwischen “wir haben ein Backup” und “wir wissen, dass es funktioniert”.

Das Hosting-Setup entscheidet mit, wie ruhig dieser Ablauf läuft. Bei erpdock spiegelt die Staging-Instanz die Produktion, und der Odoo-Core-Git-Ref wird pro Instanz gepinnt. Ein Upgrade läuft dadurch kontrolliert je Instanz - nicht global über alle Instanzen auf einmal. Du testest auf einer echten Kopie, statt an der Produktiv-Datenbank zu basteln. Für den Umzug heißt das: Der Testlauf ist keine Improvisation, sondern hat eine dedizierte Umgebung.

Migration ist der richtige Moment für Datenhoheit

Kern-Aussage: Ein Hoster-Wechsel ist der eine Moment, in dem du den Serverstandort deiner Daten ohne Zusatzaufwand ändern kannst. Wenn du ohnehin umziehst, entscheidest du damit auch über Datenhoheit - also nutze den Moment.

Der Zusammenhang ist praktisch: Übermittlungen personenbezogener Daten in Drittländer brauchen nach der DSGVO eine eigene Rechtsgrundlage. Für die USA gibt es seit dem 10.07.2023 einen Angemessenheitsbeschluss - das EU-US Data Privacy Framework (Durchführungsbeschluss (EU) 2023/1795). Der deckt aber nur Anbieter, die auf der DPF-Liste stehen und jährlich re-zertifizieren; für alle anderen bleiben Standardvertragsklauseln plus eigene Prüfung im Einzelfall (Schrems II, EuGH C-311/18, 2020). Dazu kommt der CLOUD Act (18 U.S.C. § 2713): Er verpflichtet erfasste US-Anbieter zur Herausgabe von Daten in ihrem Besitz oder unter ihrer Kontrolle, “regardless of whether such communication, record, or other information is located within or outside of the United States” - der Speicherort hilft dagegen also nicht. Wer Odoo bei einem US-Anbieter hostet, handelt sich diese Prüfkette ein. Ein Umzug zu einem europäischen Anbieter mit EU-Standort löst das Problem, indem er es gar nicht erst entstehen lässt. erpdock hostet alle Kundendaten in Rechenzentren in Wien - ein Drittlandtransfer findet gar nicht erst statt.

Migration und Datenhoheit gehören also zusammengedacht. Wenn dein Umzug zugleich ein Wechsel des Serverstandorts ist, solltest du vorab die Datenhoheit beim Hoster-Wechsel klären - welche Verträge (AVV nach Art. 28 DSGVO), welche Rollen und welche Pflichten daran hängen. Das ist kein juristischer Anhang zur Migration, sondern ein Teil der Entscheidung, wohin du umziehst.

Praktisch heißt das: Kläre den Serverstandort in derselben Bestandsaufnahme, in der du Version und Module aufnimmst. Ein zweiter Umzug allein wegen des Standorts - nachdem du gerade erst umgezogen bist - ist vermeidbarer Doppelaufwand. Wer den Standort beim ersten Umzug richtig setzt, hat das Thema für Jahre vom Tisch.

Selbst migrieren oder machen lassen?

Die ehrliche Antwort: Es kommt auf dein Setup, dein Team und deine Zeit an. Ein reiner Umzug einer Standard-Instanz ist machbar, wenn du Export, Import und ein Go-live-Fenster im Griff hast. Sobald Custom-Module, ein Versionssprung oder ein enges Downtime-Fenster dazukommen, steigt das Risiko - und damit der Wert einer getesteten Vorgehensweise.

Selbst machen ergibt Sinn, wenn du eine überschaubare Instanz hast, das Wissen im Team sitzt und du eine Staging-Umgebung zum Testen hast. Ohne Testlauf sollte niemand eine produktive Odoo-Instanz umziehen oder upgraden - das ist die eine harte Grenze.

Machen lassen kannst du es über einen Odoo-Partner, der die eigentliche Migrations- und Upgrade-Arbeit übernimmt. Was erpdock beisteuert, ist das Hosting: EU-souverän in Wien, mit Staging-Instanz zum Testen und einer klaren Ablauf-Garantie. Die 48-Stunden-Garantie heißt konkret: Läuft deine Instanz nach dem Start nicht innerhalb von 48 Stunden, wird kostenlos weitergearbeitet, bis sie läuft. Du hast keinen Partner? Migration mit 48-Stunden-Garantie starten - wir bringen dich mit einem passenden Odoo-Partner zusammen und stellen das Hosting. In beiden Fällen läuft jeder Test auf einer echten Staging-Kopie - die Produktiv-Datenbank bleibt unangetastet.

Wenn du erst einmal nur die Lage sortieren willst, ist ein kurzes Erstgespräch der pragmatische Startpunkt: klären, ob du eine Migration, ein Upgrade oder beides vor dir hast - und was das in deinem Fall bedeutet.

FAQ

Was ist der Unterschied zwischen Odoo-Migration und Odoo-Upgrade? Migration ist der Umzug an einen neuen Ort (Hoster, Server, Land) bei gleicher Version. Upgrade ist der Sprung auf eine neuere Odoo-Version am gleichen Ort. Häufig fällt beides in ein Projekt - dann trennst du die zwei Schritte am besten bewusst.

Kann ich Odoo von odoo.sh auf einen eigenen Hoster umziehen? Ja. Datenbank und Filestore lassen sich exportieren und auf einem anderen Hoster einspielen. Bei Community ist das frei möglich, bei Enterprise hängt die Portabilität an deiner gültigen Subscription. Der Umzug selbst funktioniert in beiden Fällen.

Verliere ich bei einer Odoo-Migration Daten? Bei einem getesteten Ablauf nicht. Die Testmigration läuft komplett auf einer Staging-Instanz durch, und die Backup-Wiederherstellung wird geprüft, bevor das Go-live stattfindet. Datenverlust entsteht dort, wo dieser Testlauf fehlt.

Muss ich beim Hoster-Wechsel auch die Odoo-Version upgraden? Nein. Ein reiner Umzug behält deine Version. Ob du zusätzlich upgradest, ist eine separate Entscheidung - getrieben davon, ob deine Version noch Security-Support bekommt oder ob du neue Features brauchst.

Wie lange dauert eine Odoo-Migration? Das hängt an Datenmenge, Modul-Set und Custom-Code. Der eigentliche Datentransfer ist meist der kleinere Teil; der große Posten ist die Anpassung deiner eigenen Module und das Testen. Eine seriöse Dauer nennt dir erst die Bestandsaufnahme.