Migration & Wartung

Jede Migration beginnt mit einem Inventar. Wir ziehen die Liste aller Adressen aus Sitemap, Serverlogs und Analysedaten, erfassen Inhaltstypen, Medien, Formulare, Benutzerkonten und alles, was an Drittsystemen hängt. Daraus entsteht eine Zuordnung vom alten auf das neue Modell, Feld für Feld.

Danach folgt eine Testmigration auf einer separaten Umgebung. Erst dort zeigt sich, welche Zeichensätze kippen, welche Bilder ihre Verknüpfung verlieren und welche Sonderfälle im Altsystem nie dokumentiert wurden. Dieser Durchlauf wird so oft wiederholt, bis das Ergebnis stimmt, denn die eigentliche Umschaltung soll keine Überraschungen mehr enthalten.

Vor dem Wechsel senken wir die TTL der DNS-Einträge, frieren die Redaktion kurz ein, spielen die letzten Inhalte nach und schalten um. Direkt danach werden Weiterleitungen, Formularversand, Suchfunktion, Zahlungs- und Versandschnittstellen sowie die Indexierbarkeit geprüft. Das alte System bleibt erreichbar, bis der neue Stand stabil läuft, und die letzte Sicherung des Altsystems bleibt archiviert.

Ein Systemwechsel steht meistens an, wenn der Hersteller den Support einstellt, die Lizenzkosten in keinem Verhältnis mehr zum Nutzen stehen oder die Redaktion mit dem Backend nicht mehr arbeiten kann. Der Wechsel von TYPO3 zu WordPress fällt häufig in diese Kategorie. Ein Serverumzug wird nötig, wenn das Hosting aktuelle PHP- oder Datenbankversionen nicht mehr mitträgt, die Antwortzeiten nicht stimmen oder Daten aus rechtlichen Gründen in einem bestimmten Land liegen sollen.

Wartung ist der unspektakuläre Teil: Updates von Kern, Themes und Erweiterungen, Prüfung der Backups, Erneuerung von Zertifikaten, Überwachung der Erreichbarkeit, Kontrolle der Fehlerprotokolle. Ohne diesen Takt wird jede Aktualisierung irgendwann zum eigenen Projekt.

Eine Migration ersetzt keinen Relaunch. Wenn Struktur, Navigation und Inhalte grundsätzlich nicht mehr passen, nimmt ein reiner Umzug die Probleme mit auf das neue System. Dann ist der Neuaufbau der ehrlichere Weg, mit der Migration als einem Arbeitsschritt darin.

Der häufigste Schaden bei einem Umzug entsteht durch verlorene Adressen. Jede alte URL braucht ein Ziel, und zwar eine dauerhafte Weiterleitung mit Status 301 auf die inhaltlich passende neue Seite, nicht pauschal auf die Startseite. Ketten aus mehreren Weiterleitungen lösen wir auf, weil sie Ladezeit kosten und Signale verwässern.

Nach der Umschaltung gehören eine neue Sitemap, die Kontrolle der robots.txt und die Prüfung auf versehentlich gesetzte noindex-Angaben dazu. Solche Angaben stammen oft noch aus der Testumgebung und sind der Klassiker unter den stillen Fehlern. Interne Verlinkung, kanonische Adressen und bei mehrsprachigen Seiten die hreflang-Angaben werden ebenfalls neu gesetzt.

In den Wochen danach beobachten wir Indexierung, Serverfehler und die Protokolle auf 404-Aufrufe, die im Inventar gefehlt haben. Für den laufenden Betrieb legen wir einen festen Wartungstakt fest, mit Updates über Staging, getrennt gespeicherten Backups und einem Rückweg, der einmal geprobt wurde.