Ein Traum: Das Telefon klingelt und der Kunde (B2B, weltweit agierend) „droht“ mit Auftrag. Ein Relaunch der Website soll es werden, auf einer neuen Technologie und sogar ein paar Ziele hat er bereits definiert: Top! Eine Websitemigration steht an.
Trotzdem wird es in einigen Fällen im Laufe des Projekts zu einer beliebten Diskussion kommen: Was passiert eigentlich mit den alten bzw. bestehenden Inhalten – kann man diese nicht einfach migrieren oder in der neuen Struktur zusammenführen?
Diesen Zahn mussten wir unseren Kunden bis auf wirklich wenige Ausnahmen bisher immer(!) ziehen und es gibt auch sehr gute Gründe, weshalb eine Migration von bestehendem Content in den meisten Fällen nicht sinnvoll ist.
Websitemigration: Alter Wein in neuen Schläuchen?
Eine neue Website ist nicht unbedingt günstig und wenn man schon den einen oder anderen Euro für ein solches Projekt in die Hand nehmen möchte, dann bitte doch auch mit Sinn und Verstand. Oft ist das bestehende Projekt schon in die Jahre gekommen. Dadurch hat sich vielleicht auch das Marketing, die Kundenansprache, die Bildsprache, das Produktportfolio oder die Strategie des Unternehmens geändert. Diese neuen Umstände mit schon betagteren Texten und Bildern zu untermauern scheint nicht nur schwierig, es ist auch so.
Ein Relaunch einer Website sollte in der Konzeptionsphase auch immer eine Content Landscape und Sitemap mit berücksichtigen, sowie das vorgelagerte Erstellen von neuen Texten und Inhalten, das ganze bitte gemappt auf die konzipierten Module. Die Übernahme der erstellten Inhalte in das CMS im späteren Projektverlauf stellt im Idealfall eine reine Fleißarbeit dar: Bilder und Texte an die definierte Stelle mit einer definierten Vorlage einfügen.
Fazit: wenn Relaunch, dann aber auch bitte richtig, Alter Wein in neuen Schläuchen hilft keinem wirklich weiter.
Ein Importer ist komplex und teuer
Warum ein Importer so komplex und teuer ist? Das ist recht einfach zu erklären, wenn man sich die Features anschaut, die er so besitzen muss. Zunächst einmal muss der Content für die Websitemigration aus dem alten System heraus extrahiert werden. Im Idealfall gibt es einen Exporter, im Notfall könnte man auch noch aus statischen Seiten mit robustem HTML Dom Tree die Inhalte exrahieren. Wenn man Glück hat und die Formatierungen sind nur über Stylesheets vorgenommen worden, so besitzt man am Ende des Tages eine Sitemap, Texte und Bilder, dazu vielleicht ein paar interne Links, leere Stellen, an denen Funktionen integriert waren (Teaser, Linklisten, Ansprechpartner usw.).
Soweit zum einfachen Teil, dem Export.
Dazu haben wir bis auf eine einzige Ausnahme aber noch kein einziges Projekt erlebt, in dem wirklich nur die Technologie gewechselt und die Sitemap und die Inhalte 1:1 übernommen wurden. Wenn sich aber die Sitemap unterscheidet, dann fallen entweder Seiten weg, sie werden umsortiert oder ggf. zusammengefügt. Damit tut sich ein Automatismus schon im Grundsatz schwer.
Wenn es neue Module und Stylesheets gibt, dann gibt es vermutlich auch ein neues Layout mit neuen Bildformaten, denn zumindest an die neuen Browser und an eine optimale Darstellung auf mobilen Geräten mittels responsive Design sollte man seine Website trotzdem anpassen (auch wenn man “nur” die Technologie wechseln möchte). Die Verwendung der alten Bilder wird oftmals nicht möglich sein, daher müssen ggf. neue Bilder integriert werden.
Vielleicht liegen die neuen / alten Bilder jetzt aber auch (am besten nur teilweise) in einem MAM (Media Asset Management) und müssen extern referenziert werden. Über die Schnittstelle reden wir gar nicht erst, aber dass die Bilder so heißen wie man sich das vor ein paar Jahren mal überlegt hat, glauben wir alle erst einmal so nicht. Das gleiche gilt übrigens auch für andere Dokumente (Dokumentationen, Sicherheitsdatenblätter, Ausschreibungstexte, usw.)
Was wir an dieser Stelle auch einmal absichtlich außer Acht lassen, um es nicht unnötig kompliziert zu machen, ist die oftmals vorhandene Anforderung an Mehrsprachigkeit und die Wiederverwendung von Inhalten in mehreren Webseiten-Versionen (z.B. Länder-Auftritten).
Ein weiterer wichtiger Punkt ist die Suchmaschinenoptimierung der Website
Bestehende Metadaten wie Descriptions oder Seitentitel passen nach der Websitemigration eventuell nicht mehr und müssen optimiert oder ausgetauscht werden. Oder der Schwerpunkt wird auf andere Keywords gelegt, die sinnvoll in den Website-Texten platziert werden müssen.
Selbst wenn wir es also schafften, die vielen hundert Seiten mit einer Logik zu versehen, die die Seiten fachlich korrekt bearbeitet, Referenzen und Verlinkungen sicherstellt, dem neuen Layout entspricht usw., dann liegt nachträglich die Qualitätssicherung und Korrekturphase an, denn: zu 100% wird der Importer das gewünschte Ergebnis nicht herstellen können, vermutlich nicht einmal zu 70%.
Ergänzend liegt das Ergebnis erst sehr spät im Projektverlauf vor, die Phase für die QS ist kurz und somit haftet dem Importer auch noch ein großes Risiko an.
Unsere These lautet daher
In der gleichen Zeit bzw. zu geringeren Kosten ist es locker möglich, jede Seite komplett neu zu erstellen, dem Kunden ein früheres, besseres Ergebnis in höherer Qualität zur Verfügung zu stellen.
Echt? Ja echt… Nehmen wir ein Beispiel (der Importer soll sich ja auch lohnen): 500 Seiten bestehenden Content sollen neu in ein System kommen. Nehmen wir als Ausgangsbasis 500 Word-Dokumente mit Text, Bildern und Links, Verortung in der neuen Struktur und das vorgesehene Modul. Dann gehen wir bei einem – auf dem System geschulten – Redakteur von einer maximalen Bearbeitungszeit von 10 – 15 Minuten für die Neuerstellung der Seite aus, macht also was zwischen 80 und 125 Stunden und damit 10 – 15 Personentage. Da dies eine einfache Arbeit ist, reichen Hilfskräfte aus, um diesen Job zu erledigen.
Im Gegensatz dazu kostet der Importer sicherlich eine niedrige bis mittlere fünfstellige Summe, wenn alles automatisiert passieren soll. Trotzdem muss jede Seite ein paar Minuten überprüft und angepasst werden. Selbst bei 1.000 Seiten und mehr und auch bei internationalen Aufgabenstellungen bleibt die Rechnung deutlich auf der Seite der manuellen Übernahme, da die Kosten und das Risiko beim Importer bei Zunahme der Komplexität ebenfalls stark ansteigen. Dazu geht der aktuelle Trend generell weg von stark Content lastigen hin zu mehr emotional aufgeladenen Seiten. 1.000 Seiten über ein Unternehmen sind nicht zu warten, die Tochtergesellschaften in den Ländern wollen und werden sie nicht übersetzen und… tja, lesen wird sie auch niemand 😉
Und die Ausnahme von der Regel
Der Vollständigkeit halber: es gibt auch Ausnahmen, denn stark strukturierte Inhalte wie z.B. alte Pressemitteilungen können oftmals leichter importiert werden und liegen dazu noch in sehr großen Massen vor. Ob man mit diesen – redaktionell nie mehr anzufassenden – Inhalten das neue System dann belasten muss, ist von Fall zu Fall zu entscheiden.
Eine weitere Ausnahme können vielleicht Intranets und intern genutzte Wissensplattformen darstellen, die heute aber nicht Thema sind.
Guter Punkt Alex!
Es gilt immer abzuwägen, was dem Kunden auf den Nägeln brennt. Es muss ja einen Grund geben, wenn jemand freiwillig durch das „Tal der Tränen“ geht und seine CMS Infrastruktur austauscht, statt auf der bestehenden Plattform einen Design-Refresh oder funktionale Erweiterungen durchzuführen – konsequente Trennung von (strukturieren) Inhalten und Form mal vorausgesetzt.
Ist die bisherige Infrastruktur nicht mehr sicher / wartbar oder instabil – vielleicht ein gestorbenes Open Source Projekt oder ein im Merger untergegangenes Produkt? Dann ist klar, dass der Kunde möglichst schell auf eine neue Plattform umziehen will. Dabei alles komplett neu zu machen, dauert möglicherweise einfach zu lange. Dann gilt es entweder Prioritäten zu setzen und Mut zur Lücke zu beweisen oder ‚Augen zu und durch‘.
Geht es in erster Linie darum, mit anderer Usability / Funktionalität mehr Wirkung zu erzielen, dann ist oft ein schrittweises Abschalten / Ersetzen sinnvoller, als ein Big-Bang mit Migrationwehen.
Wie isst man einen Elefanten? In kleinen Stücken!
Kluge Menschen betrachten das Thema übrigens nicht am Ende, sondern zu Beginn des Life-Cycle, also bei der Auswahl des neuen CMS Produktes. Sie fragen den Hersteller, wie einfach und maschinenverständlich denn der Content aus dem System zu bekommen ist und was das System denn alles als Content betrachtet. Jedenfalls war eines meiner take-aways der letzten J.Boye Konferenz: „Before you enter into something, think of your exit strategy!“
– Bernd
Disclosure: Ich bin Produktmanager von onion.net, einem CMS Framework für individuelle Lösungen (welches Content als Schema validiertes XML speichert).