Upgrade von Drupal 7 auf Drupal 9

Die Uhr tickt, die Lebensdauer von Version 7 des Content-Management-Frameworks läuft ab. Höchste Zeit, das Upgrade zu planen.

Dieser Beitrag mit praktischen Tipps zur Planung eines Upgrades auf Drupal 9 richtet sich an Betreiberinnen einer älteren Version von Drupal – nicht an Sitebuilder oder Entwicklerinnen. Auch wenn diese sicherlich von einer guten Vorbereitung profitieren und herzlich eingeladen sind, diesen Link zu teilen.

Warum Drupal-Upgrades bislang immer schmerzten

Die große Stärke von Drupal ist die Anpassbarkeit auf spezifische Anforderungen. Es wird häufig eingesetzt für ambitionierte umfangreiche Web-Applikationen, aber auch für Webauftritte des Mittelstands mit nicht alltäglichen Wünschen. Diese Stärke war viele Jahre lang gleichzeitig auch eine Schwäche, denn vielschichtigen Setups stellten eine große Hürde für Upgrades auf die nächste Hauptversion dar.

Wer sich deshalb aktuell verständlicherweise die Frage stellt, ob es tatsächlich nochmal ein Drupal sein soll, kann sich damit trösten, dass diese Art des Upgrades zum letzten Mal ansteht. Ab der Hauptversion 8 wurde ein neues Upgrade-Konzept eingeführt, das künftig grundlegende Änderungen in sanften Schritten einführt.

Dass dieses Konzept tatsächlich konsequent verfolgt wird, hat die Drupal-Community unter Beweis gestellt. Die 2015 veröffentlichte Version 8 konnte – sofern Minor-Updates kontinuierlich eingespielt wurden – ab dem 3. Juni 2020 problemlos auf Drupal 9 umgestellt werden. Ein quasi kosmetisches Upgrade.

Drupal 7 sollte ursprünglich im November 2021 “sterben” (also keine Sicherheitsupdates mehr erhalten). Aufgrund der COVID-19-Pandemie wurde die Lebenszeit auf November 2022 verlängert. Nichtsdestotrotz sollte die Planung des Upgrades nicht auf die lange Bank geschoben werden, denn Sie haben einiges vorzubereiten (und eventuell auch noch auszuschreiben).

Konzentration auf das Wesentliche

Meine Berufspraxis hat größtenteils mit Website-Relaunches zu tun. Ich habe viele vermeidbare Schmerzen bei allen Beteiligten beobachtet (und natürlich auch selbst erlebt). Die folgenden Empfehlungen sollen dabei helfen, grundlegende Fehler zu vermeiden. Glauben Sie mir: am Ende des Tages wollen alle Seiten – ja, auch die Agenturen – vor allem ein erfolgreiches Projekt umgesetzt haben.

Grundlagen aufschreiben

Häufig werden vermutete Selbstverständlichkeiten übersprungen. Machen Sie sich diese bewusst und schreiben Sie sie auf.

• Was ist der Hauptnutzen der Website?

Natürlich einmal abgesehen von “unsere Repräsentanz im Internet” – geschenkt. Ihre Organisation investiert vermutlich nicht aus Eitelkeit. Der Nutzen kann beispielsweise sein “Umsätze erhöhen”, “Supportaufwand reduzieren”, “Publizieren als Satzungsziel umsetzen”.

Gerne wird ein Relaunch zum Anlass genommen, einiges zu verändern, gern auch alles auf einmal: Endlich das Design für mobile Geräte optimieren und sowieso modernisieren. Schnittstellen zur Warenwirtschaft oder Mitgliederverwaltung anbinden. Neue Schmankerl für die User.

Diese Wünsche sind verständlich, nur wird dabei gern vergessen, was der eigentlich Anlass des Relaunches war: die aktuelle Programmversion ist abgekündigt. Der Erhalt dessen, was wir haben, steht auf dem Spiel. Vergessen Sie deshalb bitte nicht, sich vor Augen zu führen, was erhaltenswert ist.

• Notieren Sie die drei Aspekte, die Ihnen am meisten fehlen würden, wenn sie nicht mehr da wären.

Es sind typischerweise übrigens Ihre wertvollen Inhalte, die lediglich in einem Nebensatz erwähnt werden. Meistens eine dieser Selbstverständlichkeiten, die nicht hinreichend kommuniziert werden. Sofern Sie nicht vorhaben, völlig von vorne zu beginnen, sollten Sie eine Bestandsaufnahme machen. Dazu mehr weiter unten.

Es können aber auch ganz andere Aspekte sein. Beispielsweise das Verhindern gleichzeitiger Bearbeitung von Inhalten, ein eingespielter Workflow mit Ihrem Übersetzungsbüro, eine sorgfältig gepflegte Verschlagwortung, eine Vorschau Ihrer Social-Media-Posts.

Bitten Sie Ihr Team, die individuellen Perspektiven auf das Erhaltenswerte zusammenzutragen. Achten Sie bei diesem Schritt darauf, dass noch keine Verbesserungswünsche geäußert werden. Denn dafür ist der nächste Schritt gedacht:

• Notieren Sie die drei Aspekte, die Sie funktionell am meisten stören/behindern

Üblicherweise beginnt jetzt das Wunschkonzert, deshalb die Beschränkung auf drei Punkte. Der Sinn der Überlegung ist, diejenigen Verbesserungen zu identifizieren, die am dringendsten benötigt werden. Bei einem Relaunch können solche Verbesserungen meist gut eingeführt werden. Wir sollten nur darauf achten, dass das Wunschkonzert nicht zu einer Explosion des benötigten Budgets führt.

Notieren Sie diejenigen Punkte, die dem Hauptnutzen der Website oder aber der Arbeitseffizienz am meisten dienen. Das sind beispielsweise Aussagen wie “Das Einpflegen neuer Produkte ist zu zeitraubend”, “Durch das Nachladen von Bedienelementen klicke ich ständig falsche Buttons” oder “Wegen des manuellen Kopierens von Daten aus E-Mails benötigt unsere Abteilung eine zusätzliche Vollzeitstelle”. Aber auch “Wir bekommen ständig Beschwerden, dass der Download nicht funktioniert” oder “Die großen Bilder auf dem Handy verschlechtern die Orientierung, es kommt zu häufigen Abbrüchen”.

Ein Schritt nach dem anderen

Gratulation, Sie haben das Fundament geschaffen. Die nächsten Schritte sollten sich daran orientieren, das grundlegende Ziel des Relaunches zu erreichen: den zukunftsfähigen Erhalt dessen, was wertvoll für uns ist.

Kennen Sie den Begriff “Backlog”? Wenn nicht, lernen Sie ihn jetzt kennen und sollten ihn nicht mehr vergessen. Das Backlog ist der Sammler all dessen, was an Wünschen, Ideen, Verbesserungen aufkommen, wenn die konkrete Umsetzung des Relaunches geplant wird. “Es wäre doch schön, wenn …” – ab ins Backlog. “Wo wir schon dabei sind, könnten wir nicht …” – ab ins Backlog.

Webentwicklung bedeutet schon lange nicht mehr, dass man etwas baut, dass die nächsten 10 Jahre unangetastet halten kann. Schon allein wegen der Sicherheitsupdates. Berücksichtigten Sie dies bei der Budgetplanung, reservieren Sie ein paar Tage für kontinuierliche Wartung und Weiterentwicklung. Dann kann Ihr Backlog auch nach und nach abgearbeitet werden. Immer wieder einen kleinen Wunsch zu erfüllen ist doch dankbarer als alle 10 Jahre einen größeren.

Schön, wir sind uns also einig, dass wir einen Relaunch planen, keinen “Abriss und Neubau”. Wie geht man jetzt also die Vorbereitung an?

Bestandsaufnahme

Dies ist die wichtigste Empfehlung: Erstellen Sie eine detaillierte Beschreibung des Bestandssystems. Sie können Kosten sparen und gleichzeitig das Risiko minimieren, dass etwas übersehen wird, was während der Migrationsphase zu Mehrkosten führen würde.

Die strukturierte Auseinandersetzung mit Ihrem aktuellen Drupal bringt viel Klarheit darüber, was Sie haben, was Sie weiter benötigen und was unbedingt geändert bzw. neu gemacht werden muss.

Wenn ich mit der Konzeption eines Relaunches beauftragt werde, ist mein Hauptarbeitsinstrument ein Tabellenkalkulationsprogramm (Libre Office Calc oder MS Excel). Strukturierte Daten - die Stärke von Drupal - lassen sich eben am besten in einem strukturierten Format erfassen, also tabellarisch. Wenn ich lediglich Listen benötige, sammle ich diese gegliedert in einem Textdokument.

Je Entity-Typ erstelle ich eine Datei mit einem Tabellenblatt je Bundle. Drupal-Entities sind z. B. Inhaltstypen, User, Taxonomien. Fangen wir mit den leichten Übungen an und arbeiten uns dann zu den komplexeren Aufgaben vor:

Sprachen

Auflisten. Eventuell wollen Sie unterscheiden, welche Sprachen installiert und welche tatsächlich verwendet wurden.

Domains

Auflisten (Quelle: /admin/structure/domains). Nur falls Sie ein Multi-Domain-Setup einsetzen, sonst überspringen Sie diesen Schritt.

Menüs

Auflisten (Quelle: /admin/structure/menu). Bedenken Sie, dass ein Webauftritt typischerweise mehrere Menüs hat und listen Sie alle auf, die für Ihr System aus Ihrer Sicht eine Rolle spielen. Sie müssen nicht sämtliche Links auflisten, nur die Menüs, ggf. deren Position und vor allem ihren Nutzen:

• Hauptnavigation für die Inhalte
• ggf. ein separates Menü für mobile Geräte
• Footer-Menü
• Utilities-Menü (z. B. mit Sprachwechsler, Suche, Login)
• Legal-Menü (z. B. mit Links zu Impressum, Datenschutzerklärung etc.)
• Links zuSocial-Media-Profilen
• Admin-Menü mit administrativen/redaktionellen Links
• ggf. ein zusätzliches Menü mit kuratierten Links für ausgewählte Rollen

Rollen

Auflisten (Quellen: /admin/people/permissions/roles und /admin/people). In eigenen Worten notieren, was die wesentlichen Unterscheidungsmerkmale sind. Anzahl User zählen, die der Rolle zugeordnet sind, z. B.

• administrator (2)
• Redaktion (12)

Inhaltstypen

Kurzfassung: Auflisten (Quellen: /admin/structure/types und /admin/content). Anzahl Nodes zählen, die mit diesem Typen erstellt wurden.

Elaborierte Fassung: Tabellarisch.

Empfehlenswert, wenn im Zuge der Migration Änderungen vorgenommen werden sollen oder wenn Module eingesetzt werden, die in dieser Form bei Drupal 9 keine Rolle mehr spielen.

Bestandaufnahme aller Felder je Inhaltstyp tabellarisch auflisten (mit Angaben zum Typ). Daneben die gewünschte Änderung für Drupal 9 vermerken.

Ein typischer Aufbau einer solchen tabellarischen Übersicht hat bei uns folgenden Aufbau: Eine Zeile je Feld; Spalten …

• Drupal 7
  • Feldname (Label) - z. B. “Artikeltyp”
  • machine name - z. B. “article_type”
  • Feld-/Widgettyp - z. B. “List / Select Dropdown Single-value”
  • Kommentar - z. B. “Mapping: künftig Taxonomie-Referenz”
• Drupal 9
  • Feldname (Label) - “Artikeltyp”
  • machine name - “article_type_ref”
  • Feld-/Widgettyp - “Term-referenc / Autocomplete Single-value”
  • Kommentar - “Listenwerte in neue Taxonomie ‘Article type’ exportieren”

Diese Arbeit ist aufwendig, aber sie lohnt sich, denn zu erstellende Migrationsskripte können direkt hierauf aufbauen. Ihr Vorteil dabei ist, dass Sie jedes Detail auf den Prüfstand gestellt und nichts übersehen haben.

Taxonomien

Unterscheiden Sie hierbei am besten nach “inhaltlich” und “funktional”. Inhaltlich sind Taxonomien (“Vokabulare”), die üblicherweise auf der Website als Links sichtbar sind und auf Seiten führen, auf der alle Inhalte aggregiert sind, die mit diesem Term (“Begriff”) verschlagwortet wurden. “Funktional” sind Taxonomien, die systemseitig verwendet werden, um z. B. Pressemitteilungen von News zu unterscheiden.

Kurzfassung: Auflisten (Quellen: /admin/structure/taxonomy sowie die jeweiligen Übersichten via “Begriffe auflisten”). Anzahl Begriffe je Vokabular zählen. Mehrsprachige Konfiguration notieren.

Elaborierte Fassung: Tabellarisch. Empfehlenswert, wenn die Taxonomien individuelle Felder haben - dann nach dem Muster für Inhaltstypen vorgehen. Nicht erforderlich, wenn lediglich die Standardfelder “Begriff” und “Beschreibung” verwendet wurden.

Media-Assets

Bild- und Datei-Uploadfelder waren gestern. Heute arbeiten wir mit (wiederverwendbaren) Media-Entities. Hier zählen wir mindestens die Medien je Typ über die Dateiübersicht (/admin/content/file). Wenn die Media-Modulsuite in Ihrem Setup schon eine Rolle gespielt hat, prima. Die Auflistung verwendet dann als Quelle: /admin/content/media. Möglicherweise wurden dann auch individuelle Felder an die Media-Assets gehängt. Hierfür ist eine tabellarische Übersicht nach dem Muster der Inhaltstypen wieder sinnvoll. Felder, die mal eine gute Idee waren, aber dann nie genutzt wurden, sollten jetzt vielleicht entfernt werden.

Webforms

Diejenigen Formulare auflisten (Quelle: /admin/content/webform), die benutzt/benötigt werden - und wozu. Anzahl der Felder je Formular auflisten. Den Komplexitätsgrad zu kennen ist auf jeden Fall hilfreich; ein detailliertes Auflisten der Konfiguration ist nur in Ausnahmefällen erforderlich.

Sie sollten aber unbedingt notieren, wenn ein Webformular nach dem Absenden automatisiert verarbeitet, also jegliche Programmlogik, die über das Versenden von E-Mails hinausgeht.

Views

Ab hier wird es speziell, möglicherweise haben Sie auf diese Übersicht in Ihrer Rolle gar keinen Zugriff. Views sind meist essenziell für den Nutzen Ihrer Website, beispielsweise für das Zusammenstellen und Filtern von Produkten, für die Suchergebnisseiten oder für die Präsentation aktuellster Inhalte.

Leider gibt es für Views keinen “Upgrade-Pfad” zu Drupal 8/9 - das bedeutet, sie müssen nachgebaut werden. Deshalb ist eine Bestandsaufnahme hier besonders wichtig.

Auflisten (Quelle: /admin/structure/views) - zumindest die Views, die individuell erstellt wurden. Systemseitig gelieferte Views wie z. B. die Inhaltsübersicht oder die Benutzerübersicht brauchen nicht unbedingt erwähnt zu werden. Diese gibt es auch automatisch im neuen System. Wohl aber sollten sie erwähnt werden, wenn individuelle Anpassungen vorgenommen wurden, beispielsweise eine Filtermöglichkeit in der Inhaltsübersicht nach spezifischen Feldern.

Eine tabellarische Übersicht ist bei Views eher nicht sinnvoll. Hilfreich wird aber sein, wenn wesentliche Filter, Sortierung, Kontextfilter und Bezüge notiert werden.

Module

Ein Ausdruck (PDF) o. ä. der Modulübersicht (Quelle: /admin/modules) ist unbedingt hilfreich beim Einschätzen der Komplexität Ihres Systems.

Sofern Sie so tiefen Einblick haben, sollten Sie selbst jetzt nochmal überdenken, welche Module möglicherweise installiert wurden, obwohl sie nie wirklich benötigt wurden. Das könnte beispielsweise die Integration eines Kartendienstes sein, der mittlerweile stillgelegt wurde. Oder Profile2, mit dem Ihre Benutzer individuelle Profile anlegen konnten, was aber in der Praxis nicht genutzt wurde.

Setzen Sie alles auf die Abschussliste, was für die Migration und weitere Nutzung nicht unbedingt benötigt wird. Nach dem Umzug ist ein besserer Zeitpunkt, um neue Features zu planen.

Custom modules

Das ist wichtig: Möglicherweise nutzen Sie Individualentwicklungen, die essenziell für die Funktionalität Ihrer Webapplikation sind. Es könnte auch eine erkleckliche Anzahl von Sonderfunktionen sein, die sich hinter dem schlichten Namen “Unser Projekt - Custom” verbergen.

Hoffentlich wurde diese Individualentwicklung dokumentiert. Oder aber das Entwicklungsteam ist noch verfügbar und setzt die Anpassungen auf Drupal 9 um. Es werden vermutlich einige “deprecated functions” im PHP-Code zu ersetzen sein.

Wenn beides nicht der Fall ist, könnte das “Reverse engineering” aufwändig werden. Versuchen Sie den Aufwand von vornherein zu minimieren, indem Sie Informationen aus der ursprünglichen Entwicklungsphase zusammentragen: wie viele und welche Anforderungen wurden gelöst? Haben Sie Ihre Tests/Abnahme dokumentiert? Alles kann hilfreich sein.

Schnittstellen

An welche Drittsysteme ist Ihr Drupal angebunden? Besteht ein direkter Datenaustausch (uni- oder bidirektional) zu beispielsweise einem Warenwirtschaftssystem, SAP, Navision, LDAP?

Vermutlich verfolgen Sie zumindest Seitenbesuche über Matomo (ehem. Piwik) oder Google Analytics. Möglicherweise haben Sie eine Marketing-Automation-Software angebunden oder übergeben Informationen an einen Newsletter-Provider.

Oder haben Sie “Teilen”-Funktionen via Twitter, Facebook & Co. integriert? Listen Sie alles auf, was Ihnen dazu einfällt. Auch wenn wir jetzt schon sicher sein können, dass möglicherweise noch etwas übersehen wurde.

Anhaltspunkte liefert Ihnen sicherlich auch Ihre aktuelle Datenschutzerklärung.

Weitere Komponenten

• Paragraphs
• Panels
• Blöcke
• Benutzerprofiltypen
• Custom entity types
• Feeds
• Field Collections

Professionelle Unterstützung

So ein “Umzug mit dem kompletten Haushalt” kann anstrengend werden. Möglicherweise haben Sie neben Ihrem Tagesgeschäft auch nicht die Kapazitäten für solch eine elaborierte Bestandsaufnahme und fachliche Begleitung. Die gute Nachricht: Es gibt spezialisierte Dienstleister*innen (ich bin nur eine davon).

Die Stichworte “Bestandsaufnahme”, “technisches Konzept”, “Website-Migration” sollten in Ihrer Angebotsanfrage auftauchen. Trennen Sie diesen Schritt von einer Angebotsanfrage zur Umsetzung. Erst auf Grundlage der zu erstellenden Bestandsaufnahme lässt sich der Aufwand für die Migration seriös schätzen. Alles andere ist ein Blick in die Glaskugel und wird ganz sicher zu Mehrkosten (oder Wenigerumsetzung) führen.

Fazit + Alternativen

Eine Migration von Drupal 7 zu Drupal 9 ist ein Projekt, das an sich aufwändig genug wird. Verzichten Sie auf goldene Wasserhähne. Lassen Sie diese gesondert anbieten, wenn das Upgrade vollzogen ist.

Wenn Sie bei Drupal bleiben, wird dies das letzte Mal sein, dass ein Upgrade einen solchen Aufwand verursacht. Nach wie vor haben Sie dann aber alle Vorteile der Individualisierbarkeit des Systems.

Sollten Sie jetzt aber feststellen, dass Sie diese Flexibilität eigentlich nie benötigt haben und eigentlich nur Inhalte einer “stinknormalen Image-Website” pflegen wollen, macht Ihnen auch niemand einen Vorwurf, wenn Sie über den Wechsel zu einem der anderen großartigen Open-Source-CMS nachdenken.

Dank der quelloffenen Struktur können Ihre Inhalte auch in ein anderes Content-Management-System migriert werden. Natürlich auch nicht ohne Aufwand und Kosten, aber möglicherweise mit geringeren Folgekosten bei der Wartung.

Über die Autorin

Meike Jung ist seit 20 Jahren Konzepterin für Website-Projekte und hat ungezählte Relaunches geplant sowie als Projektmanagerin begleitet.

Weil sie davon überzeugt ist, dass Werkzeuge (“nicht nur der Hammer”) den Menschen dienen sollen und dass “nicht jedes Problem ein Nagel” ist, hat sie den CMS Garden mitgegründet und ist derzeit Mitglied des Vorstands.