Migration von Odoo 17 zu Odoo 18: Welche Änderungen, welche Probleme auftreten und wie man sich vorbereitet

Odoo veröffentlicht jedes Jahr eine Hauptversion und jedes Upgrade bringt neue Funktionen, Leistungsverbesserungen und unweigerlich bahnbrechende Änderungen mit sich. Die Migration von Odoo 17 auf Odoo 18 erfordert eine sorgfältige Planung, insbesondere wenn Sie benutzerdefinierte Module ausführen oder auf Community-Add-ons angewiesen sind. Dieser Leitfaden behandelt alles, was Sie über die Migration von Odoo 17 auf 18 wissen müssen: wichtige Änderungen, potenzielle Probleme, Vorbereitungsschritte und Teststrategien.

Warum ein Upgrade auf Odoo 18?

Odoo 18 führt erhebliche Verbesserungen auf der gesamten Plattform ein:

• Neue OWL 3-Komponenten: Neu geschriebene Frontend-Komponenten mit verbesserter Leistung und Entwicklererfahrung
• KI-gestützte Funktionen: Prädiktive Lead-Bewertung, intelligente Vorschläge zur Bankabstimmung und KI-gestützte Inhaltserstellung
• Verbesserungen bei Tabellenkalkulationen: Native Tabellenkalkulationsintegration mit Echtzeit-Odoo-Daten, Pivot-Tabellen und kollaborativer Bearbeitung
• Fertigungs-Upgrades: Verbesserte Produktionsplanung, Unterauftragsportal und Tablet-Schnittstelle für die Werkstatt
• Leistung: 15–25 % schnellere Seitenladevorgänge durch optimierte Asset-Bündelung und verzögertes Laden
• Website-Builder: Neue Drag-and-Drop-Blöcke, Optionen zur Themenanpassung und verbesserte mobile Bearbeitung

Bei veralteten Versionen zu bleiben bedeutet, dass Sicherheitspatches fehlen, der Zugriff auf Community-Modul-Updates verloren geht und sich technische Schulden ansammeln, die zukünftige Migrationen erschweren.

Zeitleiste: Wie lange dauert eine Odoo-Migration?

| Komplexität | Benutzerdefinierte Module | Geschätzter Zeitplan | |---|---|---| | Standard (kein benutzerdefinierter Code) | 0 | 1-2 Wochen | | Niedrig (wenige benutzerdefinierte Felder/Ansichten) | 1-5 | 2-4 Wochen | | Mittel (benutzerdefinierte Workflows) | 5-15 | 4-8 Wochen | | Hoch (tiefe Anpassungen) | 15+ | 8-16 Wochen |

Diese Zeitpläne umfassen Analyse, Migration, Tests und Go-Live. Die größte Variable ist die Komplexität benutzerdefinierter Module.

Wichtige Änderungen in Odoo 18

OWL-Framework-Änderungen

Odoo 18 setzt die Migration auf OWL 3 fort. Wenn Ihre benutzerdefinierten Module Frontend-JavaScript-Komponenten enthalten, müssen Sie mit diesen Änderungen rechnen:

Wichtige OWL-Änderungen:

• Komponentenlebenszyklus: willStart und willUpdateProps werden durch die Hooks setup() und onWillStart ersetzt
• Vorlagenkompilierung: QWeb-Vorlagen werden jetzt zur Erstellungszeit statt zur Laufzeit in optimiertes JavaScript kompiliert
• Service-Injektion: Greifen Sie ausschließlich über das this.env.services-Muster auf Dienste zu; Direktimporte sind veraltet
• Asset-Bündelung: Die web.assets_backend-Bundle-Struktur hat sich geändert; Aktualisieren Sie Ihre __manifest__.py-Vermögensdeklarationen

Beispielmigration:

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

Python-Backend-Änderungen

Modell- und Feldänderungen:

• fields.Monetary erfordert jetzt die explizite Deklaration von currency_field (standardmäßig nicht mehr currency_id) – Der @api.multi-Dekorator wurde vollständig entfernt (seit Version 13 veraltet, wurde aber von einigen Community-Modulen weiterhin verwendet) – Verhaltensänderung von sudo(): sudo() ohne Argumente verwendet jetzt explizit den SUPERUSER anstelle des OdooBOT-Benutzers – search_count() akzeptiert jetzt einen optionalen limit-Parameter zur Leistungsoptimierung

Veraltete Methoden zum Aktualisieren:

| Veraltet (v17) | Ersatz (v18) | |---|---| | fields.Many2one.search() | fields.Many2one mit domain-Attribut | | _register_hook() | _post_init_hook im Manifest | | Direktes SQL in Modellen | self.env.cr.execute() mit der richtigen Parametrisierung | | website.published-Feld | website.is_published (umbenannt) |

Ansichts- und Vorlagenänderungen

• Formularansicht: sheet Wrapper ist jetzt für alle Formularansichten obligatorisch (bisher optional)
• Listenansicht: Das tree-Tag wird offiziell in list umbenannt (abwärtskompatibler Alias funktioniert weiterhin, löst aber Warnungen vor veralteter Funktion aus)
• Kanban-Ansicht: QWeb t-esc ist jetzt die Standardeinstellung; t-raw erfordert aus Sicherheitsgründen eine explizite Einwilligung
• QWeb melden: PDF-Rendering-Engine aktualisiert; Testen Sie alle gedruckten Berichte auf Layoutänderungen

Änderungen am Datenbankschema

Odoo 18 enthält strukturelle Änderungen an Kerntabellen:

• sale.order.line erhält neue Felder für die Abonnementverwaltung – account.move.line enthält neue abgleichsbezogene Spalten
• stock.quant-Tabelle umstrukturiert, um die Leistung bei großen Beständen zu verbessern
• mail.message- und mail.activity-Tabellen mit neuen Indizes optimiert

Diese Schemaänderungen werden von Odoos integrierten Migrationsskripten für Standardmodule verarbeitet, aber benutzerdefinierte Module, die auf diese Tabellen verweisen, erfordern manuelle Aktualisierungen.

Checkliste zur Vorbereitung vor der Migration

1. Überprüfen Sie Ihre aktuelle Installation

Dokumentieren Sie alles, bevor Sie beginnen:

• [ ] Alle installierten Module auflisten (offiziell, Community und benutzerdefiniert)
• [ ] Aktuelle Odoo-Version und Patch-Level aufzeichnen
• [ ] Dokumentieren Sie alle benutzerdefinierten Entwicklungen (Felder, Modelle, Ansichten, Berichte, geplante Aktionen)
• [ ] Alle externen Integrationen auflisten (Zahlungsgateways, Versanddienstleister, APIs von Drittanbietern)
• [ ] Aktuelle Zugriffsrechte exportieren und die Konfiguration der Aufzeichnungsregeln exportieren
• [ ] Sichern Sie die Produktionsdatenbank und den Dateispeicher vollständig

2. Überprüfen Sie die Kompatibilität des Community-Moduls

Für jedes Community-Modul (OCA oder Drittanbieter):

• Überprüfen Sie, ob eine mit Odoo 18 kompatible Version auf GitHub oder im Odoo Apps Store vorhanden ist
• Wenn keine kompatible Version vorhanden ist, entscheiden Sie, ob Sie das Modul selbst portieren, eine Alternative finden oder die Funktionalität entfernen möchten
• Wenden Sie sich an die Modulbetreuer, um die voraussichtliche Ankunftszeit für v18-Ports zu erfahren

3. Benutzerdefinierte Modulports vorbereiten

Bewerten Sie für jedes benutzerdefinierte Modul den Migrationsaufwand:

Geringer Aufwand (1-3 Tage pro Modul):

• Module mit nur neuen Feldern und einfachen Ansichten
• Keine JavaScript/OWL-Komponenten
• Keine Überschreibungen geänderter Kernmethoden

Mittlerer Aufwand (3-10 Tage pro Modul):

• Module mit OWL-Komponenten, die Updates erfordern – Überschreibungen veralteter oder geänderter Kernmethoden
• Benutzerdefinierte Berichte, die QWeb-Updates erfordern

Hoher Aufwand (10+ Tage pro Modul):

• Tiefe Integration mit geänderten Kernmodulen (Buchhaltung, Inventar, Website)
• Komplexe OWL-Frontend-Anwendungen – Module, die häufig veraltete oder entfernte APIs verwenden

Die Zusammenarbeit mit erfahrenen Odoo-Migrationsspezialisten reduziert den Zeitaufwand und das Risiko der Portierung benutzerdefinierter Module erheblich.

Schritte zur Migrationsausführung

Schritt 1: Einrichten der Migrationsumgebung

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

Erstellen Sie eine isolierte Umgebung mit:

• Eine neue Odoo 18-Serverinstallation
• Eine Kopie Ihrer Produktionsdatenbank
• Alle benutzerdefinierten Module auf v18 portiert

Schritt 2: Führen Sie das Datenbank-Upgrade aus

Für Odoo Enterprise: Nutzen Sie den offiziellen Upgrade-Service von Odoo unter upgrade.odoo.com. Laden Sie Ihre Datenbank hoch und Odoo SA führt die Migrationsskripte für alle Standardmodule aus.

Für die Odoo-Community: Verwenden Sie das openupgrade-Projekt von OCA. OpenUpgrade bietet von der Community verwaltete Migrationsskripte für Standardmodule:

1. Installieren Sie OpenUpgrade für die Zielversion
2. Führen Sie die Migration für Ihre Testdatenbank aus
3. Überprüfen Sie das Migrationsprotokoll auf Fehler und Warnungen
4. Beheben Sie alle Probleme und führen Sie den Vorgang erneut aus, bis er sauber ist

Schritt 3: Benutzerdefinierte Module portieren

Für jedes benutzerdefinierte Modul:

1. Aktualisieren Sie die __manifest__.py-Version auf 18.0.x.x.x
2. Korrigieren Sie den Python-Code (veraltete APIs, geänderte Methodensignaturen)
3. Aktualisieren Sie JavaScript/OWL-Komponenten auf v3-Muster
4. XML-Ansichten korrigieren (Baum zur Liste, Blattumbruch, Vorlagenänderungen)
5. Führen Sie die Testsuite des Moduls aus und beheben Sie Fehler
6. Testen Sie manuell in der Staging-Umgebung

Schritt 4: Datenüberprüfung

Überprüfen Sie nach der Migration die Datenintegrität:

• Buchhaltung: Vergleichen Sie die Saldosummen der Testversion zwischen Version 17 und Version 18. Sie müssen genau übereinstimmen.
• Bestand: Überprüfen Sie die Lagerbestände für eine Stichprobe hochwertiger Produkte.
• Verkauf/Einkauf: Offene Bestellungen bestätigen und deren Status korrekt übertragen.
• Kontakte: Überprüfen Sie, ob die Kunden- und Lieferantendaten einschließlich Adressen und Bankdaten intakt sind.
• Anhänge: Stellen Sie sicher, dass auf Dokumente, Bilder und Dateianhänge zugegriffen werden kann.

Teststrategie

Level 1: Automatisierte Tests

Führen Sie die vollständige Testsuite für jedes installierte Modul aus. Beheben Sie alle Fehler, bevor Sie fortfahren.

Level 2: Funktionstests

Testen Sie die Kerngeschäftsabläufe durchgängig:

• Angebot erstellen, bestätigen, Ware liefern, Rechnung erstellen, Zahlung registrieren
• Bearbeiten Sie eine Bestellung anhand der Quittung und der Lieferantenrechnung
• Führen Sie einen Fertigungsauftrag von der Stückliste bis zum fertigen Produkt aus
• Führen Sie einen vollständigen Bankabstimmungszyklus durch
• Erstellen und überprüfen Sie wichtige Finanzberichte

Level 3: Benutzerakzeptanztest (UAT)

Lassen Sie echte Benutzer aus jeder Abteilung 5–10 Werktage lang ihre täglichen Aufgaben in der Staging-Umgebung ausführen. Verfolgen Sie Probleme in einer gemeinsamen Tabelle oder einem Projektmanagement-Tool.

Level 4: Leistungstests

Vergleichen Sie die Seitenladezeiten, die Geschwindigkeit der Berichtserstellung und die Suchleistung zwischen Version 17 und Version 18 mit Datenmengen auf Produktionsebene.

Go-Live-Strategie

Empfohlener Ansatz: Wochenendmigration

1. Freitagabend: Erstellen Sie ein letztes Produktions-Backup. Alle Transaktionen einfrieren.
2. Samstag: Führen Sie das Upgrade für die Produktionsdatenbank aus. Portieren Sie alle Last-Minute-Daten.
3. Sonntag: Vollständige Datenüberprüfung und Rauchtest. Bereitstellung auf Produktionsservern.
4. Montagmorgen: Live gehen. Beobachten Sie die ersten 48 Stunden genau.

Halten Sie einen Rollback-Plan bereit: Halten Sie die Datenbanksicherung und Serverkonfiguration der Version 17 bereit, damit Sie bei Auftreten kritischer Probleme innerhalb weniger Stunden eine Wiederherstellung durchführen können.

Häufig gestellte Fragen

F: Kann ich Versionen überspringen und direkt von Odoo 16 auf Odoo 18 migrieren? Ja, aber es ist komplexer. Jede Version hat ihre eigenen Migrationsskripte und das Überspringen von Versionen verstärkt die Änderungen. Der Upgrade-Service von Odoo verarbeitet Sprünge über mehrere Versionen hinweg, aber die Portierung benutzerdefinierter Module erfordert die Bewältigung wichtiger Änderungen aus jeder übersprungenen Version. Planen Sie 50–100 % mehr Zeit für Migrationen mehrerer Versionen ein.

F: Funktionieren meine benutzerdefinierten Berichte während der Migration nicht mehr? Potenziell. QWeb-Berichtsvorlagen ändern sich aufgrund aktualisierter Datenstrukturen und Verbesserungen der Rendering-Engine häufig zwischen den Versionen. Testen Sie nach der Migration jeden gedruckten Bericht (Rechnungen, Lieferscheine, Bestellungen) und passen Sie die Vorlagen nach Bedarf an.

F: Soll ich migrieren oder neu anfangen? Migrieren Sie, wenn Sie über langjährige historische Daten, komplexe Konfigurationen und geschulte Benutzer verfügen. Beginnen Sie neu, wenn Ihre aktuelle Installation stark angepasst ist und nicht mehr repariert werden kann, erhebliche Probleme mit der Datenqualität aufweist oder wenn sich Ihre Geschäftsprozesse so stark geändert haben, dass eine Neukonfiguration schneller wäre. Die meisten Unternehmen entscheiden sich für eine Migration, um ihre Betriebsgeschichte zu bewahren. Wenden Sie sich an einen Odoo-Beratungspartner, um zu beurteilen, welcher Ansatz zu Ihrer Situation passt.

Professionelle Migrationsunterstützung

Die Migration zwischen Odoo-Versionen ist ein technisches Projekt, das von erfahrenen Händen profitiert. Die Odoo-Migrationsdienste von ECOSIRE decken den gesamten Prozess ab: Audit vor der Migration, Portierung benutzerdefinierter Module, Datenmigration, Tests und Go-Live-Support.

Kontaktieren Sie unser Team für eine Migrationsbewertung und einen Zeitplanvoranschlag basierend auf Ihrer spezifischen Odoo-Installation. Wir analysieren Ihre Module, Anpassungen und Datenkomplexität, um einen genauen Umfang und ein genaues Budget bereitzustellen.