Umzug zu einem neuen Hoster ohne Ausfall: Schritt für Schritt
Ein Hosting-Umzug ohne Ausfall gelingt, wenn der neue Server fertig eingerichtet und getestet ist, bevor ihn ein Besucher sieht. Dann ist die Umschaltung eine DNS-Änderung mit kurzer TTL, und der alte Server bleibt erreichbar, bis dort niemand mehr ankommt.
Kritisch sind bei einem Umzug die Minuten und Stunden nach der Umschaltung: wenn ein Teil der Besucher noch beim alten Server landet, das Zertifikat auf dem neuen fehlt, Mails plötzlich im Spam liegen oder eine Bestellung auf der falschen Datenbank gespeichert wird.
Die folgende Anleitung gilt für einen Umzug zwischen deutschen Anbietern wie IONOS, Strato, Mittwald, netcup, all-inkl oder Hetzner ebenso wie für den Wechsel von einem Paket auf einen eigenen Server. Wie sich Strato und Hetzner im Angebot unterscheiden, zeigt der Vergleich Hetzner und Strato. Warum der Standort der Daten über den Anbieter hinaus zählt, steht unter EU-Hosting: Mehr als nur Schrems II.
Bestandsaufnahme: was alles umzieht
Eine Website besteht selten nur aus Dateien und einer Datenbank. Bevor der neue Server bestellt wird, gehört alles auf eine Liste, was am alten Anbieter hängt:
Code, hochgeladene Dateien und Datenbanken, mit Größe und PHP-Version,
DNS-Einträge der Domain, vollständig exportiert, mit allen Einträgen über A und MX hinaus,
E-Mail-Postfächer, Weiterleitungen und Verteiler,
Cronjobs, Warteschlangen und Hintergrundprozesse,
Zertifikate, Firewall-Regeln, Zugänge für Dritte (Zahlungsanbieter, Schnittstellen mit IP-Freigabe),
Vertragsdaten: Kündigungsfrist, Laufzeitende, wer die Domain beim Registrar hält.
Der letzte Punkt entscheidet den Zeitplan. Ein Hostingpaket mit drei Monaten Kündigungsfrist zum Laufzeitende gibt Ihnen ein festes Datum, bis zu dem der alte Server laufen darf. Kündigen Sie erst, wenn der neue Betrieb seit einigen Tagen ohne Auffälligkeiten läuft.
Beim DNS-Export zählt Vollständigkeit. Ein TXT-Eintrag zur Domain-Bestätigung bei Google, ein DKIM-Schlüssel des Newsletter-Dienstes oder ein CNAME für das Kundenportal eines Dienstleisters fallen erst auf, wenn sie nach dem Umzug fehlen. Fragen Sie deshalb jeden Eintrag einzeln ab und vergleichen Sie mit der Oberfläche des alten Anbieters. Für DKIM brauchen Sie den Selektor, also den Namen vor ._domainkey. Er steht im Kopf jeder signierten Mail im Feld DKIM-Signature hinter s= oder in der Oberfläche des Mail- oder Newsletter-Dienstes; das Beispiel unten nimmt mail2024 an.
Wie man solche Bausteine von vornherein trennt, zeigt ein Einmalauftrag für eine D2C-Gründerin in München (Case Study von 2022): Domain mit Subdomains und Weiterleitungen über Route 53, Postfächer über WorkMail, Dateien über S3 und CloudFront, also vier AWS-Dienste mit je eigenem Zweck. Laut Case Study lässt sich so später ein Baustein ersetzen, ohne die anderen anzufassen. Für einen Umzug heißt das: Website und Postfächer können zu verschiedenen Terminen wechseln.
# Alle wichtigen Einträge der Domain abfragen
dig +noall +answer example.de A
dig +noall +answer www.example.de A
dig +noall +answer example.de MX
dig +noall +answer example.de TXT
dig +noall +answer mail2024._domainkey.example.de TXT # Selektor anpassen
dig +noall +answer _dmarc.example.de TXT
DNS vorbereiten: TTL rechtzeitig senken
Die TTL (Time to Live) eines DNS-Eintrags legt fest, wie lange Resolver bei Providern und in Firmennetzen die Antwort zwischenspeichern dürfen. Steht der A-Eintrag Ihrer Domain auf 86.400 Sekunden, also einem Tag, sehen manche Besucher die neue Adresse erst bis zu einen Tag nach der Umstellung.
Deshalb wird die TTL vorher gesenkt, auf 300 Sekunden. Der Zeitpunkt ergibt sich aus der alten TTL: Die Senkung muss mindestens eine volle alte TTL vor der Umschaltung passieren, sonst haben Resolver noch den alten, langen Wert im Speicher. Bei 86.400 Sekunden heißt das: spätestens einen Tag vorher, besser zwei.
Montag, 10 Uhr: TTL von A- und AAAA-Einträgen auf 300 Sekunden senken.
Dienstag, 10 Uhr: Die alte TTL von einem Tag ist abgelaufen, alle Resolver fragen nun alle fünf Minuten neu.
Mittwoch: Umschaltung. Nach rund fünf Minuten kommt der größte Teil der Besucher auf dem neuen Server an.
Auch nicht vorhandene Einträge werden zwischengespeichert: Wer vor dem Umzug eine Testadresse wie neu.example.de abfragt, bevor sie angelegt ist, bekommt eine negative Antwort, und auch die wird zwischengespeichert. Wie lange, legt der SOA-Eintrag der Zone fest (RFC 2308).
Die TTL der Nameserver-Delegation bei der Registry lässt sich dagegen nicht senken. Wenn mit dem Hoster auch der DNS-Anbieter wechselt, ziehen Sie die Zone deshalb zuerst um, mit identischen Einträgen, und stellen erst Tage später die Server-Adresse um.
Daten synchronisieren und den neuen Server testen
Der neue Server wird vollständig aufgebaut, bevor sich am DNS etwas ändert: gleiche PHP-Version oder eine bewusst gewählte neuere, gleiche Erweiterungen, Webserver-Konfiguration, Cronjobs, Warteschlangen. Dateien werden mit rsync übertragen, das bei der zweiten Übertragung nur noch Änderungen kopiert. Wo die hochgeladenen Dateien liegen, hängt vom System ab: bei WordPress unter wp-content/uploads, bei Laravel unter storage/app, bei Statamic meist im Ordner public/assets. Die Datenbank kommt als Dump hinüber. Beide Schritte laufen bis zur Umschaltung mehrmals, zuletzt unmittelbar davor.
# Abgleich der hochgeladenen Dateien, beliebig oft wiederholbar
# (Pfad je nach System, hier WordPress)
rsync -az --delete --info=progress2 alt:/var/www/example/wp-content/uploads/ /var/www/example/wp-content/uploads/
# Auf dem alten Server: Dump ohne Sperre der Tabellen (MySQL/MariaDB mit InnoDB)
mysqldump --single-transaction --routines --triggers --events example > example.sql
# Auf dem neuen Server: einspielen und Stichprobe zählen
mysql example < example.sql
mysql example -e "SELECT COUNT(*) FROM wp_posts;"
Mit der echten Domain testen, bevor Besucher kommen
Getestet wird über die echte Domain, ohne DNS-Änderung. Dafür trägt jeder Tester die neue IP-Adresse in die hosts-Datei seines Rechners ein, wie im Beispiel am Ende dieses Abschnitts. Der Browser ruft dann example.de auf und landet auf dem neuen Server, alle anderen Besucher weiter auf dem alten.
Bei diesem Test fällt eine Lücke auf: das TLS-Zertifikat. Let's Encrypt prüft beim HTTP-01-Verfahren über Port 80 der Domain, und die zeigt noch auf den alten Server. Für ein gültiges Zertifikat vor der Umschaltung gibt es drei Wege:
DNS-01: Ein TXT-Eintrag unter _acme-challenge belegt die Kontrolle über die Domain. Das geht unabhängig davon, wohin die Domain zeigt, braucht aber Zugriff auf die DNS-Verwaltung.
Prüfpfad weiterleiten: Der alte Server leitet nur den Pfad /.well-known/acme-challenge/ an den neuen weiter. Let's Encrypt folgt laut Dokumentation bis zu zehn Weiterleitungen, solange sie auf http oder https mit Port 80 oder 443 zeigen.
Zertifikat übernehmen: Das gültige Zertifikat samt privatem Schlüssel vom alten Server kopieren. Das überbrückt die Umschaltung; die automatische Verlängerung muss danach auf dem neuen Server eingerichtet werden.
Wer das Zertifikat erst unmittelbar nach der Umschaltung ausstellt, hat eine kurze Zeit mit Zertifikatsfehler.
Prüfen Sie im Testlauf außerdem die Wege, die nur selten laufen: Passwort vergessen, Rechnungs-PDF, Datei-Upload, Zahlungsabschluss im Testmodus. Für einen Probelauf ohne Echtdaten eignet sich das Vorgehen einer Staging-Umgebung, etwa damit der neue Server keine echten Mails an Kunden verschickt, solange er noch nicht live ist.
203.0.113.20 example.de
203.0.113.20 www.example.de
Die eigentliche Umschaltung
Die Umschaltung ist kurz, aber die Reihenfolge zählt. Bei einer reinen Informationsseite ohne Formulare reicht es, den A-Eintrag zu ändern. Sobald Besucher Daten schreiben (Bestellungen, Formulare, Logins, Kommentare), braucht es einen Plan für die Minuten, in denen beide Server Anfragen bekommen.
Letzter Abgleich der Dateien mit rsync, kurz vor dem Termin.
Alten Server für schreibende Vorgänge sperren: Wartungsseite nur für Formulare und Kasse oder die Anwendung in einen Nur-Lese-Modus setzen.
Datenbank ein letztes Mal exportieren, auf dem neuen Server einspielen, Zahl der Datensätze in den wichtigsten Tabellen vergleichen.
A- und AAAA-Einträge auf die neue Adresse ändern.
Den alten Webserver so umstellen, dass er alle Anfragen an den neuen weiterleitet (Reverse Proxy). Wer noch die alte Adresse im Speicher hat, landet so trotzdem auf dem neuen System.
Schritt 5 trennt eine kurze Störung von einem Umzug ohne Ausfall. Ohne Weiterleitung schreibt ein Teil der Besucher bis zum Ablauf der TTL in die alte Datenbank, und diese Bestellungen fehlen später auf dem neuen System. Mit Weiterleitung landet jede Anfrage in derselben Datenbank. Das klappt nur, wenn der Hoster einen eigenen Webserver mit Konfigurationszugriff bietet; bei Shared-Hosting-Paketen bleibt die Wartungsseite für schreibende Wege der sichere Ersatz.
Die Dauer hängt von der Datenmenge ab. Bei einer Datenbank mit einigen Hundert Megabyte dauern Export und Import wenige Minuten, die Nur-Lese-Phase ist entsprechend kurz; messen Sie die Zeit beim letzten Testlauf, dann kennen Sie sie für den Umzugstag. Bei vielen Gigabyte ist eine Replikation vom alten zum neuen Datenbankserver sinnvoll, die bis zur Umschaltung mitläuft.
Zur Umschaltung gehört ein Rückweg. Legen Sie vorher fest, bis zu welchem Zeitpunkt zurückgeschaltet wird und wer das entscheidet, etwa wenn die Zahlungsabwicklung auf dem neuen Server nach einer Stunde noch nicht sauber läuft. Der Rückweg ist dieselbe Umschaltung in umgekehrter Richtung: A-Eintrag zurück, die seit der Umschaltung neu entstandenen Daten vom neuen auf den alten Server übertragen. Weil die TTL noch kurz ist, wirkt auch das binnen Minuten. Den alten Server deshalb in den ersten Tagen nicht verändern, nicht neu aufsetzen und nicht kündigen.
Nach dem Umzug: Mails, Zertifikate, Cronjobs prüfen
Der Umzug ist abgeschlossen, wenn auch die unsichtbaren Teile laufen. Eine Prüfliste für die ersten 48 Stunden:
Mails der Anwendung: Ändert sich die IP-Adresse, von der Kontaktformular und Shop Mails verschicken, muss sie im SPF-Eintrag stehen. Fehlt sie, landen Bestellbestätigungen im Spam oder werden abgewiesen. Beim eigenen Server zusätzlich den Reverse-DNS-Eintrag (PTR) beim Hoster setzen und prüfen, ob DKIM signiert.
Postfächer: Ziehen die Postfächer mit um, werden die Inhalte per IMAP kopiert, bevor die MX-Einträge umgestellt werden, und ein zweites Mal danach, um Nachzügler mitzunehmen.
Zertifikate: Läuft die automatische Verlängerung auf dem neuen Server? Ein Testlauf der Verlängerung zeigt es sofort, nicht erst bei der ersten fälligen Verlängerung.
Cronjobs und Warteschlangen: Laufen sie auf dem neuen Server und nicht mehr auf dem alten? Doppelte Cronjobs verschicken Newsletter zweimal oder erzeugen doppelte Rechnungen.
Backups: Sichert der neue Server, und lässt sich eine Sicherung testweise zurückspielen?
Erst wenn auf dem alten Server nur noch Bot-Anfragen ankommen, wird er abgeschaltet. Die TTL der DNS-Einträge geht danach wieder auf einen längeren Wert, etwa eine Stunde.
Kurz beantwortet
Häufige Fragen
-
Die Umschaltung selbst dauert bei sauberer Vorbereitung Minuten. Die Vorbereitung braucht mehr Zeit: Inventur, Aufbau und Test des neuen Servers, TTL-Vorlauf von mindestens einem Tag. Als grobe Schätzung kommt eine Firmenwebsite mit CMS mit ein bis zwei Personentagen Arbeit aus, eine Webanwendung mit Schnittstellen und Warteschlangen braucht eine bis zwei Wochen Kalenderzeit, weil jede Schnittstelle einzeln getestet und mit ihrem Anbieter abgestimmt wird.
-
Bleiben die Mails beim alten Hoster, ändert sich nur der A-Eintrag der Website, die MX-Einträge bleiben. Ziehen sie mit, werden die Postfächer vor und nach der MX-Umstellung per IMAP kopiert.
-
Für eine Website ohne Formulare nicht. Sobald Besucher Daten schreiben, braucht es eine kurze Phase, in der der alte Server nichts mehr speichert, oder eine Weiterleitung vom alten zum neuen Server. Legen Sie diese Phase in eine ruhige Zeit und kündigen Sie sie bei Bedarf an.
Umzug ohne Unterbrechung planen
Inventur, Aufbau, Umschaltung auf Server in Deutschland und der Betrieb danach: Mit dieser Liste planen wir Ihren Umzug Schritt für Schritt.
Nachweise
Quellen und Stand
Stand: 10.11.2026, Angaben geprüft am 02.11.2026. TTL und negatives Caching laut RFC 1035 und RFC 2308, Prüfverfahren und Weiterleitungen für Zertifikate laut Let's Encrypt, Angaben zum AWS-Aufbau laut Case Study. Die Dauer in der FAQ ist unsere Schätzung, die IP-Adressen stammen aus dem Dokumentationsbereich nach RFC 5737.
Artikel teilen