So migrieren Sie Websites sicher

Veröffentlicht am 21. Juni 2026

Eine sichere Website-Migration beginnt, bevor irgendwelche Dateien verschoben werden. Wenn Sie wissen möchten, wie Sie Websites sicher migrieren, besteht die erste Aufgabe nicht darin, Daten zu kopieren - sondern darin, Unbekannte zu reduzieren. Wir prüfen den aktuellen Stack, frieren unnötige Änderungen ein, bestätigen, dass Backups tatsächlich wiederhergestellt werden können, und bauen einen Rollback-Pfad auf, bevor wir DNS anfassen. Das ist der Teil, den viele Teams überspringen, und später erzählen die Logs dieselbe Geschichte.

Migrationen scheitern aus banalen Gründen. Ein vergessener cron job schreibt weiter in die alte Datenbank. DNS wird umgeschaltet, bevor SSL bereit ist. Weiterleitungsregeln werden nur halb kopiert. Der Cache lässt die neue Website für eine Person gut aussehen und für alle anderen kaputt. Nichts davon ist dramatisch, aber es ist teuer. Eine sichere Migration besteht vor allem aus disziplinierter Reihenfolge.

So migrieren Sie Websites sicher ohne Ausfallzeit-Überraschungen

Die saubersten Migrationen beginnen mit einer Bestandsaufnahme. Sie müssen genau wissen, was umzieht, was sich während des Umzugs ändern kann und welche Abhängigkeiten außerhalb des Servers liegen. Das bedeutet Website-Dateien, Datenbanken, Medienspeicher, SSL-Zertifikate, DNS-Zonen, geplante Aufgaben, E-Mail-Routing, API-Integrationen, Payment-Callbacks und Firewall-Regeln. Wenn die Website ein CDN, externen Bildspeicher, Object Cache oder Drittanbieter-Suche verwendet, nehmen Sie diese ebenfalls auf.

Hier finden Teams die kleinen Fallen. Ein WooCommerce-Shop kann auf einen Payment Webhook angewiesen sein, der auf die alte IP zeigt. Eine SaaS-App kann Background-Worker auf einer zweiten Maschine haben. Eine Marketing-Website mag einfach sein, aber das Kontaktformular sendet über einen SMTP-Dienst, der durch den Server-Hostnamen eingeschränkt ist. Bei sicheren Migrationen geht es selten um die Homepage. Es geht um die Ränder.

Bevor Sie irgendetwas verschieben, entscheiden Sie, welche Art von Migration Sie durchführen. Ein gleichartiger Umzug von einem VPS zu einem anderen ist eine Risikostufe. Gleichzeitig von Shared Hosting zu Managed VPS zu wechseln, Control Panels zu ändern, PHP zu aktualisieren und den Webserver von Apache auf Nginx umzustellen, ist ein ganz anderes Kaliber. Sie können mehrere Änderungen gleichzeitig vornehmen, aber jede zusätzliche Variable verlangsamt die Fehlersuche. Trennen Sie nach Möglichkeit Infrastrukturänderungen von Anwendungsänderungen.

Beginnen Sie mit Backups, die Sie bereits getestet haben

Jeder Anbieter sagt, dass Backups existieren. Das ist schön, aber ein Backup ist nur dann nützlich, wenn es sauber und schnell genug für Ihr Wiederherstellungsziel wiederhergestellt werden kann. Erstellen Sie unmittelbar vor der Migration ein frisches Backup von Dateien und Datenbanken. Bewahren Sie außerdem eine Kopie außerhalb der Quellumgebung auf, damit Sie sich nicht darauf verlassen müssen, dass eine einzelne Plattform einen guten Tag hat.

Wenn die Website umsatzrelevant ist, führen Sie eine Testwiederherstellung in einer Staging-Umgebung durch. Öffnen Sie die wiederhergestellte Website, verifizieren Sie die Datenbankkonnektivität, prüfen Sie Dateiberechtigungen und stellen Sie sicher, dass Medien geladen werden. Wenn Sie nicht die gesamte Anwendung testen können, bestätigen Sie zumindest, dass das Backup-Archiv vollständig ist und der Datenbank-Dump lesbar ist. Das ist keine glamouröse Arbeit, aber das ist es auch nicht, der Buchhaltung zu erklären, warum die Bestellungen von letzter Nacht im Wald verschwunden sind.

Änderungen während des Migrationsfensters einfrieren

Inhaltsänderungen, Plugin-Installationen und Code-Deployments während der Migration erzeugen Split-Brain-Probleme. Ein System wird aktualisiert, das andere nicht, und nun ist niemand sicher, welche Version die echte ist. Legen Sie einen kurzen Änderungsstopp fest. Bei inhaltsreichen oder transaktionalen Websites verwenden Sie während der finalen Synchronisierung den Wartungsmodus oder versetzen kritische Teile in einen schreibgeschützten Zustand.

Planen Sie für E-Commerce, Buchungen oder nutzergenerierte Inhalte eine Delta-Synchronisierung. Kopieren Sie den Großteil der Dateien und Daten im Voraus und führen Sie dann während des Umschaltfensters eine finale Synchronisierung durch, um Änderungen in letzter Minute zu erfassen. So bleibt die Ausfallzeit gering, ohne Datenabweichungen zu riskieren.

Zielumgebung vor der Umschaltung aufbauen

Ein häufiger Fehler ist, den Zielserver wie eine leere Kiste zu behandeln, die später konfiguriert werden kann. Sichere Migration funktioniert genau andersherum. Die Zielumgebung sollte vor dem Wechsel bereit sein: Betriebssystem gepatcht, Web-Stack installiert, PHP-Version bestätigt, Datenbank optimiert, SSL vorbereitet, Backups geplant und Monitoring aktiviert.

Erfüllen Sie zuerst die Anforderungen der Anwendung und verbessern Sie dann vorsichtig. Wenn die alte Website auf PHP 7.4 läuft und die App nicht für PHP 8.2 zertifiziert ist, ist der Migrationstag nicht der Moment für Heldentum. Modernisieren können Sie, nachdem die Stabilität bestätigt ist. Erst Ruhe, dann Optimierung.

Berechtigungen und Eigentümerschaft verdienen besondere Aufmerksamkeit. Viele Vorfälle nach dem Muster „die Website wurde migriert, aber Uploads schlagen fehl“ sind nur falsche Benutzer-/Gruppen-Eigentümerschaft oder fehlende beschreibbare Pfade. Prüfen Sie außerdem cron jobs, Queue-Worker und geplante Aufgaben. Eine Website kann problemlos laden, während wichtige Hintergrundverarbeitung vor einer Stunde still und leise aufgehört hat.

Mit einer hosts-Datei oder temporären URL testen

Zeigen Sie Live-DNS nicht auf den neuen Server, bevor die Website dort geprüft wurde. Verwenden Sie einen hosts-Datei-Override oder eine temporäre Vorschau-Domain, um die Anwendung privat zu testen. Durchsuchen Sie wichtige Seiten, senden Sie Formulare ab, melden Sie sich als Admin an, geben Sie falls relevant eine Testbestellung auf und verifizieren Sie den E-Mail-Versand. Prüfen Sie Bilder, Suche, APIs, Admin-Aktionen und alles, was mit Sessions oder Caching zusammenhängt.

Schauen Sie über visuelle Prüfungen hinaus. Prüfen Sie Error-Logs, Webserver-Logs, PHP-FPM-Status, langsame Datenbankabfragen und Festplattennutzung. Bestätigen Sie, dass Weiterleitungen wie erwartet funktionieren. Stellen Sie sicher, dass kanonische URLs, robots-Regeln und Umgebungsvariablen korrekt sind. Es ist erstaunlich leicht, eine Produktionswebsite zu migrieren, an der noch ein noindex-Header aus der Staging-Umgebung hängt. Suchmaschinen sind in den denkbar schlechtesten Momenten gehorsam.

DNS-, TTL- und Umschaltplanung

Wenn Sie lernen, wie Sie Websites sicher migrieren, ist DNS der Bereich, in dem sich Vorbereitung auszahlt. Senken Sie die TTL für relevante DNS-Einträge rechtzeitig vor dem Migrationsfenster, idealerweise 24 bis 48 Stunden vorher. Das hilft Resolvern, schneller zu aktualisieren, wenn Sie die Website auf den neuen Server umschalten. Es garantiert keine sofortige globale Propagation, reduziert aber die Zeit, in der Benutzer noch am alten Standort landen können.

Aktualisieren Sie bei der Umschaltung nur das, was notwendig ist. In der Regel bedeutet das den A-Eintrag, vielleicht AAAA, und manchmal mailbezogene Einträge, wenn auch E-Mail umzieht. Achten Sie darauf, Website-Migration nicht mit E-Mail-Migration zu vermischen, sofern es keinen klaren Grund dafür gibt. Sie zu kombinieren vergrößert den Schadensradius. Die schönste Migration ist oft die, bei der weniger Dinge geändert wurden.

Lassen Sie den alten Server für eine sichere Überschneidungsphase weiterlaufen. Auch nach der DNS-Änderung werden einige Benutzer und Bots den alten Host noch eine Weile erreichen. Überwachen Sie während dieser Zeit die Access-Logs auf beiden Systemen. Wenn der alte Server noch relevanten Traffic erhält, halten Sie ihn verfügbar und lenken Sie Schreibaktivität, wenn möglich, sorgfältig, damit keine Daten verloren gehen.

Auf Caching- und SSL-Probleme achten

CDN-Caches, Anwendungscaches und lokaler Browser-Cache können nach der Migration Probleme verbergen. Leeren Sie, wo nötig. Wenn ein Full-Page-Cache im Einsatz ist, leeren Sie ihn nach der finalen Synchronisierung und nach der DNS-Umschaltung. Bestätigen Sie, dass der CDN-Origin aktualisiert ist, falls einer existiert.

SSL sollte bereit sein, bevor umgeschaltet wird, nicht danach. Installieren Sie Zertifikate in der neuen Umgebung, verifizieren Sie die vollständige Kette und testen Sie das Verhalten von HTTP zu HTTPS. Mixed-Content-Warnungen können erscheinen, wenn hartcodierte Asset-URLs noch auf die alte Domain oder das alte Protokoll zeigen. Das sind kleine Details, aber Benutzer bemerken das Schloss-Symbol schneller als Ihre sorgfältige Planung.

Weiterleitungen, SEO und Anwendungsintegrität

Wenn die Domain gleich bleibt, ist das SEO-Risiko geringer, aber technische Prüfungen sind trotzdem wichtig. Stellen Sie sicher, dass Weiterleitungen von HTTP zu HTTPS, von www zu non-www oder umgekehrt sowie alle alten Pfadzuordnungen genau wie erwartet funktionieren. Wenn sich die Domain ändert, verwenden Sie umfassend 301-Weiterleitungen und aktualisieren Sie Canonical-Tags, Sitemaps und interne Verweise.

Starten Sie möglichst nicht mit Weiterleitungsketten. Sie verlangsamen die Dinge und erzeugen Indexierungschaos. Prüfen Sie außerdem benutzerdefinierte Fehlerseiten, robots.txt, die XML-Sitemap-Generierung und strukturierte Daten, falls die Website darauf angewiesen ist. Migration bedeutet nicht nur „Website lädt“. Sie bedeutet „Website verhält sich unter normalen Bedingungen und in Randfällen korrekt“.

Testen Sie bei dynamischen Anwendungen Authentifizierung, Sessions und Berechtigungen mit echten Benutzerrollen. Admin kann funktionieren, während der Kunden-Login wegen Cookie-Scope, Session-Speicher oder Proxy-Headern fehlschlägt. Das ist besonders häufig hinter Load Balancern oder Reverse Proxys.

Der Rollback-Plan ist Teil der Migration

Eine Migration ist nur sicher, wenn eine Umkehr möglich ist. Definieren Sie Rollback-Bedingungen im Voraus. Zum Beispiel: anhaltende 5xx-Fehler, Checkout-Ausfall, defekter Login, starke Performance-Regression oder Datenabweichung. Definieren Sie außerdem, wer die Rollback-Entscheidung trifft und wie lange das Beobachtungsfenster nach der Umschaltung dauert.

Rollback sollte einfach genug sein, um unter Stress ausgeführt zu werden. Das bedeutet in der Regel, die alte Umgebung intakt zu halten, den alten Datenbankzustand nach Möglichkeit zu bewahren und DNS oder Traffic-Routing schnell zurückzustellen. Wenn Schreibvorgänge in der neuen Umgebung stattgefunden haben, benötigen Sie eine Richtlinie für die Datenabstimmung. Deshalb erfordern transaktionale Websites beim finalen Wechsel besondere Sorgfalt.

In den ersten 24 Stunden konsequent überwachen

Überwachen Sie nach der Umschaltung Uptime, Antwortzeit, CPU, Speicher, Disk-I/O, Datenbanklast, SSL-Gültigkeit, Queue-Tiefe und Backup-Jobs. Achten Sie auch auf nutzerseitige Signale: Bestellfluss, Kontaktformulare, erfolgreiche Logins und Fehlermeldungen. Eine Migration kann nach zehn Minuten gut aussehen und in Stunde drei scheitern, wenn geplante Jobs anlaufen oder der Cache abläuft.

Hier verdient sich Managed Support seinen Platz. Gutes Monitoring erkennt Ressourcenspitzen, fehlgeschlagene Dienste und Zertifikatsprobleme, bevor Kunden zu Ihrem Alarmsystem werden. Für Teams ohne große interne Ops-Tiefe ist diese ruhige operative Ebene wichtiger als ein weiteres Häkchen in einem Hosting-Plan.

Eine praktische Regel für sicherere Migrationen

Ändern Sie nicht alles, nur weil Sie endlich die Gelegenheit dazu haben. Erst umziehen, dann stabilisieren, dann verbessern. Diese Reihenfolge spart Zeit, auch wenn sie auf dem Papier langsamer wirkt. Wenn Sie Hilfe dabei benötigen, Websites sicher zu migrieren, sollte der richtige Hosting-Partner nicht nur beim Server selbst unterstützen können, sondern auch bei Backups, Monitoring, Rollback-Planung und den unangenehmen kleinen Randfällen, die erst nach Mitternacht auftauchen.

Eine gute Migration fühlt sich fast ereignislos an. Das ist das Ziel. Ruhige Logs, stabiler Traffic, funktionierende Formulare, keine mysteriösen cron-Katastrophen und ein Team, das nach der DNS-Umschaltung schlafen kann. Bei kodu.cloud ist das normalerweise der Standard, den wir anstreben - nicht auffällig, einfach unter Kontrolle.

Andres Saar Kundenbetreuungsingenieur