Migration von einem alten Enterprise-CMS, ohne SEO oder Uptime zu verlieren.

Niemand ersetzt ein fünfzehn Jahre altes CMS, weil die Technologie interessant ist. Du ersetzt es, weil jedes neue Feature jetzt Monate dauert, die Entwickler, die die ursprüngliche Architektur verstanden haben, längst weg sind und der Anbieter still und leise aufgehört hat, die laufende Version zu unterstützen. Was diese Migration von einem normalen Website-Relaunch unterscheidet, sind Umfang und Blast Radius: Die Domain trägt eineinhalb Jahrzehnte angesammelter Suchautorität, Dutzende interne Systeme lesen von ihr oder schreiben in sie, und eine einzige übersehene Redirect-Regel oder ein Staging-robots.txt-Tag, das versehentlich in Produktion landet, kann Jahre an Rankings innerhalb weniger Tage zunichtemachen. Nichts davon ist ein Grund, nicht zu migrieren. Es ist ein Grund, die Migration selbst als das eigentliche Projekt zu behandeln, nicht als Anhängsel an ein Redesign.

Drei Wege für den Cutover im Vergleich

Keine davon ist im Abstrakten die „richtige“ Wahl — die Entscheidung hängt davon ab, wie viel Toleranz die Organisation für eine lange Übergangsphase hat im Vergleich zu einem einzigen risikoreichen Cutover-Tag, nicht davon, was Google bevorzugt.

Warum die Redirect-Map die ganze Migration ist

Jede URL, die das alte CMS jemals indexiert hatte, braucht einen expliziten, individuellen Redirect zum nächstliegenden Äquivalent im neuen System — keine pauschale Regel, die alles auf die Startseite schickt. Googles eigene Hinweise zu Website-Umzügen sind hier eindeutig: Ein Redirect auf ein unpassendes oder zu allgemeines Ziel wird als Soft 404 behandelt, und die Seite verliert jede Ranking-Historie, die sie sich aufgebaut hatte. Bei einem so alten System ist die Redirect-Map selten eine saubere 1-zu-1-Sache — Seiten wurden über fünfzehn Jahre zusammengelegt, abgeschafft oder umstrukturiert, und jede davon braucht eine bewusste Entscheidung, keine automatisierte Vermutung.

Redirect-Ketten sind der zweithäufigste Fehler, und sie sind fast immer selbst verschuldet: eine Seite, die vor drei Jahren beim Rebranding umgeleitet wurde, dann letztes Jahr bei einem Plattform-Update noch einmal, bekommt jetzt bei dieser Migration einen dritten Redirect — drei Sprünge, bevor ein Besucher oder ein Crawler die echte Seite erreicht. Google folgt Ketten, aber jeder Sprung erhöht Latenz und Risiko, und eine Schleife irgendwo in der Kette (ein echter, gar nicht so seltener Copy-Paste-Fehler) macht die Seite einfach kaputt. Die Lösung ist mechanisch, aber nicht verhandelbar: Löse jeden Redirect vor der Migration zu seinem endgültigen Ziel auf, nicht durch die alte Kette.

Das Staging-Desaster: Wie ein einziges Noindex-Tag den Launch killt

Der häufigste Grund, warum eine gut geplante Migration trotzdem schiefgeht, hat nichts mit Inhalten oder Redirects zu tun. Eine Staging- oder Development-Umgebung trägt fast immer ein pauschales `Disallow: /` in der robots.txt oder ein seitenweites Noindex-Tag — genau damit Suchmaschinen die unfertige Kopie niemals crawlen. Wenn genau dieser Code am Cutover-Tag in Produktion geht — weil die Deploy-Pipeline die Staging-Konfiguration einfach mitkopiert —, geht die Sperre live mit. Google kann innerhalb weniger Tage auf ein neu entdecktes Noindex-Signal reagieren, und bis irgendjemand merkt, dass der organische Traffic eingebrochen ist, ist ein spürbarer Teil der Website schon aus dem Index verschwunden.

Die Absicherung ist langweilig, und genau deshalb funktioniert sie: Die Produktions-Deploy-Checkliste braucht einen expliziten, eigenen Schritt, der robots.txt und Meta-Robots-Tags auf der Live-Domain nach dem Launch prüft, bevor irgendjemand die Migration für abgeschlossen erklärt — nicht einen Schritt, der einfach annimmt, dass die Deploy-Pipeline das schon richtig gemacht hat. Behandle es genauso wie ein Pilot seine Preflight-Checkliste behandelt: nicht weil das Flugzeug normalerweise ein Problem hat, sondern weil es, in dem einen Fall, in dem es doch eins hat, am Boden nichts kostet und in der Luft alles.

Cutover ohne Downtime, in der Praxis

Die Strangler-Fig- und Blue-Green-Ansätze aus der Tabelle oben sind, wie große Migrationen Downtime tatsächlich vermeiden, und beide beruhen auf demselben Trick: Altes und neues System laufen gleichzeitig, und der Traffic wandert zwischen ihnen, ohne dass ein Besucher jemals eine Wartungsseite sieht. Ein Blue-Green-Cutover hält das neue System vollständig im Schatten live, prüft es gegen echte Traffic-Muster und kippt dann eine DNS- oder Load-Balancer-Einstellung, sobald das Vertrauen groß genug ist — das alte System bleibt dabei laufen und ist sofort erreichbar, falls ein Rollback nötig wird. Strangler Fig macht dasselbe in kleinerer Körnung: Einzelne Abschnitte oder Subdomains wechseln nacheinander, hinter einem Reverse Proxy, der jede Anfrage an das System routet, dem der jeweilige Pfad gerade gehört.

Das Detail, das am häufigsten übersehen wird, ist die DNS-TTL — die Cache-Dauer der DNS-Einträge der Domain muss Tage vor dem Cutover gesenkt werden, nicht am Tag selbst, denn eine TTL, die noch auf 24 Stunden steht, bedeutet, dass ein Teil der Besucher nach dem Wechsel noch einen ganzen Tag lang auf dem alten System landet — egal wie sauber der Cutover selbst war. Es ist eine Fünf-Minuten-Änderung, eine Woche früher gemacht, und sie zu überspringen ist einer der häufigeren Gründe, warum eine technisch erfolgreiche Migration trotzdem einen harten Launch-Tag hat.

Was wirklich schwankt, und wie lange

Eine gewisse Ranking-Bewegung während und direkt nach einer Migration ist normal und zu erwarten — Googles eigene Dokumentation zu Website-Umzügen sagt das direkt: Das System muss die neuen URLs neu crawlen und neu bewerten, und das braucht Zeit, selbst wenn jeder Redirect korrekt ist. Bei einer gut ausgeführten Migration — saubere 1-zu-1-Redirects, kein versehentliches Noindex, Sitemap aktualisiert und neu eingereicht — stabilisiert sich diese Schwankung normalerweise innerhalb weniger Wochen, nicht Monate. Eine Migration, die zwei Monate später immer noch sichtbar weniger organischen Traffic hat, hat fast immer einen der beiden oben genannten Fehler, keine mysteriöse algorithmische Abwertung; behandle ein Plateau an diesem Punkt als Debugging-Problem, nicht als etwas, das man aussitzt.

Es lohnt sich, diese Erwartung schon vor der Migration mit allen Beteiligten zu klären, nicht danach: Ein vorübergehender Einbruch in den ersten zwei bis drei Wochen ist kein Beweis dafür, dass etwas schiefgelaufen ist, und auf die Zahlen von Tag drei zu reagieren, indem man die Redirect-Strategie infrage stellt, richtet meistens mehr Schaden an als der Einbruch selbst.

Wie wir das in der Praxis angehen

Eine Migration dieser Größe beginnt mit einem Technical Audit des bestehenden Systems — jede indexierte URL, jede Integration, die vom CMS liest, jedes undokumentierte Verhalten, das sonst jemand mitten in der Migration auf die harte Tour entdeckt. Dieser Audit wird zur echten Redirect-Map und zum Cutover-Plan, nicht zu einer generischen Checkliste.

Der Wiederaufbau selbst wird meist als Website Upgrade geplant oder, wenn sich Marke und Informationsarchitektur zusammen mit der Plattform ändern, als vollständiges Redesign & Relaunch. So oder so: Monatliche Wartung in den Wochen direkt nach dem Cutover ist der Rahmen, in dem robots.txt-Check, Redirect-Monitoring und die oben beschriebene Ranking-Beobachtung tatsächlich stattfinden — das hier ist kein „starten und vergessen“-Projekt.

Quellen

Die Hinweise oben zu Redirects, robots.txt und Ranking-Schwankungen stammen von hier, geprüft im August 2026.

• Google Search Central — Site moves with URL changes ↗

  Ein Redirect auf eine unpassende oder zu allgemeine Seite (z. B. die Startseite) wird als Soft 404 behandelt und verliert die Ranking-Historie; eine gewisse vorübergehende Ranking-Schwankung während eines Umzugs ist zu erwarten, solange Google die neuen URLs neu crawlt und neu bewertet.

• Google Search Central — 301 redirects and Google Search ↗

  Hinweise zu Redirect-Ketten und -Schleifen sowie dazu, einen Redirect zu seinem endgültigen Ziel aufzulösen, statt mehrere Sprünge stehen zu lassen.

• Google Search Central — Introduction to robots.txt ↗

  Wie eine Disallow-Regel oder eine Noindex-Direktive Crawling und Indexierung steuert — der Mechanismus dahinter, wenn eine Staging-Sperre versehentlich in Produktion landet.

• McKinsey Digital — Tech debt: Reclaiming tech equity ↗

  Befragte Führungskräfte schätzen technische Schulden auf etwa 20 bis 40 Prozent des Werts ihres gesamten Technologiebestands vor Abschreibung — der zugrunde liegende Kostendruck, der eine Ablösung eines Legacy-Systems irgendwann unausweichlich macht.