So geht Relaunch: In 14 Schritten zum unfallfreien Neustart

Der Klassiker jeder Online-Abteilung ist der Relaunch, also die Erneut-Neuentwicklung einer Website. Das ist - im Unterschied zum Redesign oder Rebrush - immer ein Eingriff in die Struktur der Site, meistens auch in ihre Funktion und Inhalte.

Daher sollte man meinen, dass es im Internet Literatur und Kochrezepte über den Wechsel von einer alten zu einer neuen Website gibt. Doch weit gefehlt: Wie so oft bei Fachwissen finden sich im Internet nur fragmentarische Hinweise und einige Spezialartikel zum Thema SEO, was aber bei Weitem nicht alle Aspekte trifft. Vielleicht haben Dienstleister nur die Lieferung des Software-Produktes im Auge, während man aus Kunden- (=Betreiber-)Sicht den Schmerz ignoriert, weil er peinlich ist und ohnehin nur alle drei Jahre auftritt. Hier ein paar Hinweise für professionelle Praktiker:

1. Altdaten

Die Bezeichnung "Altdaten" klingt wie "Altmüll", könnte in Wahrheit aber Ihr wertvollstes Vermögen bezeichnen. In Zeiten von "Big Data" und "Content-Marketing" (beide Begriffe schmerzen) wird klar, dass Daten nicht nur im Sinne des Content-Managements "Assets" sind, sondern auch im Sinne der Strategie. Leider sind diese Assets häufig von sehr großer Anzahl (zehntausende sind nicht ungewöhnlich) und vor allem sind diese Inhalte historisch gewachsen, weswegen in vielen Fällen gar kein sicheres Wissen über sie vorhanden ist. Es ist also niemand da, der folgende Fragen verbindlich beantworten könnte:

1. Welche Daten müssen wir übernehmen?
   Und "Daten" meint nicht "alles, was da ist", sondern was sinnvoll ist. Pflegeaufwand und eine Art Datenhygiene (wie ein Strauch, der zu beschneiden ist) sprechen dafür, im Zweifel eher weniger zu übernehmen, die Aufrechterhaltung des SEO-Juices eher für mehr. Zudem enthält die richtige Antwort die exakte Struktur dieser Daten, beispielsweise verschiedene Zeitstempel (wann hat ein Datum einen bestimmten internen Prozessschritt durchlaufen). Es hilft nichts: das Altsystem muss analysiert werden, Objekt für Objekt. Wenn Budget und Politik das zulassen, buchen Sie den alten Dienstleister für einen Workshop. Gehen Sie alle Attribute der Datenobjekte Ihres Altsystems durch, um sich unangenehme Überraschungen zu ersparen.
2. Welche Daten können wir unverändert übernehmen / welche Daten müssen geändert werden? Welche Daten sind vollständig, fehlerfrei, konsistent? Wenn nicht alle: mit welchen Maßnahmen und Personen erreichen wir diesen Zustand?
   Im Arbeitspaket "Analyse der Altdaten" sind Korrektheit, Vollständigkeit und Konsistenz wichtig, weil Korrekturen Ihr Gesamtprojekt deutlich verzögern können. Wegen dieses Risikos muss die Analyse so früh abgeschlossen sein, dass bis zum Systemtest so viel Zeit verbleibt, alle Daten von Hand zu korrigieren. Das geht natürlich häufig nicht, also ziehen Sie ein Sample der Daten und achten Sie darauf, dass es repräsentativ ist und nicht nur das Schönste dessen, was sie haben. Also: Analyse mit Sample, dann gegebenenfalls Maßnahmenplan. Und überschätzen Sie die Rolle der Maschinen dabei nicht: der beste Scraper und der beste Importer oder Datenveredler kann aus Garbage nur Garbage erzeugen. Lieber mehr Zeit in manuelle Prozesse stecken, wenn es irgend möglich ist.

Wenn Sie sich des Themas nicht frühzeitig annehmen, stoßen Sie drei Tage vor dem Launch im Systemtest auf Fehler, weil Ihr neues System Fachlogik enthält, die auf fehlerhaften Daten aufbaut (was ja eigentlich das Wesen von Fachlogik ist). Beispiel: Sie haben Georestriction-Attribute oder Zeitstempel zum Publikationsende. Wenn diese Daten nicht korrekt sind, wird Ihr System schwere Fehler produzieren.

2. Metadaten

Metadaten sind eigentlich ein Unterfall von Punkt 1, aber so wichtig, dass sie eine gesonderte Betrachtung erfordern. Hier tauchen des Öfteren drei Fragen auf. Die erste ist: Unter welchen Bedingungen kann ein Objekt publiziert werden? Diese sog. Legal Restrictions sind extrem wichtig, weil sie teure Haftungsfälle auslösen können. Ein zweiter Punkt sind Taxonomien, Thesauri, Ontologien und andere Strukturen - hier reicht es nicht, die Metadaten zu migrieren, vielmehr muss auch die Hilfsstruktur (z.B. der Thesaurus) mitmigriert werden.

Während manchmal schon die Daten nicht aus dem Altsystem exportierbar sind, weil ein Vollexport nie vorgesehen war, bedarf das Herausschälen der Hilfsstrukturen und das Integrieren in das Neusystem besonderer Chirurgie, da es Softwarekomponenten sind, die eng mit den Metadaten verzahnt sind. Ein drittes Beispiel sind Attribute, die erst durch Nutzerinteraktion entstehen: Was tun mit 5-Stern-Ratings, wenn das Neusystem 6 Sterne hat? Was tun mit Best-of-Listen etc.? Dazu auch Punkt 4.

Bild: HighText Verlag Eine kurze Geschichte des Relaunchs: Screenshots von 2003, 2007 und 2013.

Bild: HighText Verlag Allerdings gelten für Shops eigene Gesetze beim Thema Relaunch...

Bild: HighText Verlag ...denn Relaunches im E-Commerce sind mit Vorsicht zu genießen und vergrätzen oftmals Kunden.

3. URL-Migration (SEO und Zugänglichkeit)

Die URL-Migration ist für alle wichtig, die über Google   gefunden werden möchten. Auf den ersten Blick klingt es trivial, für alte URLs eine Umleitung auf neue URLs zu definieren, aber so einfach ist es leider nicht. Erster Schritt ist, alle URLs aufzulisten, für die ein Redirect eingerichtet werden soll. Da die wenigsten Systeme die genutzten URLs liefern, lassen Sie sich diese von einem Backlink-Tool anzeigen, was Ihnen auch ein SEO-Experte abnehmen kann. Anhand der Ziel-URLs des neuen Systems müssen Sie sodann eine exakte Zuordnung von alten zu neuen URLs entwickeln. Das ist einfach bei statischen Seiten, etwa vom alten zum neuen Impressum.

Schwierig ist es bei Datenbankinhalten, die als generierte Webseiten sehr komplexe URLs erzeugen, die beispielsweise Nummern und IDs enthalten - hier müssen Sie wissen, was sich dahinter verbirgt, und das wiederum bedeutet meistens, dass sie entweder im Nebel tausend Heuhaufen suchen müssen oder jemanden finden, der die Bedeutung dieser URLs mal kannte (Tipp: Das ist der Programmierer, der längst die Firma verlassen hat). Außerdem sollten Sie es sich nicht zu einfach machen und einfach zig spezifische URLs auf eine einzige Seite umleiten, zum Beispiel 20 Texte auf eine neue Themenseite - Google mag das nicht so gern und verlangt eine möglichst granulare Zuordnung von URL zu URL. Haben Sie das erledigt, brauchen Sie noch Redirects für alte Inhalte, auf die z.B. soziale Netzwerke verweisen. Und am Ende muss jemand aus Ihrer Fachlichkeit ein kleines Programm entwickeln, das die htaccess-Datei für den Webserver generiert. Alles zusammen kann fachlich schwierig sein, sodass Sie am besten mindestens vier Wochen vor dem Launch mit der Konzeption beginnen. Denn: Sie müssen gefühlt 80 Prozent Ihrer URLs spätestens 48 Stunden nach dem Relaunch redirected haben, sonst stuft Sie Google ab.

Und wenn wir schon mal dabei sind: Achten Sie darauf, dass Ihr Dienstleister die Testsysteme von der ersten Sekunde an mit einer robots.txt-Datei versieht, die Google das Crawlen verbietet, sobald jemand fahrlässigerweise den Passwortschutz von der Site nimmt. Sie haben sonst nämlich Schrott bei Google. In diesem Zusammenhang bitte auch darauf achten, dass bei etwaigem Parallelbetrieb der alten Site der Crawler ausgesperrt ist und Links auf canonical gesetzt werden.

4. User Generated Content

User Generated Content ist normalerweise nicht selbstständiger Inhalt, sondern hat - wie Kommentare - einen Bezug auf redaktionellen Inhalt und ist daher nicht ganz leicht zu migrieren. Ich habe noch nicht einen einzigen Relaunch bemerkt, der diese Inhalte übernommen hat. Das ist ein überraschend unfreundlicher Akt den Nutzern gegenüber. Theoretisch sollte es möglich sein, wenn es sich um klassische Kommentare handelt, mit Datenstrukturen wie hcomments von A nach B zu migrieren, zumal die Nutzerprofile ja ohnehin migriert werden müssen. Alternativ möchte ich anregen, bei älteren Artikeln die Kommentarstränge als eine statische Seite auszuspielen und eventuell auch die Kommentare zu schließen. Das sollte eine pragmatische Lösung sein.

5. SEM

Es empfiehlt sich, alle Anzeigen auf Google durchzusehen, ob sie so noch verwendet werden können. Die URL von Landingpages und die Site-Struktur haben sich ja fast immer verändert. Es ist bei Brand Searches ein bisschen peinlich, wenn oben die falsche bezahlte Anzeige steht und darunter die unbezahlte richtige.

6. Schnittstellen, Wucherungen und Balkone

Sie denken, Sie wissen genau, was Ihr Altsystem macht? Dann schalten Sie es mal ab und warten Sie, wer es vermisst. Ganz beliebt ist nämlich, dass es irgendeine Schnittstelle eines anderen Systems bedient, von dem Sie noch nie gehört haben, oder dass irgendjemand vor Jahren noch ein Pflege- oder Analysetool angeflanscht hat, das auch Sie nicht kennen. Ergo: Fragen Sie den alten Projektleiter, den Dienstleister und Ihre Kollegen im IT-Betrieb nach Abhängigkeiten anderer Systeme und Funktionsmodule, die nicht zum Kernsystem gehören. Eventuell erfahren Sie schon früh von Wucherungen und Balkonen, die man angebaut hat. Die müssen Sie nämlich mit migrieren oder überflüssig machen. Wer versorgt eigentlich Ihre Apps mit Inhalt?

7. Webanalyse

Man möchte meinen, dass man nur ein Stück Javascript oder einen Link auf einen Pixel in jedes Template einfügen muss, um auch die Nutzung der neuen Site analysieren zu können. Als Profi weiß man, dass man natürlich auch eine Systematik an Performance-Indikatoren zusammenstellen, bestimmtes Verhalten analysieren und Reports zusammenstellen muss. Unmittelbar nach dem Relaunch ist Webanalyse so wichtig wie sonst nie, weil Nutzer erstmals auf neue Strukturen stoßen und der Traffic des Öfteren um 20 Prozent einbricht. Die Konsequenz: Bereiten Sie vor dem Launch alles vor, damit sie alte und neue Sites vergleichen können. Hat man das gleiche Tool wie zuvor, muss man sich entscheiden, ob man allen Traffic in den alten Site-Datenstrom laufen lässt oder ob man einen zweiten anlegt und dann eine Weile zwei Datenströme betrachtet, die man vielleicht in einer Tabellenkalkulation zusammenführt.

Hat man zugleich auch das Tool gewechselt, stellt sich die Frage, wie man Altdaten eines Systems in ein neues Webanalyse-System übernimmt. Ich persönlich bevorzuge die Philosophie, bei Webanalyse ganz maßnahmenorientiert nach vorne zu sehen, und würde mir daher vor dem Relaunch einige KPIs zusammenstellen, die kurzfristig einen Vergleich ermöglichen, also z.B. den Durchschnitt der Monatswerte einer Hand voll KPIs. Wenn in der Woche nach dem Launch z.B. die Anzahl der Besucher fast auf dem Niveau der letzten Monate ist, ist alles gut. Wenn dem nicht so ist, helfen alte Daten auch nicht, dann muss man eine Tiefenanalyse der Nutzung der neuen Site vornehmen.

Relaunch: Für wen, warum, wann

Der Relaunch ist tabu für: Onlineshops: Warum: Für ECommerce-Seiten sind dramatische Relaunches tabu. Dort kann man das Risiko nicht eingehen, den Kunden zu verlieren, weil dieser sich nicht mehr zurechtfindet. Besser: Sukzessive, feine Änderungen, die der Kunde kaum spürt. Diese Änderungen sollten immer mit Tests verbunden sein. Soziale Portale: Warum: Ein Komplett-Relaunch ist auch für soziale Portale ein No-Go. Immerhin hat sich mancher User noch immer nicht an die Umstellung von Open BC auf Xing gewöhnt. Und selbst die Einführung der Timeline auf Facebook hat viele Nutzer verunsichert. Besser: Aus diesen Beispielen sollten soziale Portale lernen und Änderungen der Seite so behutsam wie möglich durchführen. Der Relaunch eignet sich für: Marken-Websites: Warum: Die Neuorientierung oder der Imagewechsel einer Marke sollten mit einem Website-Relaunch unterstrichen werden. Außerdem müssen Markenseiten aus Imagegründen immer technisch und visuell auf dem aktuellen Stand sein. Wann: Je nach Situation und Branche alle drei bis fünf Jahre Der Relaunch eignet sich bedingt für: Newsportale Warum: Hier muss man mit Relaunches vorsichtig sein. Zum einen handelt es sich ebenfalls um eine Markenseite, die aber andererseits mehr oder weniger über Klickzahlen finanziert wird. Besser: Da ein Nutzerzahlen-Einbruch fatal wäre, aber die Seite immer modern bleiben muss, braucht es einen Kompromiss und gut durchdachte, ausgiebig getestete Webseiten-Anpassungen.

8. Rechtsdokumente

Natürlich gehört die Anpassung einer Website an rechtliche Erfordernisse ebenso zur regulären Pflege wie die Aktualisierung von rechtlich relevanten Dokumenten um Rahmen von Change Requests. Soweit die Theorie. In der Praxis wird nicht jedes Unternehmen jedes Dokument ständig aktuell haben, weil das permanente Monitoring der Rechtslage bei gleichzeitiger Kenntnis der Fachlichkeit aufwändig ist. (Für Großunternehmen mit gut bestückten Rechtsabteilungen gilt das weniger, diese haben aber dann mit der Vielzahl an Anwendungen zu kämpfen.)

Selbstverständlich prüft man daher die Nutzungsbestimmungen, Datenschutzbestimmungen und Erklärungen entlang von Transaktionen (Widerrufserklärung bei E-Commerce etc.) auf Aktualität. Leider sind aber auch erstens Texte im Frontend durchzusehen, zweitens neue Funktionslogik rechtlich zu prüfen sowie drittens Funktionslogik aufgrund neuer Rechtslage zu ändern. Ein schönes Beispiel für den letzten Fall sind Zwei-Klick-Lösungen bei Sharing-Buttons, die rechtlich veranlasst sind. Diesen Prozess kann man nur ganz fehlerfrei durchlaufen, wenn die Juristen die gesamte Fachlichkeit des Systems kennen, was in der Praxis zu aufwändig und im übrigen auch selten von Erfolg gekrönt ist, weil Fachlogik keine juristische Fachlichkeit ist und Juristen also das Fachthema nicht gut verstehen. Rechtsfragen beim Relaunch sind also prinzipiell ein Bermudadreieck, bei dem Probleme verschwinden wie die Titanic und danach titanische Eisberge auftauchen. Es ist daher Managementaufgabe, sich - die Fachlichkeit und mögliche Rechtsprobleme zugleich (!) im Blick - diesem Themenkomplex zu widmen.

9. Nutzer-Feedback

Hier sind drei Dinge zu tun: Erstens ist es für eine Evaluation sinnvoll, wenn man den Nutzern noch auf der alten Website ein paar Fragen stellt, die auch auf der neuen Site gefragt werden sollen - und zwar exakt die gleichen! Auf diese Weise hat man dann Vergleichswerte, um die Antworten zur neuen Site richtig einordnen zu können, die relative Veränderung entscheidet. Zweitens sollte man ein Feedback-Tool bis einige Zeit nach dem Relaunch in die Website integriert haben (beispielsweise Jira oder Zendesk), damit unzufriedene Nutzer sich dort artikulieren können. Drittens sollte man nun wieder eine Umfrage machen, deren Kernfragen wegen der Vergleichbarkeit nun wiederholt werden (Werkzeugklasse Surveymonkey o.ä.)

10. Rollback

Zeigt sich nach dem Relaunch, dass auf die alte Website zurückgeschaltet werden muss (Rollback), ist das ganz einfach dadurch möglich, dass man die URL wieder auf das Altsystem zeigen lässt. Zu diesem Zwecke empfiehlt es sich, das Altsystem für einen kurzen Zeitraum weiterzupflegen, z.B. bei einer Newssite. Sinnvoll ist es auch, eine spezielle statische Wartungsseite vorbereitet zu haben.

11. CDNs

Viele größere Websites werden mit vorgeschaltetem Cache-Server und Content Delivery Network (CDN) betrieben, damit Seiten schnell ausgeliefert werden und die eigentliche Applikation entlastet wird. Dies bedeutet dreierlei. Erstens müssen Sie mit Umstellungszeiten von einer Stunde o.ä. rechnen, bis die Replikation über alle Maschinen eines CDN erfolgt ist. Und sie müssen die Performance mit CDN in einem realistischen Szenario messen lassen, also mit "warmem Cache" und richtig eingestellten Content-Lebenszeiten (TTL). Schließlich sollte das auch im Live-Betrieb sofort funktionieren und nicht nur im Testbetrieb, dafür müssen die richtigen Inhalte gecacht werden - ein Spezialthema für Techniker, das ich hier nicht weiter erläutere. Fragen Sie aber Ihren Dienstleister, welche Strategie er verfolgt.

12. Nutzerkommunikation

Zur Pressemeldung: Wenn man nicht gerade die New York Times ist oder ganz wichtige Features zu vermelden hat, ist ein Relaunch eigentlich eine Nicht-Meldung. Es gibt nicht so viel zu sagen, was die Menschen interessiert. Trotzdem ist es ein guter Kommunikationsanlass. Ich empfehle daher, aktiv auf Multiplikatoren zuzugehen, damit später Backlinks entstehen.
Auch auf der Site selbst muss etwas über den Anlass und den Schwerpunkt stehen - das können Stammbesucher erwarten. Und für die Vermarktung in Social Media sollte man sich nicht zu fein sein, den Hinweis auf den Relaunch mit einem pfiffigen Gewinnspiel zu verbinden.

13. Betrieb

Unter diesem Stichwort verbergen sich zwei Klassiker. Der eine ist, dass Applikationsentwickler und Betriebsleute aus mir unerfindlichen Gründen immer wieder davon ausgehen, dass man mit einer E-Mail ja bereits geklärt hat, was man braucht. Die einen scheinen etwas unterentwickelte Vorstellungen der Betriebsinfrastruktur zu haben, weswegen sie überrascht sind, wenn Loadbalancer andere Sachen machen als sie stillschweigend erwartet haben. Umgekehrt haben Betriebsleute nicht immer die Phantasie von Applikationsentwicklern, und so kann es passieren, dass eine Firewall alle 30 Minuten Datenbankverbindungen kappt ("Das machen wir immer so, das ist hier Sicherheitsstandard"). Also: bringen Sie diese Welten am besten zu Beginn des Projektes an einen Tisch. Eigentlich sollten die Spezifikationen für den Entwicklungsauftrag vom IT-Betrieb vorgegeben werden.

Und zum Projektauftakt sollte die Betriebsumgebung bis zur Releasenummer jeder Komponente vollständig und schriftlich beschrieben sein, während der Applikationsentwickler ein Architekturdiagramm mitbringt, welche Komponenten wie miteinander kommunizieren. Klassiker Nummer zwei unter dem Stichwort "Betrieb" sind die Kommunikationsprozesse unmittelbar nach dem Launch: Wer macht bei wem ein Ticket auf? Wer hat wessen Handynummer? Wer lässt was monitoren und wer wird bei Ereignissen informiert?

14. Dauerschuldverhältnisse

Schon für mittelgroße Websites bestehen häufig Wartungsverträge, die rechtzeitig gekündigt werden müssen. Sinnvoll ist es meistens für den Site-Betreiber, für eine Übergangsphase eine einseitig verkürzte Kündigungsfrist vorzusehen. Manchmal bestehen auch noch andere Verträge, nämlich solche für Lizenzen an Softwareprodukten (z.B. CMS), für Datenlieferungen (Produktfeeds als XML oder API), Fotos und andere Inhalte. Hier muss sich aus der Differenzanalyse zwischen alter und neuer Website erkennen lassen, ob die Verträge geändert oder aufgehoben werden sollten.

---

iBusiness-Autor Christoph Kappes ist gelernter Jurist, hat das aber überwunden. Der Geschäftsführer des Beratungsunternehmens Fructus   hat in 20 Jahren über 1.000 Projekte abgewickelt.