700 Tabellen, null Datenverlust

„Können Sie unser Odoo auf einen neuen Server umziehen, ohne dass wir etwas verlieren?" ist eine der häufigsten - und nachvollziehbarsten - Sorgen eines Gründers. Eine Odoo-Migration auf einen neuen Server berührt alles gleichzeitig: die Datenbank, den Filestore, die individuellen Module, die Konfiguration. Und der schlimmste Fehlerfall ist lautlos: eine Handvoll Zeilen, die es leise nicht geschafft haben, entdeckt Wochen später, wenn ein Report nicht aufgeht. So machen Sie diesen Umzug langweilig statt beängstigend.

Warum Migrationen zu Recht Angst machen

Eine Migration macht Angst, weil sie in der Wahrnehmung Alles-oder-nichts ist, in der Realität aber teilweise. Der naive Ansatz - ein Backup exportieren, auf der neuen Maschine wiederherstellen, DNS umbiegen, hoffen - funktioniert meistens, und genau das macht ihn gefährlich. Wenn es nicht funktioniert, merken Sie es oft nicht sofort. Ein Filestore, der nicht vollständig kopiert wurde, heißt: Anhänge werfen später einen 404. Eine zurückgesetzte Sequenz heißt: Rechnungsnummern kollidieren. Ein individuelles Modul, das nicht mitgenommen wurde, heißt: ein Menü ist einfach weg. Der Einsatz ist hoch, und das Feedback kommt verzögert - die schlechteste Kombination fürs Vertrauen.

Inspizieren, bevor Sie umziehen

Der erste Schritt einer sicheren Odoo-Migration auf einen neuen Server ist kein Transfer - es ist eine Inspektion. Bevor irgendetwas umzieht, messen Sie genau, was auf der Quelle liegt: wie viele Datenbanken, welche Odoo-Version, welche PostgreSQL-Version, Größe und Form des Filestores, und jedes individuelle oder Drittanbieter-Modul im Addons-Pfad. Sie können keinen Umzug validieren, den Sie nie gemessen haben, und die meisten Migrations-Desaster lassen sich auf eine Überraschung zurückführen, die eine Inspektion aufgedeckt hätte - ein undokumentiertes Modul, eine Versions-Diskrepanz, ein Filestore an einem unüblichen Ort.

Die Inspektion zeigt auch, ob es ein reiner Umzug ist oder Umzug plus Upgrade. Braucht das Ziel eine neuere Odoo-Version, ist das ein anderer Job mit eigener Probe - siehe Upgrades ohne Panik. Die beiden Anliegen getrennt zu halten, ist Teil dessen, was eine Migration sauber hält: erst umziehen, dann aktualisieren, niemals beides gleichzeitig blind.

Übertragen, dann beweisen

Die eigentliche Übertragung läuft Server-zu-Server statt als fragiler Export/Import-Tanz über einen Laptop. Die Datenbank geht mit pg_dump und Restore hinüber, der Filestore wird vollständig kopiert, und Addons und Konfiguration kommen mit, sodass die neue Maschine ein originalgetreues Abbild ist, keine Annäherung.

Aber die Übertragung ist nicht das Ende - der Beweis ist es. Der Schritt, der aus einer Migration eine ingenieurmäßige Aufgabe statt eines Vertrauensvorschusses macht, ist die Vollständigkeitsprüfung auf der Zielseite. Zeilenanzahlen müssen übereinstimmen, Tabelle für Tabelle. Hat die Quelle eine bestimmte Anzahl Datensätze in einem Modell, muss das Ziel exakt dieselbe Anzahl haben. Bei einem echten Odoo sind das mehrere hundert Tabellen zum Abgleichen - die letzte, die wir durchgegangen sind, hatte über 700. Stimmen alle Zählungen, ist der Umzug beweisbar vollständig, nicht nur scheinbar vollständig.

Rollback als Standard, nicht als Nachgedanke

Selbst eine sorgfältige Migration kann auf Unerwartetes stoßen, deshalb geht das sichere Design davon aus, dass sie es könnte. Findet die Validierung eine Abweichung - eine Zählung, die nicht stimmt, eine Tabelle, die nicht abgeglichen hat - rollt der Umzug automatisch zurück und stellt Sie genau dort ab, wo Sie gestartet sind. Es gibt kein Halb-migriert-Limbo, in dem das alte System schon abgebaut ist und das neue noch nicht vertrauenswürdig. Das Original bleibt live und unangetastet, bis das Abbild bewiesen ist, und die Umschaltung ist das buchstäblich Letzte, was passiert.

Deshalb läuft eine agentengestützte Migration auch nach dem Prinzip Vorschau zuerst. Bevor der Transfer läuft, zeigt der Agent den Plan: was er bei der Inspektion gelesen hat, was er umziehen will, und wie der Rollback-Pfad aussieht. Auf der Quelle passiert nichts Destruktives, ohne dass ein Mensch den Plan zuvor bestätigt. Das Gate ist es, was erlaubt, etwas so Folgenreiches zu automatisieren, ohne die Luft anzuhalten.

Das langweilige Ergebnis

So gemacht, ist das Ergebnis im besten Sinne antiklimaktisch: 700+ Tabellen umgezogen, null Datenverlust, eine Umschaltung, die niemand bemerkt hat. Das ist das ganze Ziel. Eine Migration sollte keine Heldentaten oder einen Kriseneinsatz erfordern - sie sollte ein gemessener, validierter Umzug mit einem Sicherheitsnetz unter jedem Schritt sein. Aufregung ist ein Zeichen, dass etwas schiefgelaufen ist, nicht dass es gut gelaufen ist. Und weil das Original nie abgebaut wird, bevor das Abbild bewiesen ist, ist der schlimmste realistische Fall, dass Sie einen Abend investieren und genau dort landen, wo Sie gestartet sind - ärgerlich, aber keine Katastrophe. Diese Asymmetrie, kleiner Nachteil gegen einen sauberen Umzug, ist es, was erlaubt, eine Migration in einer ganz normalen Woche einzuplanen, statt sie ein Quartal lang zu fürchten.

FAQ

Wie migriere ich Odoo auf einen neuen Server, ohne Daten zu verlieren?

Inspizieren Sie zuerst die Quelle, damit Sie genau wissen, was umzieht, führen Sie einen Server-zu-Server-Transfer von Datenbank und Filestore durch, und validieren Sie die Vollständigkeit, indem Sie Zeilenanzahlen Tabelle für Tabelle abgleichen. Halten Sie einen automatischen Rollback bereit, damit jede Abweichung Sie unversehrt zum Original zurückbringt. Diese Abfolge macht eine Odoo-Migration auf einen neuen Server beweisbar verlustfrei.

Wie lange dauert eine Odoo-Migration?

Ein reiner Umzug ohne Versionswechsel ist meist in Stunden zu messen, dominiert davon, wie groß Filestore und Datenbank zum Kopieren sind. Die Validierung kostet Zeit, aber kein Risiko. Migrationen wachsen sich zu Wochen aus, wenn sie mit einem Versions-Upgrade oder einer Überarbeitung individueller Module kombiniert werden - weshalb es sauberer ist, das als getrennte Aufgaben zu behandeln.

Reicht pg_dump, um Odoo umzuziehen?

pg_dump deckt die Datenbank ab, aber Odoo hat auch einen Filestore mit Anhängen und Dokumenten, der außerhalb von PostgreSQL liegt, dazu individuelle Module und Konfiguration. Eine vollständige Migration kopiert all das und prüft dann das Ergebnis - die Datenbank allein ist nur ein Teil des Systems.