Server-Migration: So ziehst du ohne Ausfall auf einen neuen Host um

Warum eine Migration gut geplant sein will

Ein schlecht geplanter Server-Umzug endet mit downtime, kaputten Links, fehlenden E-Mails und einem Wochenende, das du stattdessen mit firefighting verbringst. Das muss nicht sein.

Der kritische Punkt bei jeder Migration: der DNS-TTL. Solange deine alte DNS-Konfiguration noch in den Caches der Welt liegt, zeigen einige Besucher noch auf den alten Server — während andere bereits auf dem neuen landen. Das erzeugt Inkonsistenz: jemand bestellt, aber die Bestätigung kommt nicht an. Ein Formular wird zweimal abgeschickt. Bilder fehlen.

Mit der richtigen Sequenz — erst alles auf dem neuen Server verifizieren, dann DNS umstellen, dann den alten Server abschalten — vermeidest du all das.

Vorbereitung: Was du auf dem neuen Host brauchst

Bevor du irgendetwas umstellst, richte den neuen Server vollständig ein. Das bedeutet:

• Webserver konfiguriert — Apache/Nginx mit denselben VHost-Regeln wie auf dem alten Server
• PHP-Version passend — Prüfe die aktuelle PHP-Version auf dem alten Server mit php -v
• Datenbank importiert — MySQL/PostgreSQL Dump eingespielt, Zugangsdaten angepasst
• SSL-Zertifikat installiert — Let's Encrypt oder bestehendes Zertifikat übertragen
• Cronjobs eingerichtet — Alle automatisierten Tasks auf dem neuen Server aktiv
• E-Mail-Weiterleitungen konfiguriert — Postfächer auf dem neuen Server angelegt

sudo nano /etc/hosts
# Füge hinzu:
# 123.456.78.90  www.deine-domain.de
# 123.456.78.90  deine-domain.de

Schritt 1: Vollständiger Datenexport vom alten Server

Der erste Schritt: alles exportieren. Files, Datenbank, E-Mails, Konfigurationen — nichts darf auf dem alten Server bleiben, das nicht dokumentiert ist.

Dateien per rsync übertragen

rsync ist das Mittel der Wahl für große Dateimengen. Es überträgt inkrementell, ist resumable, und zeigt Fortschritt:

# Trockentest (was würde übertragen werden):
rsync -avzn --delete /var/www/html/ user@neuer-server:/var/www/html/

# Tatsächliche Übertragung (inkrementell, resumable):
rsync -avz --delete /var/www/html/ user@neuer-server:/var/www/html/

# Nur bestimmte Verzeichnisse:
rsync -avz /var/www/html/wp-content/ user@neuer-server:/var/www/html/wp-content/
rsync -avz /var/www/html/media/ user@neuer-server:/var/www/html/media/

Datenbank exportieren und importieren

MySQL-Dump auf dem alten Server erstellen, auf den neuen übertragen und einspielen:

# Export (alter Server):
mysqldump -u db_user -p --single-transaction --quick db_name > db_dump.sql
gzip db_dump.sql

# Auf neuem Server importieren:
gunzip < db_dump.sql.gz | mysql -u db_user -p db_name

# Oder direkt via Pipe (kein Zwischenspeicher):
mysqldump -u db_user -p db_name | ssh user@neuer-server "mysql -u db_user -p db_name"

Schritt 2: DNS-TTL vorbereiten

Mindestens 48 Stunden bevor du umstellst, setze die DNS-TTL auf den niedrigsten möglichen Wert (meist 300 Sekunden = 5 Minuten). Das verkürzt die Propagationszeit nach der Umstellung:

# Vor der Migration: TTL auf 300 setzen
# A-Record TTL: 300

# Nach der Migration: TTL zurück auf 3600 oder höher
# Das reduziert DNS-Queries an deinen Server

Warte nach dem TTL-Update die alte TTL-Dauer ab (z.B. 24 Stunden, wenn sie vorher auf 86400 stand). Erst dann stellst du die DNS-Records um. Andernfalls cached die halbe Welt noch den alten Wert und du bekommst eine verlängerte Split-Brain-Phase.

Schritt 3: SSL-Zertifikat umziehen

Wenn du Let's Encrypt nutzt: auf dem neuen Server einfach neu ausstellen — kein Aufwand. Wenn du ein kommerzielles Zertifikat hast (Wildcard, Extended Validation), brauchst du den Private Key und das Zertifikat+Paket:

# Alten Server: Key und Zertifikate sichern
sudo tar -czf ssl-backup.tar.gz /etc/letsencrypt/
sudo tar -czf ssl-backup.tar.gz /etc/ssl/private/ /etc/ssl/certs/

# Auf neuem Server entpacken und Webserver neu starten
sudo tar -xzf ssl-backup.tar.gz -C /
sudo nginx -t && sudo systemctl reload nginx

Schritt 4: Testen auf dem neuen Server

Bevor du irgendetwas in DNS umstellst, verifiziere everything auf dem neuen Server funktioniert:

Schritt 5: DNS umstellen

Jetzt der eigentliche switch: ändere den A-Record auf die neue Server-IP. Nutze direkt das DNS-Panel deines Registrars (nicht ein intermediate DNS-Service — das fügt nur eine Schicht hinzu, die bei Problemen verwirrt):

# Prüfe aktuellen DNS-Status vor der Umstellung:
dig A deine-domain.de +short
# Sollte aktuell noch auf alte IP zeigen

# Nach der Umstellung prüfen:
dig A deine-domain.de @8.8.8.8 +short
# Sollte neue IP zeigen

# Für mehrere Subdomains:
dig A www.deine-domain.de +short
dig A mail.deine-domain.de +short
dig A api.deine-domain.de +short

Bei MX-Records: diese zeigen typischerweise auf den Mailserver-Hostnamen, nicht direkt auf die Server-IP. Falls der Mailserver auf demselben Server läuft, stelle sicher, dass der MX-Record auf den A-Record des neuen Servers zeigt.

Schritt 6: Post-Migration-Verifikation

Nach der DNS-Umstellung — und nach Ablauf der propagierten TTL — checke systematisch:

• Globaler Check: Nutze what's my dns, um zu sehen, welche Nameserver worldwide den neuen A-Record ausliefern. Nach 24 Stunden sollte >90% der Checks die neue IP zeigen.
• SSL-Check: openssl s_client -connect deine-domain.de:443 -servername deine-domain.de </dev/null 2>/dev/null | openssl x509 -noout -dates
• HTTP-Statuscodes: Prüfe die wichtigsten Seiten auf 200 OK, keine 404 oder 500
• E-Mails testen: Sende eine Test-Mail, prüfe ob sie ankommt und ob autoreply funktioniert
• Logs prüfen: Nginx/Apache Error-Logs auf dem neuen Server checken: sudo tail -50 /var/log/nginx/error.log

Schritt 7: Alten Server nicht sofort kappen

Halte den alten Server mindestens 14 Tage parallel. Während der DNS-Propagation landen immer noch einige Requests auf dem alten Server — diese Besucher sehen sonst einen Fehler. Nach 2 Wochen sind 99,9% aller DNS-Caches auf dem neuen Server:

# 14 Tage nach Migration: prüfe, wie viel Traffic noch auf altem Server ankommt
# Wenn <1% (typisch nach 2 Wochen): sicher abschalten

# Vor dem Abschalten: nochmal Everything sichern
sudo tar -czf final-backup.tar.gz /var/www/ /etc/nginx/ /etc/php/
# → Das ist dein Rettungsnetz, falls du etwas übersehen hast

WordPress-Migration: Besonderheiten

WordPress hat ein paar Fallstricke, die bei normalen HTML-Seiten nicht existieren:

Fazit: Migration ist kein Hexenwerk

Server-Migration ist ein strukturiertes Projekt, kein Glücksspiel. Die kritischen Regeln:

• TTL runter, bevor du anfängst — 48h vorher, nicht am Tag der Migration
• Neuen Server vollständig aufbauen, bevor DNS umgestellt wird — testen mit /etc/hosts
• Parallel-Betrieb mindestens 2 Wochen — DNS-Caches sind hartnäckig
• Alten Server erst abschalten, wenn du sicher bist — final-backup.tar.gz als Sicherheitsnetz

Wenn du dich an diese Sequenz hältst, ist eine Hosting-Migration ein kontrollierter, fast langweiliger Prozess — genau wie es sein sollte.