DIE ODOO-MIGRATION - Teil 1
Was eine Migration bedeutet

Die Odoo Migration

In diesem Artikel gehen wir der Frage aus dem vorigen Blog nach, was eine Migration bedeutet, wie oft man migrieren sollte und was man als Kostenfaktor einrechnen muss.

Die Ausgangssituation

Dem vorherigen Artikel kann man die Aussage entnehmen, dass es nicht nur aus technischer Sicht empfehlenswerter ist, einem IT System Funktionen hinzuzufügen als sie im Standard zu haben. Der Haupteinwand ist natürlich, dass so die Verantwortung und die Kostenübernahme nicht nur in der Umsetzung, sondern auch bei jeder Migration beim Kunden und nicht beim Hersteller liegen.

Daher sollte man die wesentlichen Fragen natürlich klären.

Vorab muss man sagen, dass wir unseren Kunden empfehlen, einen Wartungs-vertrag mit Odoo abzuschließen, da dieser nicht nur den Zugriff auf das Enterprise Paket beinhaltet, sondern auch die Migration der Produktionsdatenbank. Der hier beschriebene Prozess und die Informationen beziehen sich rein auf die Enterprise Version.

Welche Schritte gehören zu einer Migration, sollte man sich für eine neue Odoo Version entscheiden:


1. Anmeldung zur Migration

Der Kunde teilt dem technischen Team von Odoo den Wunsch zur Migration unter Verwendung der Vertragsnummer mit und eröffnet damit ein Ticket beim Support-Team. Die Ticketnummer wird dann mit openfellas geteilt.

2. Bereitstellung eines Datenbankauszugs

Nachdem das Ticket von Odoo auf „Test“ gesetzt wird, wird vom Produktivserver ein Backup gezogen und über das Ticket an Odoo übergeben.

3. Migration der Individualisierungen

Zeitgleich legt openfellas einen neuen Branch in der Entwicklungsumgebung an, der automatisch eine dem Branch zugeordnete Docker-Instanz innerhalb der Entwicklungsumgebung generiert. Darin können nun sämtliche dafür notwendigen Tests durchgeführt werden.

Als erster Schritt beginnt die Migration der vorab entwickelten Individualisierungen. Dabei werden sämtliche Vererbungen korrigiert (Objektstruktur, Masken, Berechtigungssystem). Dies impliziert natürlich eine 1:1 Migration, also keine Prozessanpassungen. Dabei sind die kritischsten Punkte mögliche Änderungen im Odoo Datenmodell. Dies kann durchaus vorkommen und fällt manchmal nur geringfügig, manchmal jedoch auch recht umfangreich aus. Abhängig von den Konsequenzen aus dieser Änderung kann das bedeuten, dass openfellas bereits eine technische Lösung hierzu hat und diese nur noch mit dem Kunden abgestimmt werden muss. In einigen Fällen kann es jedoch auch notwendig werden, dass gemeinsam mit dem Kunden eine neue Zielstruktur definiert werden muss.

Eine interessante Frage ist, wie sich neue Odoo Funktionen in die alten Prozesse integrieren lassen, wenn etwa bei Version 11 nicht nur das Hinterlegen von Notizen oder das direkte Schreiben von Nachrichten möglich ist, sondern auch Aktivitäten angelegt werden können. Darüber können z.B. Freigabeprozesse recht einfach umgesetzt werden, die vorher über Wizards oder Methoden umgesetzt werden mussten.

4. Testen der Prozesse

In einer separaten Testphase müssen nun die migrierten Individualisierungen geprüft werden. Dazu können beispielhafte Testdaten dienen.

5. Rückführung und Test Migrationsdatenbank

Da es in der Zwischenzeit eine Rückmeldung von Odoo zur Datenbank gab, sollten nach der vorausgegangenen Testphase nun die Tests mit Produktivdaten durchgeführt werden. Die aufkommenden Fehler können im Zusammenhang mit Fehlern in der Datenbankmigration stehen oder mit den migrierten Individualisierungen.

Im Falle der Module können diese direkt behoben werden, Fehler innerhalb der Datenbank müssen an Odoo zurückberichtet werden.

Sobald diese Tests erfolgreich abgeschlossen werden können, wird das Odoo Ticket auf den Status „Produktiv“ gestellt. Ab diesem Zeitpunkt kann ein neues Backup jederzeit hochgeladen und durch das Migrationsskript, das zum Ticket hinterlegt wurde, jederzeit in eine neue Produktivversion umgewandelt werden.

6. Aufsatz neues Produktivsystem

Nun können die Vorbereitung eines neuen Produktiv- und Testsystems anlaufen. Das Testsystem sollte dabei für Schulungen und Tests nach dem Live-Gang genutzt werden.

7. Schulung

Dieser Schritt ist nicht unbedingt bei jeder Migration notwendig. Sollte sich die Oberfläche von Odoo geändert haben oder sollten Prozesse umgestellt worden sein, kann eine Schulung notwendig werden, sie ist aber nicht immer zwingend erforderlich. Teilweise kann es ausreichen, intern Unterlagen oder Videos zu veröffentlichen.

Die Notwendigkeit dazu kann bereits zwischen den Schritten 3 und 4 bewertet werden.

8. Liveschaltung

Zeitgleich kann die URL vom alten auf das neue System umgeschaltet werden.

Wie oft sollte eine Migration eingeplant werden?

Es gibt wenige Kunden, die tatsächlich jährlich migrieren, um die Umstellungen so gering wie möglich zu halten. Der Großteil überspringt jedoch die 2 Versionen, die laut Enterprise Vertrag von Odoo zugelassen sind. D.h. in aller Regel steht der Migrationsprozess alle 2 bis 3 Jahre an.

Natürlich kann es Ausnahmen geben, die eine Migration schon vorher rechtfertigen. So kann es z.B. sein, dass eine Anforderung zu einer Individualisierung geplant ist, die mit einer neuen Odoo Version plötzlich umgesetzt wurde und im Standard enthalten ist. Dann gibt es zwar immer noch den Weg, dies auf die aktuelle Version downzugraden, doch am Ende des Tages ist es eine rein kaufmännische Entscheidung, welcher Weg der günstigere ist.

Was kostet eine Migration?

Eben dies ist am schwersten zu beziffern, denn der eigentliche Aufwand ist auch hier die Menge der Dienstleistungen zur Umsetzung der einzelnen Schritte. Wenn man die letzten Implementierungen betrachtet und daraus einen statistischen Erfahrungswert ziehen möchte, kann man sagen, dass sich der Aufwand im Vergleich zur Implementierung ungefähr zwischen 15% bis (schlimmstenfalls) 25% bewegt (vorausgesetzt, es handelt sich um eine 1:1 Migration ohne Prozessänderungen oder -anpassungen).

Falls kein Enterprise-Vertrag vorliegt und die Datenbank mit-migriert werden muss, ist der Aufwand deutlich teurer. Auch wenn es entsprechende Projekte gibt, die eine gute Basis dafür bilden, ist der wesentliche Punkt, dass bei keinem Budget der Welt der Partner für die Datenmigration eine Gewährleistung übernehmen kann. Denn das Problem ist, dass die von Odoo durchgeführten Änderungen teilweise sehr umfangreich sind und es schwierig ist, hier genügend Überblick zu haben, um bewerten zu können, welche der Änderungen relevant sind. Besonders vor dem Hintergrund, dass sich Änderungen in der Datenbankstruktur analysieren lassen können. Sollten sich jedoch Tabellenwerte zur Steuerung von Prozessen ändern, lassen sich diese nur durch Tests und das Studium des Codes exakt recherchieren. Und eben hier endet die Gewährleistung, die ein Dritter geben kann, ob all diese Werte vollständig gefunden und migriert wurden.

Was passiert, wenn man nicht regelmäßig migriert?

Natürlich unterliegt kein Kunde einem „Migrationszwang“. Es gibt durchaus Gründe, eine Odoo Version beizubehalten. Da Odoo 8 z.B. die letzte Version war, in der es keinen Split in einen Community und Enterprise Zweig gab und in der das Preismodell rein pauschal auf die Erhebung der Anzahl interner Benutzer basierte, gibt es immer noch Kunden, die darauf geblieben sind.

Was man dazu wissen muss:

1) Das Wissen über die Umsetzungen im Standard innerhalb der einzelnen Module schwindet, bei Entwicklern und Beratern. D.h. eine „richtige“ Beratung wird immer schwieriger.

2) Odoo 8 hatte wegen Python 2.x eine andere API, Anpassungen mussten daher anders entwickelt werden. Auch hier verliert sich das Wissen zunehmend.

3) Auf Grund eines mittlerweile veralteten und schwindenden Software Stacks wird es immer schwieriger, Tests und Entwicklungen aufzubauen, d.h. bei Bedarf ist der Aufwand zunehmend steigend.

4) Das wohl größte Risiko ergibt sich aus den immer häufiger ausbleibenden Updates der Basissysteme, da diese aus dem Support der Hersteller herausfallen.

  • Python 2.x wurde mittlerweile mehrfach abgekündigt, nun final bis 2020.

  • PostgreSQL 9.4 läuft Ende 2019 aus

  • Ubuntu 14.04 ist bereits im April dieses Jahres ausgelaufen

  • NGINX ist nicht ganz klar definiert. Hier heißt es nur, dass gerade Nummern auf Bedarf gepflegt werden und ungerade (also Entwicklerversionen) 4-5 Wochen dauern.

Klar kann man entscheiden, das System im internen Netzwerk wegzuschließen, doch die IT hält seit Jahren urplötzlich unangenehme Überraschungen parat, wie es Heartbleed (SSL Lücke aus 2014) oder die dieses Jahr entdeckten Intel-Lücken „Spectre“ und „Meltdown“ bewiesen haben. Diese Szenarien werden immer wieder aufkommen und sind unvorhersehbar in Ausmaß und Umfang. Und da statistisch gesehen die meisten Gefährdungen nicht von außen, sondern von innen kommen (der USB Stick, die Putzfrau, der ungerecht behandelte Mitarbeiter), ist das Wegschließen nur eine sehr eingeschränkte Sicherheitsmaßnahme.

Denn machen wir uns nichts vor, nach so langer Zeit ist eine Migration der Daten nahezu unmöglich. Damit läuft es auf einen Neuaufsatz hinaus, der nicht so schnell geschehen kann, wenn die Zeit drängt.

28 April, 2020
artikel teilen
kategorien
Bearbeiten
Archiv
Anmelden to leave a comment
DIE ODOO-MIGRATION - Teil 2
Wichtige Parameter für eine Systementscheidung
Top