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

Das Upgrade auf Odoo 19 Enterprise bietet erhebliche Verbesserungen bei Leistung, Benutzererfahrung und KI-gestützten Funktionen. Aber 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

• Für die Odoo 19-Migration muss jeweils eine Hauptversion aktualisiert werden (17→18→19 oder 17→19 direkt mit OpenUpgrade).
• 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
• Planen Sie je nach Komplexität einen Gesamtzeitrahmen für die Migration von 3 bis 8 Wochen ein
• 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: (minimum 15 required for Odoo 19)

Schritt 2: Benutzerdefinierte Module klassifizieren

Bestimmen Sie für jedes benutzerdefinierte Modul Folgendes:

Schritt 3: Identifizieren Sie die wichtigsten Änderungen in Odoo 19

Wichtige Änderungen zwischen Odoo 17/18 und Odoo 19, die sich auf benutzerdefinierte Module auswirken:

• OWL 3.x: Frontend-Komponenten müssen von OWL 2.x-Mustern migriert werden
• Python 3.12: Einige Python 3.10/3.11-Syntaxen müssen möglicherweise angepasst werden
• PostgreSQL 15+: Erforderliche Mindestversion; Einige Abfragemuster ändern sich
• API-Abwertungen: Mehrere _legacy-Methoden entfernt; nach _multi → _create_multi suchen
• Berichts-Engine: Einige QWeb-Berichtsvariablen umbenannt
• Umgestaltung der Kontoverschiebung: Änderungen an der Zeilenstruktur account.move wirken sich auf Buchhaltungsanpassungen aus

---

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:

• Verarbeitet keine benutzerdefinierten Module
• 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 und Enterprise bereitstellt.

# Clone OpenUpgrade for Odoo 19
git clone https://github.com/OCA/OpenUpgrade.git -b 19.0

# Install upgrade dependencies
pip install openupgradelib

# Run migration
python odoo-bin --config=upgrade.conf \
    --update=all \
    --load=base,web,openupgrade_framework

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 (Woche 1–2)

Datenbankvorbereitung:

-- Run on source database before export
-- Identify orphaned records
SELECT id, name FROM res_partner WHERE active = FALSE AND id NOT IN (
    SELECT partner_id FROM sale_order
    UNION SELECT partner_id FROM account_move
    UNION SELECT partner_id FROM stock_picking
);

-- Archive old draft records (reduces migration time)
UPDATE sale_order SET active = FALSE
WHERE state = 'draft' AND date_order < NOW() - INTERVAL '2 years';

-- Verify accounting reconciliation
SELECT COUNT(*) FROM account_move_line
WHERE reconciled = FALSE AND debit != credit;

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 -p 5433 -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

Überprüfung des benutzerdefinierten Modulcodes:

Führen Sie für jedes benutzerdefinierte Modul eine Kompatibilitätsprüfung durch:

# Check for deprecated patterns
grep -r "execute_kw" custom_modules/   # Still valid in v19
grep -r "browse\(\[" custom_modules/  # Should be browse(ids) not browse([ids])
grep -r "_multi" custom_modules/      # Check for renamed methods
grep -r "account\.move\.line\." custom_modules/  # Account refactoring affected
grep -r "@api\.one" custom_modules/   # Removed in v14, ensure not present
grep -r "@api\.multi" custom_modules/ # Removed in v14, ensure not present

---

Einrichten der Migrationsumgebung (Woche 2–3)

Infrastrukturaufbau:

# Install Odoo 19 Enterprise on migration server
# Requirements: Ubuntu 22.04/24.04, PostgreSQL 15+, Python 3.12

# 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

Quelldatenbank auf Migrationsserver wiederherstellen:

# Create target database
createdb -h localhost -U postgres odoo_migration_test

# Restore backup
pg_restore -h localhost -U postgres -d odoo_migration_test \
    odoo_prod_backup_YYYYMMDD.dump

# Run Odoo upgrade
python3 /opt/odoo19/odoo-bin \
    -d odoo_migration_test \
    -u all \
    --without-demo=all \
    --stop-after-init

---

Migration benutzerdefinierter Module (Wochen 3–5)

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. Python-Kompatibilität aktualisieren:

# Old pattern (deprecated):
@api.multi
def my_method(self):
    for record in self:
        pass

# New pattern:
def my_method(self):
    for record in self:
        pass

3. Syntax der Ansicht aktualisieren:

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

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

4. OWL-Komponenten aktualisieren (falls vorhanden Frontend-Widgets):

OWL 3.x führt Reaktivitätsänderungen ein. Wenn Ihre Module benutzerdefinierte JavaScript-Widgets verwenden:

// Old OWL 2.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    willStart() { ... }
}

// New OWL 3.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    setup() {
        onWillStart(async () => { ... });
    }
}

5. 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 (Wochen 5–6)

Finanzdatenvalidierung:

-- Verify balance sheet balances (assets = liabilities + equity)
SELECT
    SUM(CASE WHEN account_type LIKE 'asset%' THEN balance ELSE 0 END) as assets,
    SUM(CASE WHEN account_type LIKE 'liability%' THEN balance ELSE 0 END) as liabilities,
    SUM(CASE WHEN account_type = 'equity' THEN balance ELSE 0 END) as equity
FROM account_account aa
JOIN account_move_line aml ON aml.account_id = aa.id
JOIN account_move am ON aml.move_id = am.id
WHERE am.state = 'posted';

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 (Woche 7–8)

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 (< 5 Minuten)
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. Bei OpenUpgrade müssen Sie je nach verfügbaren Migrationsskripten möglicherweise 17→18→19 wählen. Ü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. Eine Standard-Odoo-Instanz mit minimalen Anpassungen: 2–3 Wochen. Mäßig angepasst (5–10 individuelle Module): 4–6 Wochen. Stark angepasst mit komplexen Integrationen: 8–16 Wochen. 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.

Wird meine Odoo Enterprise-Lizenz auf Version 19 übertragen?

Ja. Odoo Enterprise-Abonnements sind versionunabhängig. Ihr Jahresabonnement deckt die von Ihnen verwendete Version ab. Wenden Sie sich an Ihren Odoo-Partner, um den Odoo 19 Enterprise-Code zu erhalten, wenn Sie mit Ihren Unternehmensanmeldeinformationen nicht über das Git-Repository von Odoo darauf zugreifen.

---

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.

ECOSIRE hat Dutzende Odoo-Instanzen von den Versionen 13, 14, 15, 16, 17 und 18 erfolgreich auf Odoo 19 Enterprise migriert. Unsere Migrationsmethodik umfasst eine vollständige Bewertung, benutzerdefinierte Modulaktualisierungen, parallele Tests und einen dokumentierten Umstellungsplan mit Rollback-Verfahren.

Anfordern einer Odoo-Migrationsbewertung von ECOSIRE →

Wir bewerten Ihre aktuelle Umgebung, identifizieren alle Migrationsrisiken und erstellen einen Migrationsplan mit festem Umfang, damit Sie genau wissen, was Sie erwartet, bevor das erste Migrationsskript ausgeführt wird.