Wellenreiten statt Tiefseetauchen

Drupal-Projekte kann man in einem einzigen grossen Wisch angehen. Oder man kann sie aufteilen in kleine Teilprojekte und diese Teilprojekte laufend veröffentlichen; dabei sind Teile der alten und Teile der neuen Website für eine beschränkte Zeit parallel online. Bei grösseren Websites bevorzugen wir klar Letzteres.

Dieses iterative Vorgehen ermöglicht,

• dass Besucher früh von neuen Features profitieren: Sobald das erste Teilprojekt auf Drupal 9 fertig ist, veröffentlichen wir dieses. So sehen wir, wie die neue Website ankommt und können daraus rasch lernen.
• schneller fertig zu sein: Statt in einer vorgelagerten mehrmonatigen Konzeptions- und Designphase für das Gesamtprojekt, planen wir die Teilprojekte in wenigen Wochen. Darauf beginnen wir mit der Entwicklung. Und während der Entwicklung planen wir bereits das nächste Teilprojekt.
• Risiken zu minimieren: Das Risiko eines IT-Projekts wächst exponentiell mit dessen Umfang (eine Behauptung, aber bisher unwiderlegt). Je kleiner die Teilprojekte, desto kleiner das Risiko für das Gesamtprojekt. Auch, weil wir aus Fehlern früh lernen und das Gelernte bei der weiteren Umsetzung berücksichtigen können.
• dich als Kunden glücklich zu machen: Der Relaunch einer Website bringt auch für Auftraggeber viel Arbeit (Projektleitung, Einbezug der Stakeholder, Testing, Content-Erstellung, Migrationen, Schulung …). Indem wir diese Aufgaben auf Teilprojekte verteilen, reduziert sich deine Spitzenlast.
• laufend Erfolge zu feiern: Weil Teile der Website früh und darauf laufend abgeschlossen und veröffentlicht werden, gibt's immer wieder auf etwas anzustossen. Das hilft der Moral – und die ist für den Erfolg von IT-Projekten matchentscheidend.

Divide and Conquer

Bei einem schrittweisen Vorgehen soll die neue Website möglichst früh möglichst viel Mehrwert bieten. Dazu unterteilen wir die Funktionalität der Website in logische Blöcke. Bestehende Seitentypen können dafür ein guter Ansatzpunkt sein.

Die Priorisierung der Blöcke kann nach verschiedenen Kriterien erfolgen:

• Besucherzahlen: Anhand des bestehenden Analytics-Tools eruieren wir, welche Blöcke von den meisten Besuchern genutzt werden.
• Content-Produktion: Das Erstellen oder Überarbeiten von Inhalten ist zeitintensiv. Es bietet sich deswegen an, Seiten mit viel Inhalt früh anzugehen.
• Mehrwert: Wenn eine bestehende Funktion für das Unternehmen besonders wichtig ist und Optimierungspotential hat, kann es Sinn machen, diese vorzuziehen.
• Abhängigkeiten: Manchmal hängt ein Block von einem anderen ab. Der Block «Automatischer Newsletter-Versand» kann z.B. vom Block «Blog» abhängen, von welchem der Newsletter seine Inhalte bezieht.

Der Spatz in der Hand

Grösste Gefahr eines Relaunchs ist, diesen zu überfrachten: gleichzeitig zu viel Neues zu wollen. Wir empfehlen deswegen, in einem ersten Schritt höchstens die bisherigen Funktionen nachzubilden, welche auch effektiv genutzt wurden.

Ganz ohne Fortschritt macht eine neue Website aber wenig Freude. Deswegen überarbeiten wir in der Regel die Gestaltung komplett. Zudem legen wir gemeinsam fest, wohin sich die Website zukünftig entwickeln soll, damit wir diese Anforderungen früh bedenken können.

Und selbstverständlich lässt sich die eine oder andere Optimierung auch bereits beim Relaunch umsetzen – sofern sie klar definiert, wichtig und überschaubar ist.

Ein Foxtrail

Bei einem Relaunch können URLs ändern; das sollte aber nur der Fall sein, wenn die bisherige URL-Struktur nicht optimal war.

Falls URLs wechseln, machen wir gemeinsam aus, welche Inhalte unter einer neuen Adresse erreichbar sind; wenn Inhalte wegfallen, legen wir fest, was wir den Nutzern stattdessen anzeigen.

Die alten URLs leiten wir auf die neuen via HTTP-Redirect (Status 307) weiter, damit Nutzer und Suchmaschinen direkt zu den Seiten gelangen, die sie erwarten.

Tear Down this Wall!

Während der «Umbauphase» läuft ein Teil der Website auf Drupal 9, ein anderer auf Drupal 7. Das werden die Nutzer bemerken, weil wir im Rahmen des Relaunches das Design aktualisieren; Drupal 9 sieht deswegen anders aus als Drupal 7.

Um die Unterschiede zwischen alt und neu zu minimieren, nehmen wir auf Drupal 7 in der Regel kleine Anpassungen vor: Beispielsweise gleichen wir die Navigation (Gestaltung und Inhalte) an Drupal 9 an.

One for the Geeks

In der Regel läuft auf einer Domain nur ein CMS. Falls dich interessiert, wie wir Drupal 7 und 9 kombinieren, ohne Subdomains zu nutzen: Wir schalten den beiden Drupal-Installationen einen Proxy-Server vor.

Wenn ein Nutzer die Webseite aufruft, gelangt er zuerst zu diesem Proxy-Server. Anhand der aufgerufenen URL entscheidet der Server (gestützt auf eine Konfiguration, die wir hinterlegen), ob er den zugehörigen Inhalt bei Drupal 7 oder Drupal 9 holt – er dient als Weiche. Darauf gibt er die entsprechende Webseite zurück. Der Nutzer merkt davon nichts.

Das ist, wie's tönt: Nicht ganz ohne. Aber mit unserer Erfahrung bestens machbar.

Mal ganz ehrlich

Das geschilderte schrittweise Vorgehen bietet viele Vorteile. Aber eben nicht nur:

• Während der Umbauphase – in der Regel dauert sie einige Monate – laufen Drupal 7 und 9 parallel. In dieser Zeit besteht deine Website aus zwei Websites. Wir halten die Unterschiede so gering wie möglich – aber sie sind bemerkbar.
• Während Drupal 7 und 9 parallel laufen, müssen beide Systeme gewartet werden (z.B. Security Updates einspielen).
• Der Proxy-Server muss URLs auf Drupal 7 oder 9 weiterleiten. Es braucht Disziplin, viel Testing und Erfahrung, um die zugehörige Konfiguration im Griff zu haben. Letzteres fehlte uns beim ersten Release – wir waren bis spät nach Mitternacht im Büro.
• Die Reihenfolge, in welcher wir die Teilprojekte angehen, kann matchentscheidend sein – gerade, wenn diese Abhängigkeiten voneinander haben. Das ist mühsam – aber es ist zentral, dass wir die Blöcke und ihre Abhängigkeiten im Vorfeld durchexerzieren.

Alles wird gut

Im Juni 2020 wurde Drupal 9 veröffentlicht. Der Wechsel von Drupal 8 zu Drupal 9 ist mit minimalem Aufwand verbunden. Bei unseren Kunden führen wir diese Aktualisierung im Rahmen der regulären Wartungsarbeiten aus.

Letztlich: Wir haben hier Drupal als Beispiel verwendet. Eigentlich gehen wir jedes grössere Web-Projekt genau so an: In kleinen Schritten, iterativ. Egal, welche Technologie wir dabei verwenden.