Die Schwierigkeit der Mirgration von Projekten

Häufig erhalte ich Anfragen von Bestandskunden oder von fremden möglichen Auftraggebern zur Migration von Bestandprojekten auf eine neuere Joomla-Haupt-Version, verbunden mit der Bitte einer Aufwandseinschätzung und der Abgabe eines Preisangebotes. Diese Frage ist jedoch nicht einfach zu beantworten, denn viele Faktoren spielen eine Rolle und hinzu kommen Dinge die einfach von vornherein schwer einzuschätzen sind, sondern erst ihre Probleme beim ersten Migrationsversuch offenbaren. An dieser Stelle seinen dafür ein paar lesenswerte Gründe genannt, um Verständnis für die Problematik zu vermitteln. 

Dieser Beitrag bezieht sich ganz speziell auf die Arbeit mit dem OpenSource CMS Joomla!, betrifft aber auch andere CMS wie WordPress, Drupal etc.

Update vs. Migration

Zunächst sei auf den Sachverhalt hingewiesen, dass wir bei größeren Versionssprüngen üblicherweise von einer Migration ausgehen und nicht von einem Update.

Ein Update ist meist eine einfache Sache, die mit einem Knopfdruck erledigt ist. Ein Update ist nie so gravierend, dass sich Datenstrukturen maßgeblich ändern oder ganz Basistechnologien in den Corescripten verändern. Das Update ist i.d.R. mit einem "Drüberbügeln" und einer Kontrolle der Auswirkungen abgeschlossen. Selten gibt es dann noch Anpassungsaufwand.



Anders bei der Migration. An den zugrundliegenden Frameworks wurde meist so umfangreich gearbeitet, dass dies auch Auswirkung auf alle Erweiterungen hat, die das Framework/API nutzen. Meist werden dabei große Teile des Frameworks ausgetauscht, balastfrei ein ganz neuer Ansatz gefahren, der mit alten Scripten nicht mehr umsetzbar ist. Mit Joomla 3 waren das neben "unwichtigen" Templateumstellungen vor allem solche Dinge im Hintergrund wie die Rechtestrukturen, die eigene Mehrsprachigkeit, die Responsivität, das Versionsmanagement etc. Diese Änderungen waren so maßgeblich, dass für 2.5 entwickelte Erweiterungen dann nicht ohne Anpassungsaufwand unter Joomla!3 liefen.

Die Zukunft der Migration/Updates

Der Trent in der Softwareentwicklung geht zum Glück immer mehr dahin, dass es so genannte große Versionsspünge immer weniger geben wird. Das sieht man z.B. auch beim Windows 10, welches ja angeblich das letzte Windows sein soll und sich zukünfigt still und heimlich fortlaufend selbst aktualisiert in Form kleiner Updateschritte. Die Zeit des vollst. Neuaufsetzens von System wie unter früheren Windows-Versionen wird dann vorbei sein. Ähnliches kennen wir von Smartphones und Apps, wo dieser Ansatz mittlerweile längst üblich ist.

Auch Joomla! wird diesen Weg mehr und mehr einschlagen. Das ist zu erkennen an der neuen Versions-Nummern-Politik. Die Sprünge von 1.0.x auf 2.0.x und 3.0.x und die stables 1.5.x zu 2.5.x 3.5.x wird es nicht mehr geben, sondern nur noch kleine Sprünge von 3.4. auf 3.5 etc. Deshalb bin ich in Hoffnung, dass Migrationen nicht mehr so häufig notwendig sein werden. Ganz ausbleiben werden sie vermutlich trotzdem nicht, denn es wird immer Funktionen geben die irgenwann mal aus einem Framework/einer API entsorgt werden und auf die die Erweiterungen dann nach einer Übergangszeit nicht mehr zugreifen können, also angepasst werden müssen.

Die Entscheidung Migration oder Neu-Aufsetzen eines Projektes

Die Notwendigkeit einer Migration ist oben begründet. Motivationen für den aufwändigen Schritt einer Migration sind neben Sicherheitsaspekten, die beim "Stillstand" von Projekten mit veralteten nicht mehr supporteten Versionen zu beachten sind, gerade jetzt der wichtige Umbau des Templates zur Erfüllung der Ansprüche an ein responsives Layout/Design. Kein Websitebetreiber möchte potentielle Seitenbesucher, die per Smartphone surfen, nicht erreichen können.

Dieser Schritt der Migration ist nicht einfach und auch nicht mit wenig Aufwand und Kosten verbunden. Deshalb sollte man sich über die Vorgehensweise gründlich Gedanken machen. Was vielen Entscheidern dabei oft gar nicht in den Sinn kommt ist, statt der Migration eines bestehenden Projektes einfach eine neues aufzubauen und statt dessen die Bestandsdaten aus dem alten Projekt in das neue zu übertragen. Das ist auch nur eine Option und nicht für jedes Projekt gleichermaßen anwendbar.

Mögliche Migrationsvarianten

Die "klassische Migration" geht technisch davon aus, dass man in ein bestehendes Projekt ein neues Joomla installiert, also z.B. in ein 2.5er Joomla die Version 3.x. Vorher sind i.d.R. die Erweiterungen zu aktualisieren, von denen man ausgeht, dass diese 2.5 und 3.x kompatibel sind, was oft so gegeben ist. Wenn alles unproblematisch verläuft, was es durchaus gibt, dann hat man mit wenigen Handgriffen schon gewonnen. Erfahrungsgemäß funktioniert das so nur mit Projekten die fast ausschließlich mit Joomla-Kern-Inhalten arbeiten, also wenig Erweiterungen nutzen und auch das Template diese Vorgehensweise unterstützt.

Der Gegenansatz dazu ist das "jungfräuliche Parallelprojekt". D.h. es wird völlig balastfrei ein Projekt aufgebaut, ein neues, bevorzugt nun responsives Template installiert und indiviualisiert, die neuen Erweiterungsversionen oder Alternativen dazu installiert und dann die Daten, sprich Inhalte manuell eingepflegt/übertragen.
Im Übrigen ist es mitunter auch ein Gewinn und Pro-Argument für ein Neuaufbau, weil man so gleich die Chance für die evtl. eh längst fällige Überarbeitung und Neustrukturierung von Inhalten nutzen kann ;-). Das Projekt wäre dann "altlastenfrei".

Dazwischen gibt es noch als Alternative die "automatisiert Datenübertragung", die auch von manchen Migrations-Tools so praktiziert werden. In ein jungfräuliches Parallelprojekt werden durch die Migrations-Tools die Daten aus dem alten Projekt in das neue z.T. zugleich mit den notwendigen Datenkonvertierungen importiert. Natürlich kann kein Tool alle Datenstrukturen der mgl. Erweiterungen kennen, weshalb diese Tools sich also auf die Joomla-Kern-Inhalte und wichtige weit verbeitetet Erweiterungen konzentrieren. Dieser Weg hat also auch seine Grenzen, ist aber nach meiner Auffassung meistens der erfolgreichste und günstigste.

Automatische Migration oder Neuaufbau mit manueller Datenübertragung!

Nicht selten ist erfahrungsgemäß eine klassische Migrationen teurer als eine Neuerstellung eines Parallelprojektes. Gründe dafür sind nachvollziehbar:

  • Alle früheren Komponenten müssen auch nach dem Update von Joomla laufen, was oft nicht der Fall ist. Dann müssen deren Daten von der alten Komponente in die neue übertragen werden und die neue Komponente entspr. gestylt werden, so dass diese sich in das Joomla-Template einfügen.
  • Zwischen alten und neuem Template gibt es oft gravierende Unterschiede, nicht nur weil es nun responsiv sein soll, sondern weil meist im Hintergrund neue Technologien arbeiten, die es damals (vor z.B. 5 Jahren) noch nicht gab (z.B. booster-tools, sass/scss, yaml, bootstrap, etc.) nun aber notw. Entwicklungsstandards sind.
  • Auch die Entscheidung "klassische Migration" oder "Neuprojekt" führt oft nur über den Weg des Versuchs! D.h. Es gibt keine Garantie, ob und wie erfolgreich eine autom. Migration ist. Das weiß man i.d.R. erst nach div. Versuchen, die auch Zeit fressen. Treten dabei Störungen auf, muss nach evtl. abstellbaren Ursachen geforscht werden, vielleicht klappt es ja doch noch ... Häufig erst danach kommt der Entschluss für einen Neuaufbau.
  • Leider sind oft auch viele Inhalte der Seite nicht sauber angelegt und widersprechen den Anforderungen an ein responsives Design. Diese müssen also sowie überarbeitet werden. Das ist z.B. oft der Fall, wenn durch die Autoren Beiträge speziell formatiert wurden, anstatt auf das zentrale Style-Set zu bauen. Diese "harten" Styles bleiben in den Beiträgen erhalten und stören in Ihrer alten Optik das Gesamerscheinungsbild der Seite. Das ist zu prüfen.

Welche Migrationsvariante passt zu meinem Projekt

Abschließend möchte ich Tipps geben, die bei der Entscheidung für eine Migrationsvariante behilflich sein könnten.

  1. Pauschal kann man sagen: Projekte mit großen Bestandsdatenmengen verlangen eine klassische Migration oder autom. Datenübertragung - ohne Zweifel. Der Vorteil einer klassischen/autom. Migration ergibt sich für den Seitenbetreiber oft erst dann, wenn es ihm erspart bleibt Unmengen Bestandsdaten (histor. Inhalte) übertragen zu müssen. Für Seiten mit nur wenigen Inhalten, ist eine Migration fast immer teurer als einfach ein neues Template-Package zu installieren und die wenigen Daten manuell oder wenn mgl. wenigstens teilautomatisiert zu übertragen - zumal man das dann alleine machen könnte.
  2. Beachten Sie, dass auch Migrationstools Lizenzgebühren kosten und im Budget einzuplanen sind. Da es mehrere Angebote gibt, muss man auch hier noch die für einen selbst geeigneteste finden. Nicht jede kann alles oder gleich gut. "Versuch mach kluch" ;-)
  3. Checken Sie Ihre Erweiterungen/Extensions und deren Bedeutung/Relevanz für Ihre Seite und die Menge der Inhalte die durch diese Erweiterung verwaltet werden. Während die Joomla-Migration absolult simpel ist, liegt in den Erweiterungen die ausufernde Arbeit:
    • Ist die Erweiterung überhaupt für das neue Joomla verfügbar? Leider muss das nicht so ein. Dann sind ggf. Ersatzkomponenten zu recherchieren. Hier wäre dann relevant, ob diese Ersatzerweiterung mit den Daten der alten Erweiterung umgehen kann oder diese fremd-importieren kann.
    • Art der Erweiterung (Modul, Plugin, Komponente) - Module sind i.d.R. ziemlich unproblematisch für Migrationen, Plugins nur wenn diese sich an die neuen API-Regeln halten.
    • Bedeutung für Back- und oder Frontend.
    • Sind diese Erweiterungen für die neue Joomla-Version geeignet? Ideal sind dabei Erweiterungen die mit einer Versionsnummer sowohl unter der alten als auch unter der neuen Joomla-Version laufen, denn dann ist eine eigentliche Migration für diese gar nicht notwendig.
    • Liefern die Erweiterungen (vor allem Component-Views) schon saubere responsive Inhalte aus?
    • Gibt es für diese Erweiterungen ggf. Plugins und/oder Migrationstools um notw. Funktion erweitern zu können.
  4. Welche Rolle spielt das Template selbst im Migrationsprozeß:
    • Zunächst sollte man prüfen, ob das derzeitige Template auch für die neue Joomla-Version nutzbar ist oder es ein einfaches Update dafür gibt, mit dem dann diese Kompatibilität erreicht werden kann. Auch hier gilt wie bei den Erweiterungen: Ideal sind Templates die in einem Installationspaket sowohl für die alte als auch neue Joomla-Version laufen.
    • Erfüllt das Zieltemplate Ihre erhöhten Anforderungen - z.B. ist es konsequent responsiv aufgebaut? Testen sie das vorher mit den Demo-Angeboten auf diversen Geräten bis in alle Inhaltstiefen. Verlassen Sie sich nicht auf pauschale Aussagen und Zusicherungen. Leider zeigt die Erfahrung, dass viele Templates nur soweit responsiv sind, wie zur Demonstation notw., aber Views die Sie dann nutzen sind es ggf. nicht.
    • Setzt das Template neue Technologien ein (Booster, Bootstrap, SCSS, SASS, YAML etc?
    • Haben Sie in Ihrer Seite Template-Overrides, die nachgeführt werden müssen.
    • Welches Layout/Design soll verwendet werden? Kaum ein Out-Off-The-Box-Template kann wirklich 1:1 verwendet werden! Es liefert diverse Styles, Templatebausteine, evtl. Features etc. mehr nicht. Teilweise sind diese anwendbar, manches fliegt raus, für andere Seitenbestandteile fehlen noch geeignete Präsentationsformen/Views etc. Es ist also wichtig zu definieren, welche Inhalte im neuen Projekt wie/wo dargestellt werden. (Ein Hinweis: Neue Templates tendieren immer mehr dahin konsequent auf Modulbasis zu layouten! Der frühere Ansatz eines primären Componenten-Inhaltes mit herumgebauten Modulchen wird sich immer mehr verlieren zugunsten des GRID-Layouts, zumal er schwer responsiv durchzusetzen ist.) Hieraus ergeben sich also zwangsläufig andere Gestaltungsgrundsätze, womit ein 1:1 - neu wie alt eine vertane Chance wäre.
  5. Müssen Sie ggfl. berücksichtigen, dass in Ihrem Projekt laufende Nutzerdaten anfallen (z.B. in einem Shop gibt es ständig Neukundenregistreirungen und Bestellungen). Muss Ihr Projekt nahezu unterbrechungsfrei umgestellt werden? 
    Bei der Migration müssen diese zeitnah und verlustfrei übernommen werden können. Der übliche Weg ist dann hier ein Parallelprojekt zu migrieren und abschließend noch mal die Daten oder betreffende Teildaten zeitnah rüberzuholen und die Projekte dann zu "switchen". Hierbei ist Fingerspitzengefühl und akribisch sauberes Arbeiten notwendig, um crashfrei zu arbeiten. Vor Livegang: Testen! Testen! Testen!
  6. Ist Ihr Projekt mehrsprachig? Wie ist diese Mehrsprachigkeit bisher umgesetzt worden. Früher konnte Joomla selbst keine Mehrsprachigkeit. Dieses wurde durch Erweiterungen wie z.B. JoomFish erreicht. Diese Erweiterung könnte es für das neue Joomla gar nicht mehr geben. Dann haben Sie die Wahl Joomla's neue eigene Sprachfunktion zu nutzen (nicht sehr komfortabel) oder auf leistungsfähigere Erweiterungen zu bauen. Auch hier bleibt die für die Erweiterungen oben schon formulierten Ansprüche mit dem Schwerpunkt: Kann ich die alten Sprachdaten übernehmen und wie?
  7. Was ebenfalls gern bei Projektmigrationen übersehen wird, ist die notwendige Übernahme alter SEF-Adressen in das neue Projekt. Diese sollten auf keinen Fall verloren gehen oder auch nur geändert werden! Dann würden die Suchmaschinen ins Leere greifen und das bekommt dem Page-Ranking nicht. Joomla 3 hat hierfür jetzt eine sehr gutes Routing eingebaut, was früher SEF-Erweiterungen leisteteten aber ggf. nach etwas anderen Regeln. Ggf. müssen alte und neue Adressen durch Aliase verknüpft werden - entweder automatisch oder manuell gepflegt. Manuell macht auch hier nur Sinn bei wenigen Seiten.
  8. Wie ist die Hosting-Situation? Beachten Sie: Viele Komponenten und natürlich auch Joomla-Versionen setzen halbwegs aktuelle PHP- und MySQL-Versionen voraus! Unter Joomla3 sollten Sie mind. PHP 5.4 nutzen! Klären Sie das für Ihren Server und die avisierten Erweiterungen. Prüfen Sie, ob sie die geforderten Versionen auf Ihrem Server/durch Ihren Hoster sicherstellen können? Da Sie nicht alle Projekt zu gleich, oder z.B. das Testprojekt unabhängig vom Live-Projekt migrieren können/wollen, sollten die Versionen ggfl. webspaceweise oder verzeichnisweise eingestellt werden können.



Angebote von Migrations-Dienstleistern einholen und Vorgehensweise

Das oben Ausgeführte, verdeutlich die Komplexität einer Migration, berechtigter Grund warum viel Seitenbetreiber hier die Hilfe von Dienstleistern beanspruchen wollen. Tatsache ist, dass eine Migration immer viel Erfahrung benötigt. Wer hat die schon, wenn man mal eins nur sein eigenes Projekt migrieren möchte? Deshalb ist es sinnvoll hierfür auf die Effizienz von Spezialisten zu setzen.

Leider erreichen mich dann immer Anfrageformulierungen wie "Ich habe ein Joomla 2.5.-Projekt und möchte das auf Joomla 3.x migrieren - Es soll responsiv werden und ich will Template X. Bitte machen Sie mir ein günstiges Angebot."

Nun hierrauf kann man kein Angebot abgeben. Wie oben geschildert hängt die Migration von vielen Faktoren und Projektgegebenheiten ab, die bei der Preisfindung zunächst weitgehend zu beantworten sind. Und selbst wenn das Gross der o.g. Fragen geklärt ist, bleibt immer ein Restrisiko aus Problemen die sich erst bei der Migration des konkreten Projekt offenbaren. Kein Projekt ist wie ein anderes, jedes hat seine Spezifiken und damit potentielle Störquellen für einen autom. Migrationsdurchlauf.

Etwas Sicherheit kann sich der Dienstleister für sein Angebot verschaffen, in dem er sich vorher selbst gründlich im Projekt-Backend umschauen kann. Er sieht mit seiner Erfahrung schnell, welche Inhalte Probleme machen werden, also eher manuell zu übertragen wären, wo ggf. noch keine Erfahrungen vorliegen, also Risiken vorliegen usw. Allein diese Einschätzung - begründet auf Erfahrungen - sind Geld wert, denn sich selbst über alle Erweiterungen zu informieren, und die Migrierbarkeit auszutesten, frist kostbare Zeit. Machen Sie das selbst, sammeln Sie Erfahrungen für etwas, was Sie vermutlich in Ihrem Leben exakt so nicht wieder brauchen werden ;-)

Die Vorgehensweise (zusammengefasst)

Anfrage für ein Angebot sollte idealerweise enthalten:

  1. Auflistung vorhandener Erweiterungen, deren Inhalte und Bedeutung
  2. Ihre Anforderungen z.B. zwingend responsiv etc., SEF-Adressen retten
  3. Wer übernimmt welchen Part
  4. Wie umfangreich ist die Seite 
  5. Sollen alle Daten autom. importiert werden oder gibt es Bereiche die manuell übertagen werden
  6. Bleibt die Seiten/Menüstruktur 1:1
  7. Welches Template wird bevorzugt und soll dessen Design 1:1 verwendet werden oder das alte Design/Layout oder ein "freier" Mix
  8. Mehrsprachigkeit; wie bisher
  9. Gibt es Overrides oder gar Core-Modifikationen, oder Eigenentwicklungen?
  10. Zeitraum/Termin der Umsetzung?
  11. Wie sind die Hostingbedingungen (php-Version, MySQL-Version etc.), Besteht die Bereitschaft zu einem Umzug?

Wenn Sie halbwegs Vertrauen zu einem potentiellen Dienstleister gewinnen konnten, sollten er ein Möglichkeit erhalten, sich im Projekt umzuschauen. Spätestens jetzt sollte der Dienstleister sich mit einem Angebot positionieren können oder aber schlimmstenfalls nach Aufwand abrechnen.

Anmerkung:

Wenn Sie Ergänzungen zu diesem Beitrag haben oder Erfahrungen teilen wollen, können Sie diese gerne Posten.

Wenn Ihnen dieser Beitrag geholfen haben sollte, nehmen Sie eine Bewertung vor (auch per Google+). Beachten Sie auch die Werbebanner. Hierüber finanziere ich meinen Aufwand.