So migrieren Sie einen Website-Server ohne Ausfallzeiten

Veröffentlicht am 15. Juli 2026

Beginnen Sie die Migration mit einem vollständigen, wiederherstellbaren Backup und einem schriftlichen Umschaltplan. Das ist die sicherste Antwort auf die Frage, wie man eine Website-Server-Infrastruktur migriert, ohne aus einem Routineumzug einen Ausfall zu machen. Ihr neuer Server sollte aufgebaut, abgesichert und getestet sein, bevor DNS irgendwelche Besucher dorthin leitet. Der alte Server bleibt online, bis die neue Umgebung reale Prüfungen bestanden hat.

Eine Servermigration ist mehr als das Kopieren von Website-Dateien. Die Website, die Datenbank, geplante Aufgaben, Mail-Routing, SSL-Zertifikate, die Laufzeitumgebung der Anwendung, das Cache-Verhalten, DNS-Einträge und Firewall-Regeln können alle Teil des Dienstes sein. Wenn nur eine kleine Abhängigkeit fehlt, kann eine Website auf der Startseite gut aussehen, während Checkout-E-Mails, Formulare oder Hintergrundjobs stillschweigend fehlschlagen. Kein besonders glamouröser Fehler, aber trotzdem ein kostspieliger.

Ordnen Sie den aktuellen Server zu, bevor Sie ihn verschieben

Beginnen Sie mit einer Bestandsaufnahme dessen, was tatsächlich läuft. Verlassen Sie sich nicht nur auf das, was das Hosting-Control-Panel anzeigt. Prüfen Sie das Document Root, die Anwendungsversion, Datenbank-Engine und -Version, PHP- oder Node.js-Einstellungen, Cronjobs, Queue-Worker, Speicherpfade, Weiterleitungen, Umgebungsvariablen und die Konfiguration für ausgehende E-Mails.

Identifizieren Sie bei einer Business-Website auch alles außerhalb der Hauptdomain. Dazu können Subdomains, Staging-Sites, API-Endpunkte, Zahlungs-Callbacks, Objektspeicher, externe E-Mail-Anbieter, Analytics-Skripte und zur Verifizierung verwendete DNS-Einträge gehören. Wenn der Server E-Mails direkt versendet, dokumentieren Sie seine Sende-IP, die Reverse-DNS-Konfiguration sowie SPF-, DKIM- und DMARC-Einträge. E-Mail ist oft das Letzte, was auffällt, und das Erste, worüber sich Kunden beschweren.

Dokumentieren Sie auch die Ressourcennutzung des aktuellen Servers. Prüfen Sie CPU-Last, Arbeitsspeichernutzung, Speicherplatz, Datenbankgröße, Traffic-Muster und Fehlerprotokolle. So erkennen Sie, ob der neue VPS oder dedizierte Server korrekt dimensioniert ist. Eine Migration ist ein guter Moment, um eine zu kleine Festplatte, eine veraltete PHP-Version oder einen Server hinter sich zu lassen, der bislang hauptsächlich dank Optimismus überlebt hat.

Bereiten Sie zuerst die neue Umgebung vor

Stellen Sie den Zielserver bereit, bevor Sie Produktionsdaten kopieren. Spielen Sie Betriebssystem-Updates ein, richten Sie eingeschränkten administrativen Zugriff ein, konfigurieren Sie die Firewall und installieren Sie nur die Dienste, die die Website benötigt. Verwenden Sie nach Möglichkeit SSH-Schlüssel statt Zugriff nur per Passwort. Deaktivieren Sie unnötige Dienste und stellen Sie sicher, dass automatische Sicherheitsupdates zu Ihrer Betriebsrichtlinie passen.

Passen Sie die Anwendungsanforderungen sorgfältig an. Eine Website, die von PHP 7.4 auf PHP 8.3 oder von MySQL auf eine neuere MariaDB-Version umzieht, benötigt möglicherweise Codeänderungen, bevor sie sich korrekt verhält. Dasselbe gilt für die Webserver-Konfiguration. Apache-Rewrite-Regeln, Nginx-Standorte, Dateiberechtigungen und PHP-Erweiterungen lassen sich nicht immer eins zu eins übertragen.

Richten Sie Monitoring vor der Umschaltung ein, nicht erst nach einem Vorfall. Überwachen Sie Verfügbarkeit, Antwortzeit, CPU, Arbeitsspeicher, Festplattenauslastung, SSL-Ablauf und wichtige Service-Ports. Bei Anwendungen mit Hintergrundverarbeitung sollten Sie auch Queue-Tiefe und fehlgeschlagene Jobs überwachen. Mit verwalteter Infrastruktur und eingerichtetem Monitoring erzählen die Logs jetzt dieselbe Geschichte, statt Sie raten zu lassen, nachdem Besucher ein Problem melden.

Sichern Sie für die Wiederherstellung, nicht nur fürs gute Gefühl

Erstellen Sie unmittelbar vor dem Migrationsfenster ein frisches Backup. Es sollte Website-Dateien, Datenbanken, Konfigurationsdateien, von Benutzern hochgeladene Dateien und alle außerhalb des Web-Roots gespeicherten Anwendungsgeheimnisse enthalten. Vergewissern Sie sich, dass sich das Backup an einem separaten Ort wiederherstellen lässt. Ein Backup, das nie getestet wurde, ist ein hoffnungsvolles Archiv, kein Wiederherstellungsplan.

Verwenden Sie bei Datenbanken einen konsistenten Export. Große oder aktive Datenbanken erfordern möglicherweise eine besondere Handhabung, damit keine Daten kopiert werden, während sie sich ändern. Je nach Datenbank und Anwendung können Sie ein Wartungsfenster, einen Nur-Lese-Modus, Replikation oder eine abschließende inkrementelle Synchronisierung verwenden. E-Commerce-Shops, Buchungssysteme, SaaS-Produkte und Mitgliederseiten benötigen besondere Sorgfalt, weil Bestellungen und Kontoänderungen jede Minute eingehen können.

Lassen Sie den ursprünglichen Server während des Umzugs unverändert. Kündigen Sie ihn nicht und löschen Sie keine Daten, sobald Dateien am Ziel erscheinen. Wenn Sie die alte Umgebung beibehalten, haben Sie einen sauberen Rollback-Pfad, falls nach der Umschaltung eine versteckte Abhängigkeit auftaucht.

Übertragen Sie Dateien und Datenbanken stufenweise

Kopieren Sie den initialen Datensatz, während die bestehende Website live bleibt. Sichere Dateiübertragungstools wie rsync über SSH sind nützlich, weil sie bei einem späteren letzten Durchgang nur geänderte Dateien synchronisieren können. Importieren Sie bei Datenbanken den initialen Dump in den neuen Server und testen Sie dann die Anwendung dagegen mit einem temporären Hostnamen oder einer lokalen Hosts-Datei-Überschreibung.

Vermeiden Sie es, nur die Startseite zu testen. Melden Sie sich als Administrator und als normaler Benutzer an. Senden Sie ein Kontaktformular ab, setzen Sie ein Passwort zurück, laden Sie eine Datei hoch, tätigen Sie gegebenenfalls einen Testkauf, prüfen Sie Transaktions-E-Mails und bestätigen Sie, dass geplante Aufgaben ausgeführt werden. Prüfen Sie während des Tests die Anwendungslogs und die Webserver-Fehlerprotokolle. Eine erfolgreiche HTTP-200-Antwort ist kein Beweis dafür, dass der Dienst gesund ist.

Wenn Sie gleichzeitig die Serverarchitektur ändern, trennen Sie die Änderungen nach Möglichkeit voneinander. Zum Beispiel ist der Umzug auf einen neuen VPS schon genug Arbeit, ohne zusätzlich an einem Abend die Datenbank neu zu gestalten, die Caching-Schicht zu ersetzen und das Anwendungs-Framework zu aktualisieren. Getrennte Projekte machen Fehler leichter zu diagnostizieren und zurückzurollen.

Senken Sie die DNS-TTL vor der Umschaltung

Bei DNS kann eine technisch erfolgreiche Migration für Besucher verwirrend werden. Reduzieren Sie die TTL für die relevanten A-, AAAA-, CNAME- und mailbezogenen Einträge 24 bis 48 Stunden vor der geplanten Umschaltung. Eine niedrigere TTL veranlasst Resolver dazu, Einträge schneller zu aktualisieren, sobald Sie die Domain auf den neuen Server zeigen lassen.

Das garantiert nicht, dass jeder Resolver sofort aktualisiert. Einige Netzwerke cachen länger als angefordert, und Benutzer können lokales DNS-Caching haben. Planen Sie für eine Übergangszeit, in der ein kleiner Teil des Traffics noch den alten Server erreichen kann. Wenn die Website veränderliche Daten annimmt, brauchen Sie eine Strategie für diese Überschneidung. Ein Wartungsmodus während der finalen Synchronisierung ist oft sicherer, als neue Bestellungen auf zwei getrennten Servern anzunehmen.

Ändern Sie Nameserver nicht, es sei denn, es gibt auch einen Grund, das DNS-Hosting zu verlagern. Das Ändern autoritativer Nameserver fügt eine weitere Ebene der Propagierung und mehr zu prüfende Einträge hinzu. Halten Sie die Migration dort langweilig, wo es möglich ist. Langweilige Infrastruktur ist in der Regel gesunde Infrastruktur.

Führen Sie die finale Synchronisierung aus und schalten Sie den Traffic um

Versetzen Sie die Anwendung zum vereinbarten Umschaltzeitpunkt in den Wartungsmodus, wenn sie Kundendaten schreibt. Stoppen Sie Queue-Worker und geplante Aufgaben auf dem alten Server, damit sie dieselbe Aufgabe nicht zweimal verarbeiten können. Führen Sie die finale Dateisynchronisierung und den Datenbankexport/-import aus und aktualisieren Sie dann die Zielkonfiguration mit den Zugangsdaten der Produktionsdatenbank, Anwendungsschlüsseln und den korrekten URLs.

Aktivieren Sie die Anwendung auf dem neuen Server und aktualisieren Sie DNS auf seine IP-Adresse. Bestätigen Sie, dass das SSL-Zertifikat installiert ist und HTTP korrekt auf HTTPS umleitet. Wenn ein Load Balancer, CDN oder Proxy vor der Website sitzt, aktualisieren Sie dessen Origin-Konfiguration und prüfen Sie, ob er die Health Checks des neuen Servers erkennt.

Beobachten Sie während der Propagierung beide Server. Der neue Server sollte eingehende Anfragen zeigen, während der alte Server stetig weniger Traffic erhalten sollte. Prüfen Sie 404-, 500- und Berechtigungsfehler sowie anwendungsspezifische Warnmeldungen. Behalten Sie die Ressourcennutzung im Blick, denn ein neuer Server kann sich unter realem Traffic anders verhalten als im Test.

Validieren Sie den Dienst nach der Migration

Sobald Traffic in der neuen Umgebung ankommt, führen Sie eine gezielte Produktionsprüfung durch. Bestätigen Sie, dass die Hauptseiten laden, Benutzer sich authentifizieren können, Formulare funktionieren, Zahlungs- oder Buchungsabläufe funktionieren, Dashboards aktuelle Daten anzeigen und hochgeladene Dateien zugänglich sind. Testen Sie nach Möglichkeit aus mehr als einem Netzwerk, da Ihr eigener Computer möglicherweise noch DNS im Cache hat.

Prüfen Sie geplante Aktivitäten in den nächsten mehreren Stunden. Cronjobs, Backups, Verlängerungen, Berichte, Queue-Worker und Webhook-Empfänger machen Migrationsprobleme häufig erst sichtbar, nachdem die erste Validierung bestanden wurde. Prüfen Sie auch Mail-Logs und Zustellberichte. Wenn die Website einen entfernten SMTP-Dienst verwendet, bestätigen Sie, dass die IP oder der Hostname des neuen Servers autorisiert ist.

Lassen Sie den alten Server mindestens 48 bis 72 Stunden verfügbar, bei komplexen Anwendungen oder langsamen DNS-Umgebungen länger. Bewahren Sie in diesem Zeitraum Backups von beiden Seiten auf und nehmen Sie keine nicht zusammenhängenden Konfigurationsänderungen vor. Sobald das Monitoring sauber ist, der Traffic stabil ist und das Rollback-Fenster verstrichen ist, nehmen Sie den alten Server sicher außer Betrieb.

Wissen, wann Sie verwaltete Hilfe nutzen sollten

Eine einfache Broschüren-Website kann mit sorgfältiger Vorbereitung und einem kurzen Wartungsfenster normalerweise umziehen. Ein Shop mit hohem Traffic, ein Agenturportfolio mit vielen Kundenseiten, eine SaaS-Plattform oder ein Server mit benutzerdefinierten Diensten verdient einen kontrollierteren Plan. Datenbankreplikation, gestufte Releases, Traffic-Draining und aktives Monitoring senken das Risiko, brauchen aber auch erfahrene Hände.

kodu.cloud kann bei der operativen Seite einer Migration helfen, von der Vorbereitung des Zielservers und Backups bis hin zu Monitoring und Validierung. Das Ziel ist nicht, den Prozess geheimnisvoll zu machen. Es geht darum sicherzustellen, dass jemand die Infrastruktur im Blick behält, während Sie das Geschäft am Laufen halten.

Eine gute Migration endet leise: Besucher nutzen die Website, geplante Jobs laufen, Backups werden abgeschlossen, und niemand muss eine nervöse Nachricht an alle senden. Behalten Sie den Plan, das Backup und den alten Server, bis die Belege zeigen, dass der Dienst wieder ruhig läuft.

Andres Saar Customer Care Engineer