Bestehende Odoo-Instanz übernehmen: Prüfliste
Kurz gesagt
Prüfen Sie vor der Übernahme den Vertrag, die Module samt Quellcode und Lizenz, die Benutzer- und Zugangsliste und eine Sicherung, die Sie selbst in einer Kopie wiederhergestellt haben. Die Enterprise-Lizenz ist nicht übertragbar und darf nur mit gültigem Abonnement für die richtige Zahl von Benutzern laufen (Ziffer 3 des Abonnementvertrags). Auf Odoo Online wechselt der Eigentümer per Support-Ticket.
Das Wichtigste
- Die Enterprise-Lizenz ist nicht übertragbar (Ziffer 3); für den Betrieb muss eine gültige Nutzungsberechtigung mit Abonnement für die richtige Zahl von Benutzern bestehen, und ob das Abonnement fortgeführt oder übernommen wird, klären Sie mit Odoo.
- Auf Odoo Online wechselt der Eigentümer über ein Support-Ticket (Transfer Ownership im Datenbankmanager).
- Eigener und fremder Modulcode liegt nicht in der Sicherung; ohne Quellcode fehlen die Module nach dem Import.
- Odoo Online unterstützt weder eigene Module mit Quellcode noch Module aus dem Apps-Store.
- Odoo Cloud (SLA): 14 vollständige Sicherungen — 1/Tag für 7 Tage, 1/Woche für 4 Wochen, 1/Monat für 3+ Monate.
- Ein festes Sperrdatum (Hard Lock Date) bleibt nach der Übernahme unumkehrbar.
Wer eine laufende Datenbank übernimmt, übernimmt ihre Bindungen mit: ein Abonnement, das an die Zahl der Benutzer gekoppelt ist, einen Buchhaltungsstand mit möglicherweise gesetzten Sperren und Zugänge, die bisher andere hatten. Die Dokumentation beschreibt den technischen Weg über Sicherung und Import; diese Prüfliste ordnet, was vorher zu klären ist.
Was Sie vorab brauchen
- Administratorzugang zur Datenbank, bei eigener Installation zusätzlich den Serverzugang und das Master-Passwort, das der Datenbankmanager für Sicherungen verlangt
- die Abonnementunterlagen: Vertragsnummer oder Subscription Code, Laufzeit, Tarif, vereinbarte Benutzerzahl und der benannte Hauptansprechpartner
- Angaben zu Version und Hostingmodell, denn Odoo Online, Odoo.sh und ein eigener Server unterscheiden sich in Zugriff, Modulen und Sicherungen
- die Modulliste und der Zugang zu den Quellcode-Repositories aller Erweiterungen
- eine vollständige Sicherung als ZIP einschließlich Filestore und eine Testkopie, in der Sie sie prüfen
Die Prüfliste: Module, Benutzer, eigener Code, Sicherungen, Vertrag
Die Zuordnung ist eine redaktionelle Empfehlung; die Fundstellen sind die Stellen in Odoo und in den Vertragsunterlagen, an denen Sie nachsehen.
| Prüfpunkt | Fundstelle | Mangel |
|---|---|---|
| Abonnement und Laufzeit | Abonnementunterlagen, Subscription Code, Datenbankmanager | Abonnement nicht im eigenen Namen, Laufzeitende vor der Übergabe, versäumte Kündigungsfrist |
| Benutzerzahl | Settings ▸ Users ▸ Manage Users; Abonnementunterlagen | mehr aktive interne Benutzer als vereinbart |
| Benutzertypen | Benutzerliste mit Rollen | die eigene Zählung wirft aktive interne Benutzer, Light-Benutzer und Portal-Konten durcheinander; nach Ziffer 2 zählen deaktivierte Konten und Portal-Konten nicht als Benutzer, Light-Benutzer sind eine eigene Kategorie |
| Module | Apps mit Filter Apps, für technische Module Filter Extra | Module aus dem Apps-Store oder eigene Module mit Quellcode auf Odoo Online |
| Eigener Code | Repository und Manifest je Erweiterung: Autor, Version, Lizenz | kein Quellcode, unklare Lizenz, kein benannter Maintainer |
| Studio-Anpassungen | angepasste Felder, Ansichten, Automatisierungen | Studio im Tarif Standard, undokumentierte Anpassungen |
| Fremdmodule | Manifest-Schlüssel development_status im eingesetzten Zweig | Reifegrad Alpha oder Beta im Produktivbetrieb |
| Sperrdaten | Accounting ▸ Accounting ▸ Lock Dates | festes Sperrdatum verhindert Korrekturen und lässt sich nicht aufheben |
| Sicherungen | Sicherungsreiter des Projekts (Odoo.sh), Datenbankmanager (Odoo Online) | keine aktuelle Sicherung, kein eigener Wiederherstellungstest |
| Datenstandort | Datenschutzerklärung der Odoo-Cloud, Vertragsunterlagen | Produktions- oder Sicherungsorte passen nicht zu den Vorgaben Ihrer Datenschutzstelle |
| Zugänge | Benutzerliste, GitHub-Mitglieder bei Odoo.sh, API-Schlüssel, Mailserver | Konten und Schlüssel des bisherigen Betreibers bleiben aktiv |
| Wartung der Zusatzmodule | Vertragsunterlagen, Wartungsentgelt je Modul | Module ohne Wartungsentgelt, Nachzahlung beim Upgrade möglich |
Schritt für Schritt: von der Übergabe zur eigenen Instanz
Schritt 1: Vertrag und Eigentum klären
Klären Sie zuerst, wer Vertragspartei ist. Die Lizenz der Enterprise Edition ist nicht übertragbar, sie erlischt mit Ablauf oder Beendigung des Vertrags, und die Vereinbarung verlängert sich automatisch um dieselbe Laufzeit, wenn keine Partei mindestens 30 Tage vor Ende schriftlich kündigt (Ziffern 1 und 3). Ohne Enterprise-Abonnement bleibt die Community Edition unter der LGPLv3.
Prüfen Sie, ob die Datenbank bisher mit gültigem Abonnement für die richtige Zahl von Benutzern lief; ein Verstoß gegen Ziffer 3 löst laut Vertrag eine zusätzliche Gebühr von 300 Prozent des Listenpreises für die tatsächliche Zahl von Benutzern und Light-Benutzern aus. Auf Odoo Online beantragen Sie den Eigentümerwechsel über ein Support-Ticket. Wechselt der Hauptansprechpartner zu einem anderen Odoo-Partner oder direkt zu Odoo S.A., verlangt Ziffer 6.1 eine schriftliche Mitteilung 30 Tage im Voraus. Was der Vertrag sonst verlangt, steht unter Odoo-Enterprise-Vertrag und Pflichten.
Schritt 2: Version und Supportstatus festhalten
Notieren Sie Hauptversion, Zwischenversion und Hostingmodell. Der Standard-Support einer Hauptversion dauert drei Jahre ab Veröffentlichung (Odoo 20.0: September 2026 bis voraussichtlich September 2029); Extended Support gibt es nur für Odoo.sh und eine eigene Installation, nicht für Odoo Online. Ein Upgrade ist von jeder Version auf jede Hauptversion möglich, die noch Standard-Support hat oder deren Standard-Support seit weniger als sechs Monaten beendet ist. Auf Odoo Online ist das Upgrade sogar Pflicht: bei einer Hauptversion alle zwei Jahre, bei einer Zwischenversion wenige Wochen nach dem Erscheinen der nächsten Version. Der Wechsel des Hostingmodells ist kein Upgrade; die Dokumentation zählt ihn nicht zu den Leistungen des Upgrade-Dienstes.
Schritt 3: Module auflisten (Administratorrechte)
Schalten Sie den Entwicklermodus ein (Settings, Abschnitt Developer Tools, Activate the developer mode) und öffnen Sie Apps ▸ Update Apps List. In der App-Liste ist der Filter Apps voreingestellt; wählen Sie unter Filters den Eintrag Extra, um technische Module zu sehen. Entfernen Sie in dieser Prüfung nichts: Das Deinstallieren einer App löscht ihre Datenbankdatensätze, und Abhängigkeiten ziehen weitere Module mit. Vergleichen Sie die Liste anschließend mit den Modulen, die im Vertrag als abgedeckte Zusatzmodule geführt werden.
Schritt 4: Eigenen Code und Studio-Anpassungen prüfen
Der Vertrag fasst unter Extra Module jede Erweiterung: ein Verzeichnis mit Quellcode oder eine mit Python erstellte Anpassung in der Datenbank, etwa mit Odoo Studio (Ziffer 2). Verlangen Sie je Modul die Angaben des Manifests (manifest.py): author, version, license und maintainer; ohne Maintainer gilt der Autor als pflegende Person. Das Feld license kennt unter anderem LGPL-3, OPL-1 und OEEL-1. Bei Modulen der Odoo Community Association (OCA) steht der Reifegrad im Schlüssel development_status; ohne Angabe gilt Beta. Auf Odoo Online sind eigene Module und Module aus dem Apps-Store nicht möglich, und Studio löst im Tarif Standard den Wechsel zu Custom aus.
Abgedeckte Zusatzmodule werden monatlich je 100 Codezeilen abgerechnet, gezählt mit dem Werkzeug cloc; bei einem Upgrade darf Odoo für jedes Modul, das in den letzten zwölf Monaten ohne Wartungsentgelt war, einmalig je fehlendem Monat nachberechnen (Ziffern 2 und 5.1). Klären Sie deshalb, wem der Quellcode gehört und wer ihn pflegt. Wie Sie Fremdmodule bewerten, beschreibt Prüfkriterien für Fremdmodule.
Schritt 5: Sicherung ziehen und in einer Kopie wiederherstellen
Laden Sie eine vollständige Sicherung selbst herunter, nicht nur die Sicherung, die das Hosting ohnehin vorhält.
- Eigene Installation:
/web/database/manager, Schaltfläche Backup, Format zip einschließlich Filestore; dafür ist das Master-Passwort nötig. - Odoo Online: im Datenbankmanager über Download Backup. Ist der Download gesperrt, ist die Datenbank für diesen Weg zu groß; dann führt der Weg über ein Support-Ticket.
- Odoo.sh: Reiter Backups des Produktionszweigs. Der Import überschreibt alle Daten im Zweig, verlangt freien Speicher in der vierfachen Größe der Sicherung und ist nur für Hauptversionen möglich. Nach dem Import gilt die Datenbank als Duplikat und ist vom Abonnement getrennt; je Abonnement ist nur eine aktive Datenbank zulässig, also alte abmelden und neue registrieren. Ausgehende Mailserver werden abgeschaltet, Odoo.sh nutzt seinen eigenen Mailserver; für einen externen SMTP-Server sind die Ports 465 und 587 vorgesehen, Port 25 bleibt geschlossen.
Prüfkopien sind neutralisiert: geplante Aktionen, ausgehende E-Mails, Banksynchronisation, Zahlungsanbieter, Versandarten und die Indexierung durch Suchmaschinen sind abgeschaltet. Auf Odoo Online ist beim Duplizieren die Option For testing purposes voreingestellt, Duplikate werden nach 15 Tagen gelöscht, höchstens fünf je Datenbank. Den Ablauf beschreibt Odoo-Datenbank exportieren und wiederherstellen.
Die Cloud-SLA nennt 14 vollständige Sicherungen (1/Tag für 7 Tage, 1/Woche für 4 Wochen, 1/Monat für 3+ Monate), einen Recovery Point Objective von 24 Stunden und einen Recovery Time Objective von 6 Stunden bei einem Schaden an einem einzelnen Server. Auf der Projektebene von Odoo.sh sind es sieben tägliche, vier wöchentliche und drei monatliche Sicherungen des Produktionszweigs; Entwicklungszweige werden nicht automatisch gesichert. Die Sicherungsorte sind nicht wählbar: In der Region Europa liegen die Produktionsdatenbanken in Frankreich und Belgien, die Sicherungen in Frankreich, den Niederlanden und Schweden, für ältere EU-gehostete Datenbanken bis zum Abschluss der Umstellung zusätzlich in Kanada.
Eine Sicherung ist kein Archiv. Aufzeichnungen und Belege bleiben bis zum Ablauf ihrer Frist aufzubewahren: in Deutschland zehn Jahre für Bücher und Aufzeichnungen, acht Jahre für Buchungsbelege und sechs Jahre für die übrigen Unterlagen, soweit nicht andere Steuergesetze kürzere Fristen zulassen; die Frist läuft nicht ab, solange die Unterlagen für eine Steuer mit noch laufender Festsetzungsfrist von Bedeutung sind, Lieferscheine ohne Buchungsbelegfunktion enden mit dem Erhalt oder dem Versand der Rechnung, und für Kreditinstitute, Versicherungsunternehmen und Wertpapierinstitute bleibt es nach Art. 97 § 19a Abs. 3 EGAO bei der früheren Zehnjahresfrist (§ 147 Abs. 3 Sätze 1, 3, 4 und 5 AO), in Österreich sieben Jahre für Bücher und Aufzeichnungen samt den zugehörigen Belegen (§ 132 Abs. 1 BAO) und in der Schweiz zehn Jahre ab Ablauf des Geschäftsjahres für Geschäftsbücher und Buchungsbelege (Art. 958f Abs. 1 OR). Halten Sie fest, wer das nach der Übergabe tut; die Einzelheiten stehen in Datenübernahme aus dem Altsystem.
Schritt 6: Benutzer, Rollen und Zugänge neu setzen
Öffnen Sie Settings ▸ Users ▸ Manage Users. Odoo kennt drei Benutzertypen: interne Benutzer, Portal- und Public-Benutzer. Für den Vertrag zählt jedes aktive Konto, das kein Light-Benutzer ist; deaktivierte Konten und Portal-Benutzer zählen nicht mit (Ziffer 2). Deaktivieren Sie Konten, die nicht mehr dazugehören (Actions ▸ Archive), und prüfen Sie im Benutzerprofil unter My Preferences ▸ Security die Liste der angemeldeten Geräte; ein Gerät lässt sich dort mit Passwortbestätigung abmelden. Die Zwei-Faktor-Authentifizierung schalten Sie ebenfalls in My Preferences ▸ Security ein, für alle Benutzer unter Settings ▸ Permissions (Enforce two-factor authentication); in fiscal localizations einiger Länder lässt sie sich nicht abschalten.
Rechte ändern darf nur ein Administrator, und fremde Rechte ändert ein Benutzer nur, wenn in seinem Profil im Feld Administration der Eintrag Access Rights gesetzt ist; unbedachte Änderungen können eine Datenbank ohne handlungsfähigen Administrator hinterlassen. Bei Odoo.sh prüfen Sie zusätzlich die Mitgliederliste des Projekts: Sie besteht aus GitHub-Benutzern mit den Rollen Admin, Tester oder Developer, und nur Admin hat Zugriff auf die Projekteinstellungen. Für das Sperren von Zugängen gilt dasselbe Vorgehen wie beim Austritt einer Mitarbeiterin oder eines Mitarbeiters, beschrieben unter Odoo-Zugänge sperren.
So prüfen Sie das Ergebnis
- Die Sicherung liegt vollständig als ZIP mit Filestore vor und ließ sich in einer Kopie fehlerfrei einspielen.
- Die Zahl der aktiven internen Benutzer stimmt mit dem Abonnement überein; Portal- und deaktivierte Konten sind getrennt ausgewiesen.
- Für jedes Modul sind Quellcode, Autor, Version, Lizenz und pflegende Person bekannt, die Wartungsentgelte sind zugeordnet.
- Version und Supportstatus sind dokumentiert, und keine Erweiterung steht ohne Quellcode für die nächste Zielversion da.
- Sperrdaten sind geprüft und festgehalten; das feste Sperrdatum ist als unumkehrbar bekannt.
- Die Kopie sendet keine E-Mails und löst keine Zahlungen oder Versandaufträge aus; die Zugänge des bisherigen Betreibers sind entfernt.
Wenn etwas nicht klappt
| Symptom | Ursache | Abhilfe |
|---|---|---|
| Der Download im Datenbankmanager ist gesperrt | die Datenbank ist für diesen Weg zu groß | ein alternatives Verfahren über ein Support-Ticket anfordern |
| Nach dem Import fehlen Module | die Sicherung enthält Datenbank und Filestore (Anhänge und Binärfelder), keinen Modulcode | Modulordner in einen Zweig des GitHub-Repositorys legen, bei eigener Installation den Quellcode einspielen |
| Die importierte Datenbank löst Abonnement-Warnungen aus | sie gilt als Duplikat und ist vom Abonnement getrennt | die alte Datenbank abmelden und die neue registrieren |
| Das Upgrade wird abgelehnt | eigene Module ohne Quellcode für die Zielversion | den Quellcode zuerst anheben, parallel die Testdatenbank anfordern |
| Der bisherige Dienstleister kommt weiter in die Datenbank | Benutzerkonto, GitHub-Mitgliedschaft oder API-Schlüssel blieb aktiv | die Zugänge einzeln entziehen und danach die Anmeldungen prüfen |
Wann Sie Hilfe holen sollten
Holen Sie Odoo oder einen Dienstleister dazu, wenn die Datenbank eigene Module enthält, deren Quellcode Sie nicht selbst pflegen, wenn die Zahl der Benutzer im Vertrag nicht zur tatsächlichen Nutzung passt oder wenn der Eigentümerwechsel nicht zustande kommt. Fragen zum Vertragswerk und zur Vergütung der Zusatzmodule klären Sie mit Ihrer Rechts- oder Steuerberatung, die Grundlage des Zugriffs nach der Übergabe mit Ihrer Datenschutzstelle. Planen Sie diese Prüfung zusammen mit dem Abnahmetest, statt zwei Testreihen nebeneinander zu führen.