WordPress-Migrations-Fallstudie für Safer Moves
Veröffentlicht am 9. August 2026
Eine WordPress-Migrations-Fallstudie ist am nützlichsten, wenn sie zeigt, was zwischen dem fröhlichen Plan, „die Websites dieses Wochenende umzuziehen“, und dem Moment passiert ist, in dem jede Domain wieder korrekt ausgeliefert wird. In diesem mittleren Teil erwerben sich Migrationen ihren Ruf. Dateien, Datenbanken, DNS, SSL-Zertifikate, E-Mail-Einstellungen, Cronjobs, Caching und das Verhalten von Plugins können alle eine eigene Meinung haben.
Dieses Beispiel folgt einer kleinen Digitalagentur, die 18 WordPress-Websites aus einer überfüllten Shared-Hosting-Umgebung auf einen verwalteten Linux-Server umzieht. Ihre Ziele waren klar: die Seitengeschwindigkeit verbessern, jedem Kunden klarere Account-Grenzen geben, wiederkehrende Support-Tickets reduzieren und aufhören, jedes Update wie einen kleinen Produktionsvorfall zu behandeln.
Das Ergebnis war keine Magie. Es war ein strukturierter Umzug, ein kurzes Wartungsfenster für die am stärksten frequentierten Websites und eine bessere Art, den Server nach dem Go-live zu verwalten.
Der Ausgangspunkt: 18 Websites, zu viele Kompromisse
Die Agentur war nach und nach gewachsen. Neue Kunden-Websites wurden demselben Hosting-Account hinzugefügt, oft indem das Setup kopiert wurde, das beim letzten Mal funktioniert hatte, und Details später korrigiert wurden. Es war vertraut, aber nicht mehr komfortabel.
Ein Traffic-Spike auf einer E-Commerce-Website konnte sich auf nicht verwandte Broschüren-Websites auswirken. Staging-Kopien befanden sich an mehreren Orten. Backups existierten, obwohl niemand mit Sicherheit sagen konnte, welches Backup die exakt benötigte Website wiederherstellen würde. Die Agentur hatte außerdem nur eingeschränkte Transparenz bei CPU-, Speicher- und Festplattennutzung, sodass die Diagnose einer langsamen Website meist mit Rätselraten begann.
Der Hosting-Anbieter bot einen Migrationsservice an, aber die Agentur musste nach ihrem eigenen Zeitplan umziehen und die Kontrolle darüber behalten, wie Accounts, Zugriffe und Backups danach funktionieren würden. Diese Anforderung war wichtig. Bei einer Migration geht es nicht nur darum, eine Website auf einen anderen Server zu bringen. Sie ist eine Chance, die Setup-Entscheidungen nicht weiter zu wiederholen, die überhaupt erst für Reibung gesorgt haben.
WordPress-Migrations-Fallstudie: der Migrationsplan
Die Agentur teilte die Arbeit in drei Gruppen ein: Marketing-Websites mit wenig Traffic, inhaltsstarke Publisher-Websites und E-Commerce- oder Lead-Generierungs-Websites, bei denen selbst eine kurze Unterbrechung echtes Geld kosten konnte. Diese Kategorisierung bestimmte die Migrationsreihenfolge und den erforderlichen Prüfumfang.
Bevor irgendetwas kopiert wurde, erstellte das Team für jede Domain ein Inventar. Es umfasste die WordPress-Version, die PHP-Version, die Datenbankgröße, die Festplattennutzung, aktive Plugins, DNS-Einträge, den SSL-Status, geplante Aufgaben, E-Mail-Abhängigkeiten und externe Dienste wie Payment-Gateways oder Formular-Tools. Das war keine glamouröse Arbeit, verhinderte aber das klassische Problem, eine alte, aber notwendige Konfiguration erst zu entdecken, nachdem DNS bereits geändert wurde.
Sie legten auch Erfolgskriterien fest. Eine Migration galt erst dann als abgeschlossen, wenn die Startseite, wichtige Landingpages, Kontaktformulare, der Zugriff auf wp-admin, die Mediathek, geplante Aufgaben, HTTPS-Weiterleitungen und Fehlerprotokolle geprüft worden waren. Für E-Commerce-Websites umfasste die Checkliste außerdem Testbestellungen, transaktionale E-Mails, Account-Login und Bestandsaktualisierungen.
Auswahl des Ziel-Setups
Der neue Server verwendete separate Accounts für jeden Kunden, anstatt jede Website unter einem gemeinsam genutzten Systembenutzer zu platzieren. Das verbesserte die Isolation und machte es einfacher, Zugriff zu übergeben, ohne andere Kundenumgebungen offenzulegen.
Die Agentur entschied sich für ein Control Panel, weil der tägliche Betrieb sowohl für Entwickler als auch für Account-Manager praktikabel bleiben musste. Mit FASTPANEL konnten sie Websites erstellen, Datenbanken und SSL-Zertifikate verwalten, separate Accounts organisieren und die Nutzung von Serverressourcen an einem Ort überwachen. Das beseitigte nicht die Notwendigkeit technischer Urteilsfähigkeit, aber es ersparte viel unnötige Sucherei in voneinander getrennten Tools.
Zunächst hielten sie die PHP-Version an jeder bestehenden Website ausgerichtet. PHP während eines Umzugs zu aktualisieren kann sinnvoll sein, aber zwei große Änderungen zu kombinieren macht die Fehlersuche schwieriger. Das Team entschied sich dafür, zuerst zu migrieren, dann zu stabilisieren und Upgrades erst nach der Überprüfung der Plugin-Kompatibilität zu planen.
Dateien und Datenbanken kopieren, ohne alte Probleme mitzukopieren
Für jede Website erstellte das Team die Ziel-Website und die Datenbank, übertrug dann die WordPress-Dateien und importierte einen Datenbank-Export. Sie aktualisierten die Datenbank-Anmeldedaten in der Konfigurationsdatei und änderten umgebungsspezifische Werte sorgfältig.
Das wichtigste technische Risiko war nicht die Dateiübertragung. Es war die URL-Verarbeitung. Eine Website, die von einer temporären Zieladresse aus verschoben wird, kann falsche Links, Weiterleitungen oder serialisierte Daten entwickeln, wenn Search-and-Replace-Arbeiten unachtsam durchgeführt werden. Das Team verwendete eine Migrationsmethode, die WordPress-Datenstrukturen respektierte, und prüfte dann Seitenquelltext, interne Links, Bilder und Plugin-Einstellungen, anstatt anzunehmen, dass die neue Startseite ein Beweis dafür sei, dass alles funktionierte.
Sie prüften außerdem, was nicht mitumziehen sollte. Alte Cache-Ordner, ungenutzte Backup-Archive, Entwicklungsprotokolle und aufgegebene Plugins erhöhten den Speicherverbrauch, ohne der neuen Umgebung zu helfen. Das Entfernen davon reduzierte Unordnung, aber erst, nachdem ein separates Backup verifiziert worden war. Aufräumen ist nützlich. Aufzuräumen, bevor man einen Wiederherstellungspunkt hat, ist Optimismus mit Werkzeuggürtel.
Testen, bevor DNS die eigentliche Arbeit übernimmt
Jede migrierte Website wurde auf dem Zielserver getestet, bevor öffentliche DNS-Einträge geändert wurden. Die Agentur nutzte eine temporäre Zugriffsmethode, um zu bestätigen, dass die Website für interne Tester in die neue Umgebung aufgelöst wurde, während Besucher weiterhin den alten Host nutzten.
Diese Phase brachte vier Probleme ans Licht, deren Entdeckung nach dem Go-live unangenehm gewesen wäre. Eine Website hatte eine hartcodierte URL in einer Einstellung eines Page Builders. Eine andere war auf eine Mail-Konfiguration angewiesen, die an den früheren Host gebunden war. Bei einem Membership-Plugin musste der Zeitplan für seine Hintergrundaufgabe wiederhergestellt werden. Eine E-Commerce-Website hatte eine Callback-Einstellung des Payment-Gateways, die nur die alte Serveradresse erkannte.
Keines dieser Probleme war katastrophal. Genau darum geht es beim Testen vor dem Go-live. Ein guter Migrationsprozess verwandelt Überraschungen in Tickets, die bearbeitet werden können, bevor Kunden sie zu sehen bekommen.
Die Agentur testete Formulare mit echten Empfangspostfächern, nicht nur mit einer grünen Erfolgsmeldung auf der Website. Sie prüfte SSL-Zertifikate und erzwang HTTPS-Weiterleitungen. Sie überprüfte Server- und Anwendungsprotokolle auf Warnungen, die im Frontend nicht sichtbar waren. Bei den größten Websites verglich das Team eine Stichprobe von Datenbanktabellengrößen und Uploads-Verzeichnissen mit dem Quellserver, um unvollständige Übertragungen zu erkennen.
DNS-Umschaltung und das kurze Wartungsfenster
Bei Websites mit wenig Traffic änderte die Agentur DNS nach der Testfreigabe während der normalen Geschäftszeiten. Für E-Commerce-Websites wählte sie ein Abendfenster mit weniger Traffic und aktivierte kurz den Wartungsmodus, während ein finaler Datenbank-Export erfasst wurde.
Dieser letzte Datenbankschritt ist für dynamische Websites wichtig. Dateien ändern sich seltener, aber Bestellungen, Formulareinträge, Benutzerregistrierungen und Kommentare können jederzeit in die Datenbank geschrieben werden. Wenn die erste Kopie mehrere Stunden zuvor abgeschlossen wurde, verhindert eine abschließende Datenbank-Synchronisierung, dass diese neueren Datensätze zurückbleiben.
Das Team reduzierte nach Möglichkeit die DNS-Time-to-Live-Werte im Vorfeld der Umschaltung. Selbst dann rechnete es damit, dass einige Besucher kurzzeitig noch den alten Server erreichen würden, weil die DNS-Propagation kein Schalter ist, der überall gleichzeitig umgelegt wird. Der alte Hosting-Account blieb mehrere Tage lang als Sicherheitsnetz aktiv, wurde aber in einen kontrollierten Zustand versetzt, um widersprüchliche Änderungen zu vermeiden.
Keine Website verzeichnete längere Ausfallzeiten. Zwei Websites hatten nach dem Go-live kleinere Caching-Probleme, und ein Kontaktformular benötigte eine SMTP-Anpassung. Alles wurde innerhalb der ersten Stunde behoben, weil die Agentur Verantwortlichkeiten für das Monitoring zugewiesen hatte, anstatt anzunehmen, dass die Arbeit mit der DNS-Änderung beendet sei.
Was sich nach dem Umzug geändert hat
Die unmittelbare Verbesserung war Transparenz. Anstatt darauf zu warten, dass Kunden meldeten, eine Website fühle sich langsam an, konnte die Agentur Ressourcenaktivität sehen und Muster untersuchen. Separate Accounts machten es außerdem einfacher zu erkennen, welche Website Ressourcen verbrauchte, und den Kundenzugriff mit weniger Workarounds zu verwalten.
Die Migration legte eine operative Wahrheit offen: Leistungsverbesserungen kamen nicht nur vom neuen Server. Sie kamen durch die Korrektur veralteter PHP-Einstellungen, das Entfernen aufgegebener Plugins, die Überprüfung des Cache-Verhaltens und dadurch, dass stark nachgefragte Websites Raum zum Arbeiten bekamen, ohne mit jedem anderen Projekt konkurrieren zu müssen.
Die Agentur änderte außerdem ihre Support-Routine. Jede neue Kunden-Website erhält jetzt vom ersten Tag an einen dokumentierten Account, eine Backup-Richtlinie, einen Update-Prozess und eine Migrations-Checkliste. Diese Konsistenz spart mehr Zeit als jeder einzelne Befehl oder jedes einzelne Plugin.
Lehren, die sich für den eigenen Umzug mitzunehmen lohnen
Erstens: Behandeln Sie nicht alle WordPress-Websites gleich. Eine lokale Unternehmenswebsite mit fünf Seiten und ein Shop, der Bestellungen verarbeitet, benötigen unterschiedliche Umschaltpläne. Je dynamischer die Website, desto sorgfältiger müssen Sie abschließende Datenbankänderungen und Tests verwalten.
Zweitens: Ein Backup ist nur dann nützlich, wenn es wiederhergestellt werden kann. Verifizieren Sie Backups vor dem Migrationstag, halten Sie eine Rollback-Option verfügbar und legen Sie fest, wer die Entscheidung zur Rücknahme treffen darf, wenn etwas schiefgeht. Eine klare Rollback-Entscheidung ist ruhiger als eine improvisierte um Mitternacht.
Drittens: Vermeiden Sie es, nicht zusammenhängende Upgrades in die Migration hineinzupacken, es sei denn, es gibt einen klaren Grund. Neuer Server, neue PHP-Version, neues Theme und neue Caching-Schicht können zusammen funktionieren, aber sie vervielfachen auch die möglichen Ursachen eines Problems. Erst umziehen. Verbessern Sie bewusst, nachdem die neue Umgebung stabil ist.
Planen Sie schließlich die Arbeit nach der Umschaltung ein. Überwachen Sie Ressourcen, prüfen Sie Protokolle, testen Sie geschäftskritische Aktionen und halten Sie die alte Umgebung verfügbar, bis Sie sicher sind, dass sich Traffic und Daten korrekt verhalten. Eine erfolgreiche Migration ist nicht der Moment, in dem eine Domain auf eine neue IP-Adresse zeigt. Sie ist der Moment, in dem Ihr Team die Website mit mehr Sicherheit als zuvor verwalten kann.
Der beste nächste Schritt ist einfach: Erstellen Sie das Inventar, bevor Sie das Migrationsdatum festlegen. Sobald Sie wissen, wovon jede Website abhängt, wird der Umzug zu einem beherrschbaren Projekt statt zu einem nächtlichen Ratespiel.