Thema im Fokus: Drupal 7 auf Drupal 10 Migration

Am einfachsten ist hier die Frage zu beantworten, wohin man keinesfalls mehr migrieren sollte: und zwar auf die Version Drupal 8. Denn diese Version ist bereits seit dem 2. November 2021 End Of Life, wird nicht mehr weiterentwickelt und erhält keine Sicherheitsaktualisierungen mehr.

Sofern Sie also noch zu denjenigen gehören, die ein Drupal 8-Projekt betreiben, gilt: eine Aktualisierung muss so schnell wie möglich durchgeführt werden, um wieder auf der sicheren Seite zu sein.

Etwas differenzierter stellt sich aktuell noch die Lage bei Drupal 9 dar: dieses wird noch bis November 2023 supported, und unter Umständen benötigen Sie für Ihr Projekt ein Modul, welches noch nicht für Drupal 10 aktualisiert wurde. In diesem Fall kann es Sinn machen, zuerst das Upgrade auf Drupal 9 zu fahren und dann einige Zeit später auf Drupal 9 zu upgraden.

Je näher das Support-Ende von Drupal 9 aber rückt, desto weniger sinnvoll ist diese Option. Spätestens ab Sommer 2023 lässt sich klar sagen: eine Migration sollte in jedem Fall nur direkt auf Drupal 10 erfolgen.

Selbstverständlich ist es eine valide Option, auch "über den Tellerrand" zu schauen und ggf. andere Content-Management-System zu evaluieren, wenn es darum geht, ein Drupal 7-Projekt zu ersetzen.

Oft dürfte aber die Entscheidung, auf Drupal zu setzen, sehr bewusst gefällt worden sein, da Drupal nicht nur ein Content-Management-System ist, sondern eben ein Web-Applikation-Framework. Als solches lässt es sich als Fundament für sehr komplexe und anspruchsvolle Systeme verwenden - ein Usecase, der so nicht unbedingt auch bei anderen verbreiteten CMS vorgesehen ist.

Zudem sind viele logische Konzepte und Prinzipien auch in den Folgeversionen Drupals die gleichen geblieben. Wer also mit Drupal 7 vertraut ist, findet sich nach ein wenig Einarbeitung auch in Drupal 10 zurecht.

Ein klares Nein. Die Ankündigung der dritten Support-Verlängerung im Juni 2023 enthält auch den deutlichen Hinweis, dass es sich diesmal um die letzte Verlängerung handelt.

This will be the final extension.

Mit anderen Worten: es verbleiben ab dieser Ankündigung noch rund 18 Monate, um den Abschied von Drupal 7 in die Wege zu leiten und durchzuführen, sofern das entsprechende Projekt auch nach dem Drupal 7 "End of Life" weiterentwickelt und mit Sicherheits-Aktualisierungen versorgt werden können soll.

"There is a module for that" ist seit langem eine Art inoffizieller Claim von Drupal. Contrib-Module stellen ein bestimmtes Set von Funktionen bereit, die den Drupal-Kern ergänzen. Manche Contrib-Module bauen sogar auf anderen Contrib-Modulen auf und potenzieren somit die Erweiterungsmöglichkeiten Drupals.

Für Drupal 7 gilt dieser Claim in erheblich größerem Maße als inzwischen für Drupal 10. Denn die neueren Versionen Drupals haben viele Funktionen, die früher nur mittels Contrib-Modulen verfügbar waren, in den Drupal-Kern übernommen. Andere Module sind obsolet geworden, weil sich die gebotene Funktionalität heute über Sitebuilding oder Konfigurationsmöglichkeiten in Drupal abbilden lässt.

Trotzdem kann es natürlich passieren, dass es für ein bestimmtes Feature-Set eines bisherigen Drupal 7-Moduls noch keine adäquate Ensprechung als Drupal 9 oder 10-Modul gibt und somit ein Rewrite oder eine Portierung des Moduls notwendig wird.

Aber auch hier wird man von der Community nicht alleine gelassen. Neben umfangreichen Informationen, wie Module für Drupal seit Version 8 umgesetzt werden müssen, gibt es sogar ein Modul, das bei Modul-Upgrades helfen soll.

Zudem haben spezialisierte Dienstleister wie die Drupal-Agentur erdfisch natürlich auch das dedizierte Portieren von Modulen im Portfolio.

Die Handhabung von eigenen Modulen - so genannte "Custom Modules" - unterscheidet sich grundsätzlich nicht von veröffentlichten Contrib-Modulen.

Bei einer Migration eines Drupal 7-Projekts nach Drupal 10 wird die Business-Logik, die das fragliche Custom-Modul bereitstellt, analyisiert. Im Rahmen der technischen Konzeption wird dann entschieden, ob die Funktionalität durch die größeren Möglichkeiten der neuen Drupal-Version auf anderem Wege bereit gestellt werden kann, oder ob ein Custom-Modul weiterhin die beste Option darstellt. Im letzteren Fall wird das Custom-Modul für die Verwendung mit Drupal 10 portiert.

Die Frage lässt sich pauschal nicht beantworten. Es gibt in der Tat Drupal-Systeme, die von außen nicht zugänglich sind. Das kann beispielsweise ein Firmen-Intranet sein, welches nur von Computern innerhalb eines bestimmten IP-Clusters aufgerufen werden kann oder nur erreichbar ist, wenn man sich in einem speziellen VPN-Netzwerk befindet.

Da diese Systeme nicht öffentlich sind, fallen somit die meisten typischen Angriffsvektoren weg, über die eine potentielle Kompromittierung möglich wäre. Entsprechend geringer kann hier im Hinblick auf Sicherheitsaspekte die Notwendigkeit sein, Drupal 7 nach dessen Support-Ende abzulösen.

Es bleiben aber natürlich trotzdem Argumente, die auch in diesem Fall für eine Migration sprechen, wie z.B.

• dass es zunehmend schwieriger wird, Dienstleister für die Betreuung des veraltenden Systems zu finden oder
• dass neue Technologien nicht unterstützt werden und somit eine Weiterentwicklung des Systems langfristig nicht mehr möglich ist
   

Für den sehr speziellen Fall, dass ein D7-Setup

• weder von außen zugänglich ist
• noch in irgend einer Form Weiterentwicklung oder nennenswerten Support bedarf

ist die Notwendigkeit für eine Migration aber tatsächlich auch nach dem Support-Ende von Drupal 7 als relativ gering einzustufen.

Eine pauschale Antwort auf die Frage, welche Kosten bei einer Migration von Drupal 7 nach 10 anfallen können, gibt es leider nicht.

Zuviel hängt hier von der individuellen Komplexität des betroffenen Projektes ab und von Fragen wie:

• wie umfangreich und komplex ist das aktuell vorhandene Datenmodell?
• wie wurde die vorhandene Business-Logik abgebildet? Gibt es z.B. viel Individual-Entwicklung im Projekt?
• sollen Datenmodell und Business-Logik im neuen System exakt gleich bleiben, oder wird die Gelegenheit genutzt, diese Projekteigenschaften einer grundlegenden Revision zu unterziehen und ggf. neue Funktionen zu planen oder veraltete zu entfernen?
• soll der vorhandene Datenbestand komplett migriert werden, oder gibt es im abzulösenden System auch Daten, die künftig nicht mehr gebraucht werden?
• müssen auch Schnittstellen oder Drittanwendungen, die mit dem Bestandssystem interagieren, betrachtet und ggf. überarbeitet werden?

Daher müssen Projekte, die für eine Migration nach Drupal 10 vorgesehen sind, im Vorfeld auch immer einer eingehenden Bestandsaufnahme unterzogen und die vorhandenen technischen Konzepte analysiert werden. Nur auf diesem Wege können belastbare Aufwände ermittelt werden, und nicht nur willkürlich geratene Zahlen präsentiert.

Das kommt darauf an, welche Art von Web-Projekt Sie betreiben. Hier ein paar mögliche Szenarien:

1. Es gibt keinen authentifizierten Traffic auf Ihrer Seite
   Wenn Sie lediglich Informationen auf Ihrer Drupal 7-Webseite anbieten und es keine Möglichkeit zur Nutzerinteraktion gibt oder sich die Nutzer nicht auf Ihrer Webseite anmelden können, können Sie einen so genannten Static Site Generator einsetzen. Dabei handelt es sich um Dienste, die aus den Seiten, die normalerweise das CMS anhand der Inhalte aus der Datenbank und dem Theming der Benutzeroberfläche ausspielt, einfache HTML-Seiten generieren. Die Bezeichnung "statisch" rührt daher, dass diese Seiten dann unveränderlich sind.
   Das veraltete Drupal selbst kann dann von außen unzugänglich gemacht werden, während die von außen erreichbaren "statischen Seiten" keine Angriffsmöglichkeiten für Dritte mehr bieten. Ein ensprechendes Modul hierfür wird auf drupal.org angeboten.
2. Die Webseite erfährt keine Aktualisierungen mehr
   Auch in diesem Fall können Sie die komplette Seite über einen Static-Site-Generator zu einem Zeitpunkt X "crawlen" lassen und das daraus resultierende Archiv als statische Seiten bewahren.
3. Auf der Webseite gibt es authentifizierten Traffic
   Häufige Szenarien sind ein Online Shop, eine Community oder ein Intranet. In diesem Fall ist Drupal 7 immer involviert in die Content-Auslieferung bzw. die Entgegennahme von Content, da die Nutzer mit dem System interagieren können müssen.
   Falls die Personengruppe stark eingegrenzt ist wie z.B. bei einem Firmen-Intranet, besteht die Möglichkeit, das Risiko dadurch zu reduzieren, dass das System von außen unzugänglich gemacht wird - etwa, indem es nur über bestimmte freigegebene IP-Adressen oder ein VPN zugänglich gemacht wird.
   Online-Shops oder öffentliche Communities, die vom freien Zugang zum System leben, haben diese Option selbstverständlich nicht. Hier haben die Betreiber letztlich nur die Wahl zwischen 2 Optionen:
   a) die Einstellung des Angebots
   b) oder eine Migration auf Drupal 10 oder ein anderes System