Migration von Odoo 17/18 auf Odoo 19: Vollständiger Leitfaden

Die Migration ist einer der risikoreichsten Vorgänge im ERP-Lebenszyklus – Datenverlust, defekte benutzerdefinierte Module und längere Ausfallzeiten sind echte Risiken, die eine sorgfältige Planung und Durchführung erfordern.

Dieser Leitfaden bietet eine praktische, schrittweise Migrationsmethode für Unternehmen, die von Odoo 17 oder Odoo 18 auf Odoo 19 Enterprise umsteigen. Es deckt alles ab, von der Erstbewertung und Datenzuordnung bis hin zu benutzerdefinierten Modulaktualisierungen, Testverfahren und dem Go-Live-Umstellungsplan.

Wichtige Erkenntnisse

• Die Kompatibilität benutzerdefinierter Module muss anhand der API-Änderungen von Odoo 19 überprüft werden
• Die Datenmigration erfolgt über die offizielle Upgrade-Plattform von Odoo oder OpenUpgrade
• Vor der Produktionsumstellung ist eine parallele Testumgebung zwingend erforderlich
• Finanzperioden müssen vor der Umstellung geschlossen werden, um Abstimmungsprobleme zu vermeiden
• Alle Integrationen von Drittanbietern müssen nach der Migration erneut überprüft werden
• Der Rollback-Plan muss vor dem Go-Live dokumentiert und getestet werden

---

Migrationsplanung: Bewertungsphase

Bevor Sie ein einzelnes Migrationsskript schreiben, sollten Sie sich Zeit für eine gründliche Bewertung nehmen. Migrationen scheitern meist an unzureichender Planung und nicht an technischer Komplexität.

Schritt 1: Inventarisieren Sie Ihre aktuelle Umgebung

Dokumentieren Sie jede Komponente Ihrer aktuellen Odoo-Installation:

Current Environment Inventory:
- Odoo version: 17.0.x or 18.0.x
- Edition: Community or Enterprise
- Database size: X GB, Y records in sale.order, Z in account.move
- Installed modules: [list all modules]
- Custom modules: [list with developer contact]
- Third-party connectors: [Amazon, Shopify, etc.]
- Active integrations: [API, webhooks, cron jobs]
- Customized reports: [list]
- Custom fields (Studio or code): [list]
- Server specs: RAM, CPU, disk
- PostgreSQL version:

Schritt 2: Benutzerdefinierte Module klassifizieren

Bestimmen Sie für jedes benutzerdefinierte Modul Folgendes:

---

Wählen Sie Ihren Migrationspfad

Pfad 1: Offizieller Odoo-Upgrade-Service

Odoo SA bietet einen automatisierten Upgrade-Service unter upgrade.odoo.com an. Sie übermitteln Ihre Datenbank, sie führen von Odoo SA entwickelte und gepflegte Migrationsskripte aus und Sie erhalten eine aktualisierte Datenbank.

Vorteile:

• Offizieller Support und Tests durch Odoo SA
• Behandelt Datenbankschemaänderungen automatisch
• Geeignet für Standard-Odoo mit minimalen Anpassungen

Nachteile:

• Erfordert die Übermittlung von Produktionsdaten an die Server von Odoo
• Begrenzte Kontrolle über den Migrationsprozess
• Die Migration kundenspezifischer Module liegt in Ihrer Verantwortung

Pfad 2: OpenUpgrade (Community-Tool)

OpenUpgrade ist ein Open-Source-Projekt, das Migrationsskripte für Community bereitstellt.

Pfad 3: Neuinstallation mit Datenimport

Für stark angepasste Instanzen oder sehr alte Versionen:

1. Richten Sie eine neue Odoo 19 Enterprise-Instanz ein
2. Konfigurieren Sie alle Module und Einstellungen neu
3. Exportieren Sie kritische Daten aus dem alten System
4. Importieren Sie über das Importtool von Odoo oder benutzerdefinierte Migrationsskripte
5. Geben Sie die Anfangssalden für die Buchhaltung manuell erneut ein

Dieser Pfad ist langsamer, bietet aber den saubersten Ausgangspunkt.

Empfohlen für die meisten Odoo 17/18 → 19-Migrationen: Pfad 1 oder 2 kombiniert mit einem parallelen Neuentwicklungsaufwand für benutzerdefinierte Module.

---

Vorbereitung vor der Migration

Finanzperioden abschließen:

Vor der Migration:

1. Sperren Sie alle Perioden vor dem aktuellen Monat in Odoo Accounting
2. Führen Sie die Berichte zu gealterten Forderungen und Verbindlichkeiten durch und gleichen Sie Differenzen ab
3. Gleichen Sie alle Kontoauszüge bis zum Migrationsdatum ab
4. Verbuchen Sie alle Rechnungsentwürfe, die in den historischen Daten enthalten sein sollen

Alles sichern:

# PostgreSQL backup
pg_dump -h localhost -U odoo_user -Fc odoo_production > \
    odoo_prod_backup_$(date +%Y%m%d_%H%M%S).dump

# Filestore backup (attachments, images)
tar -czf odoo_filestore_$(date +%Y%m%d).tar.gz \
    /var/lib/odoo/.local/share/Odoo/filestore/

# Configuration backup
cp /etc/odoo/odoo.conf odoo_conf_backup_$(date +%Y%m%d).conf

---

Einrichten der Migrationsumgebung

Infrastrukturaufbau:

# Install Odoo 19 Enterprise on migration server

# Install PostgreSQL 15+
sudo apt install postgresql-15 postgresql-contrib

# Install Python 3.12 and dependencies
sudo apt install python3.12 python3.12-dev python3.12-venv \
    libxml2-dev libxslt1-dev libldap2-dev libsasl2-dev \
    libtiff5-dev libjpeg8-dev libopenjp2-7-dev zlib1g-dev \
    libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev \
    libfribidi-dev libxcb1-dev

# Clone Odoo 19 Enterprise
git clone https://github.com/odoo/odoo.git -b 19.0 /opt/odoo19
git clone https://github.com/odoo/enterprise.git -b 19.0 /opt/odoo19-enterprise

# Install Python dependencies
pip3.12 install -r /opt/odoo19/requirements.txt

---

Migration benutzerdefinierter Module

Diese Phase ist die zeitintensivste. Für jedes benutzerdefinierte Modul ist Folgendes erforderlich:

1. Manifestversion aktualisieren:

# Change from:
'version': '17.0.1.0.0',
# To:
'version': '19.0.1.0.0',

2. Syntax der Ansicht aktualisieren:

<!-- Old (v16 and earlier): -->
<field name="state" attrs="{'invisible': [('active', '=', False)]}"/>

<!-- New (v17+): -->
<field name="state" invisible="not active"/>

3. Testen Sie jedes Modul einzeln:

# Install and test each custom module
python3 odoo-bin -d test_db -i my_custom_module --stop-after-init
python3 odoo-bin -d test_db --test-enable -u my_custom_module

---

Datenvalidierung und Tests

Validierung der Datensatzanzahl:

Vergleichen Sie die Datensatzanzahl zwischen Quell- und migrierter Datenbank:

# Run on both source and target to compare
models_to_check = [
    'res.partner', 'product.template', 'product.product',
    'sale.order', 'purchase.order', 'account.move',
    'stock.quant', 'mrp.production', 'hr.employee'
]

for model in models_to_check:
    count = env[model].search_count([])
    print(f"{model}: {count}")

Checkliste für Benutzerakzeptanztests:

• Alle Menüs und Navigationselemente zugänglich
• Wichtige Arbeitsabläufe: Verkaufsauftrag → Lieferung → Rechnung → Zahlung
• Buchhaltung: Journaleinträge, Bankabstimmung, Berichte
• Inventar: Eingänge, Lieferungen, Bestandsbewertung
• Fertigung: Stückliste, Arbeitsaufträge, Qualitätsprüfungen (falls zutreffend)
• HR: Mitarbeiter, Urlaubsmanagement, Gehaltsabrechnung (falls zutreffend)
• Benutzerdefinierte Modulfunktionalität, die von Geschäftsbenutzern überprüft wurde
• Berichte werden korrekt generiert und stimmen mit der Ausgabe vor der Migration überein
• Externe Integrationen (API, Webhooks) im Staging getestet

---

Go-Live-Cutover-Plan

Cutover-Fensterplanung:

Wählen Sie ein Umstellungsfenster mit minimalen Auswirkungen auf das Geschäft:

• Wochenende (Samstagabend bis Sonntagmorgen für die meisten Unternehmen)
• Ende des Geschäftsjahres (vereinfacht die Eingabe des Eröffnungssaldos)
• Nach dem letzten Werktag vor einem Feiertag (zusätzliche Pufferzeit)

Checkliste für die Umstellung:

T-48 hours:
[ ] Final communication to all users about downtime window
[ ] Freeze all non-critical transactions in old system
[ ] Verify migration server is ready
[ ] Complete last data validation run

T-0 (Cutover Start):
[ ] Put old system in maintenance mode (disable user access)
[ ] Create final backup of production database
[ ] Run final migration on this backup
[ ] Verify record counts and financial balances
[ ] Test all critical workflows
[ ] DNS/URL cutover to new system
[ ] Smoke test from user devices (desktop, mobile)

T+2 hours (Go-Live Verification):
[ ] All users can log in
[ ] Create test sale order, confirm, ship, invoice
[ ] Verify email sending works
[ ] Check integrations are receiving/sending data
[ ] Monitor error logs for first 30 minutes

Rollback-Plan:

Wenn während der Umstellung kritische Probleme festgestellt werden:

1. DNS zurück zum alten Server wechseln
2. Aktivieren Sie das alte System erneut für Benutzer
3. Dokumentieren Sie alle gefundenen Probleme
4. Planen Sie ein Folgemigrationsfenster

---

Häufig gestellte Fragen

Kann ich von Odoo 17 direkt zu Odoo 19 springen oder muss ich 18 durchlaufen?

Mit dem offiziellen Upgrade-Service von Odoo können Sie in der Regel direkt von 17 auf 19 wechseln. Die Migrationsskripte von Odoo SA handhaben Sprünge mehrerer Versionen. Überprüfen Sie immer das OpenUpgrade-Repository auf die spezifischen Versionen, die Sie benötigen.

Wie lange dauert eine typische Odoo-Migration?

Die Zeitleiste hängt stark vom Anpassungsgrad ab. Die Migration selbst (Datenbank-Upgrade) dauert Stunden; Die Zeit liegt im Testen, Modulaktualisierungen und der Validierung.

Was passiert mit Studio-Anpassungen während der Migration?

Studio-Anpassungen werden als Standard-Odoo-Daten (Ansichten, Felder, Automatisierungen) gespeichert und über den Standard-Datenbank-Upgrade-Prozess migriert. Einige Ansichtsanpassungen müssen jedoch möglicherweise manuell überprüft werden, wenn Odoo 19 die zugrunde liegende Formularstruktur geändert hat. Testen Sie nach der Migration immer alle Studio-Anpassungen.

Muss ich die Anfangssalden nach der Migration erneut eingeben?

Nein, wenn Sie die Datenbank direkt migrieren. Alle historischen Journaleinträge und Salden werden mit der Datenbank übertragen. Wenn Sie den Pfad „Neuinstallation mit Datenimport“ wählen, müssen Sie Anfangssalden zum Umstellungsdatum eingeben, was eine sorgfältige Abstimmung mit Ihrem Buchhaltungsteam erfordert.

---

Nächste Schritte

Odoo-Migrationen sind Projekte mit hohem Risiko, die sich direkt auf die Geschäftskontinuität auswirken. Der Unterschied zwischen einer reibungslosen und einer schmerzhaften Migration liegt in der Vorbereitung, dem Fachwissen und einer strengen Testmethodik.

Unsere Migrationsmethodik umfasst eine vollständige Bewertung, benutzerdefinierte Modulaktualisierungen, parallele Tests und einen dokumentierten Umstellungsplan mit Rollback-Verfahren.

Anfordern einer Odoo-Migrationsbewertung von ECOSIRE →