Webhosting 8 Min Lesezeit

Website auf neuen Server migrieren 2026 – Schritt für Schritt

Website auf neuen Server migrieren 2026: Warum jetzt der richtige Zeitpunkt ist

Ein Serverumzug ist 2026 für viele Betreiber keine Kür, sondern Pflicht. Mehrere zentrale Stack-Komponenten laufen in diesem Jahr aus dem Support: Debian 11 „Bullseye" erhält LTS-Updates nur noch bis 31. August 2026, PHP 8.1 bekam seine letzten Security-Fixes im Dezember 2025, und Ubuntu 20.04 LTS ist bereits seit Mai 2025 ohne Standard-Support. Wer auf solchen Systemen hostet, fährt ohne Sicherheitsupdates – bei einem öffentlich erreichbaren Webserver ein echtes Risiko.

Gleichzeitig ist die Hardware günstiger geworden. Ein Hetzner Cloud CX22 mit 2 vCPU, 4 GB RAM und 40 GB NVMe kostet 2026 rund 4,35 € pro Monat, ein CPX21 mit 3 dedizierten vCPU etwa 8,98 €. Vor fünf Jahren zahlte man für vergleichbare Leistung das Drei- bis Vierfache. Der Umzug ist damit oft auch ein Kostensenkungsprojekt.

Dieser Guide führt Schritt für Schritt durch die komplette Migration – von der Bestandsaufnahme über rsync und Datenbank-Dumps bis zum DNS-Cutover und Rollback-Plan. Die Zeitangaben sind realistisch für ein typisches WordPress-, Shopware- oder Laravel-Projekt mit 5 bis 50 GB Daten und 1 bis 5 Datenbanken. Rechnen Sie mit 3 bis 6 Stunden Arbeitszeit plus 24 bis 48 Stunden Beobachtungsphase.

Schritt 1: Bestandsaufnahme – was muss wirklich mit?

Vor dem ersten Befehl steht die Inventarisierung. Erfassen Sie alles, was die Website ausmacht: Dateien, Datenbanken, Cronjobs, DNS-Einträge, Mail-Konten, SSL-Zertifikate, externe API-Keys und Webhooks. Vergessene Cronjobs und Webhooks sind die häufigste Ursache für „die Seite läuft, aber irgendwas fehlt" nach dem Umzug.

Ein schneller Überblick über die Dateigrößen hilft bei der Wahl des Zielservers:

du -sh /var/www/*
du -sh /var/www/html/wp-content/uploads
mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024,1) AS mb FROM information_schema.tables GROUP BY table_schema ORDER BY mb DESC;"
crontab -l
systemctl list-timers --all

Notieren Sie außerdem die exakten Versionen, denn sie bestimmen den Zielserver:

Komponente	Befehl	Relevanz
PHP	`php -v`	Ziel muss gleiche oder neuere Minor-Version haben
MySQL/MariaDB	`mysql --version`	Dump-Format und Kollationen
nginx/Apache	`nginx -v`	Rewrite-Regeln, .htaccess
Node.js	`node -v`	Build-Toolchain
OS	`cat /etc/os-release`	EOL-Status

Bei WordPress listen Sie zusätzlich alle aktiven Plugins und Themes auf, weil inaktive Plugins oft veraltete Code-Pfade enthalten, die auf neuer PHP-Version crashen: wp plugin list --status=active --format=table. Prüfen Sie parallel, ob Plugins wie Caching- oder Security-Tools an die Server-IP gebunden sind – manche Lizenzen sind hostgebunden und müssen nach dem Umzug neu aktiviert werden.

Schritt 2: Zielserver auswählen und bestellen

Die Wahl hängt von drei Faktoren ab: benötigte CPU-Leistung, Speicherplatz und ob Sie den Server selbst administrieren wollen. Für klassisches Webhosting mit WordPress reicht oft ein VPS der 5-Euro-Klasse. Shops mit vielen gleichzeitigen Sessions und Redis-Cache sollten bei 8 GB RAM einsteigen.

Anbieter / Produkt	Specs	Preis/Monat	Geeignet für
Hetzner CX22	2 vCPU, 4 GB, 40 GB NVMe	ca. 4,35 €	Blogs, kleine Shops
Hetzner CPX21	3 vCPU, 8 GB, 80 GB NVMe	ca. 8,98 €	Shopware, WooCommerce
netcup VPS 1000 G11	4 vCPU, 8 GB, 256 GB NVMe	ca. 6,49 €	Multi-Site-Setups
Contabo VPS S	4 vCPU, 8 GB, 200 GB NVMe	ca. 5,99 €	Preisorientierte Projekte
Managed WordPress (Kinsta/Raidboxes)	1 Site, 10 GB, CDN	25–35 €	Ohne Server-Admin-Aufwand

Achten Sie beim Bestellen auf drei Dinge: IPv4-Adresse inklusive (bei Hetzner kostet eine zusätzliche IPv4 0,50 €/Monat), Backup-Option (bei Hetzner 20 % Aufpreis) und Rechenzentrumsstandort in Deutschland oder Österreich für DSGVO-Konformität. Wer EU-weit ausliefert, sollte Nürnberg, Falkenstein oder Wien wählen – Latenzen unter 25 ms zu den meisten deutschen ISPs.

Bestellen Sie den Zielserver mindestens 48 Stunden vor dem geplanten Cutover. So bleibt Zeit für Setup, Test und die Propagierung der DNS-Einträge. Richten Sie direkt nach dem ersten Login einen Nicht-Root-User mit SSH-Key ein und deaktivieren Sie Passwort-Login in /etc/ssh/sshd_config (PasswordAuthentication no, PermitRootLogin no).

Schritt 3: Backup-Strategie vor der Migration

Die eiserne Regel lautet 3-2-1: drei Kopien, zwei Medien, eine außerhalb des Servers. Vor jeder Migration erstellen Sie ein vollständiges Backup, das Sie nicht auf dem Quellserver liegen lassen. Ein Backup auf derselben Platte ist kein Backup.

Für Dateien und Datenbanken getrennt:

# Dateien
tar czf /root/backup-dateien-$(date +%F).tar.gz -C /var/www html

# Datenbank (MySQL/MariaDB, konsistent ohne Lock)
mysqldump --single-transaction --quick --routines --triggers \
  --default-character-set=utf8mb4 -u root -p datenbank | gzip -9 > /root/db-$(date +%F).sql.gz

# PostgreSQL
pg_dump -Fc -U postgres datenbank > /root/db-$(date +%F).dump

Kopieren Sie die Archive sofort per rsync oder scp auf einen dritten Speicherort – ein Storage Box, S3-Bucket oder lokales NAS. Prüfen Sie die Integrität mit gunzip -t bzw. tar tzf, bevor Sie weitermachen. Ein ungetestetes Backup ist wertlos.

Für wiederkehrende Migrationen lohnt sich restic oder borgbackup mit deduplizierten Snapshots. Restic schreibt verschlüsselt in einen S3-kompatiblen Bucket und braucht für 50 GB typischerweise unter 10 Minuten bei inkrementellen Läufen.

Schritt 4: DNS vorbereiten und TTL senken

Der kritischste Teil der Migration ist der DNS-Cutover, weil er nicht sofort global wirkt. Resolver cachen Einträge gemäß ihrer TTL. Steht Ihre A-Record-TTL auf 86400 (24 Stunden), dauert die Umstellung potenziell einen ganzen Tag. Senken Sie die TTL deshalb mindestens 48 Stunden vorher auf 300 Sekunden (5 Minuten).

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME
dig NS example.com

Erfassen Sie alle relevanten Records in einer Tabelle, bevor Sie etwas ändern. Dazu gehören A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), und bei Subdomain-Setups auch Wildcards. Vergessen Sie nicht Einträge für Mail, denn ein falsch migrierter MX-Record führt zu stundenlangem Mailverlust.

Legen Sie auf dem Zielserver bereits eine Test-Subdomain an, etwa neu.example.com, die auf die neue IP zeigt. Damit können Sie die komplette Installation durchtesten, ohne die Live-Seite zu berühren. Der spätere Cutover ist dann nur noch ein Wechsel des A-Records von example.com und www.

Schritt 5: Dateien übertragen mit rsync

rsync ist das Werkzeug der Wahl, weil es inkrementell arbeitet und abgebrochene Transfers fortsetzen kann. Übertragen Sie immer über SSH, nie über FTP. Der erste Lauf dauert bei 20 GB und 100 Mbit/s etwa 30 Minuten, jeder weitere Lauf nur Sekunden.

rsync -avz --delete --numeric-ids \
  --exclude='.git' --exclude='node_modules' --exclude='*.log' \
  -e "ssh -p 22 -o Compression=no" \
  /var/www/html/ deploy@203.0.113.10:/var/www/html/

Führen Sie den Transfer in einer tmux- oder screen-Session aus, damit ein Verbindungsabbruch den Lauf nicht killt. Bei sehr großen Datenmengen ist ein tar-Stream über SSH schneller, weil der rsync-Overhead entfällt:

tar czf - -C /var/www html | ssh deploy@203.0.113.10 "tar xzf - -C /var/www"

Nach dem Transfer vergleichen Sie die Dateianzahl und Größe auf beiden Seiten mit du -sh und find /var/www/html -type f | wc -l. Setzen Sie anschließend die Besitzrechte korrekt: chown -R www-data:www-data /var/www/html und für Verzeichnisse find /var/www/html -type d -exec chmod 755 {} \;, für Dateien 644.

Schritt 6: Datenbanken migrieren

Datenbanken müssen konsistent gedumpt werden. Bei InnoDB-Tabellen sorgt --single-transaction für einen konsistenten Snapshot ohne Tabellen-Locks – die Live-Seite bleibt während des Dumps erreichbar. Bei MyISAM-Tabellen gibt es diese Option nicht, dort ist ein kurzes Wartungsfenster nötig.

# Auf dem Quellserver
mysqldump --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 -u root -p datenbank | gzip -9 > db.sql.gz

# Transfer
scp db.sql.gz deploy@203.0.113.10:/root/

# Auf dem Zielserver
gunzip -c /root/db.sql.gz | mysql -u root -p datenbank

Vergessen Sie nicht die Benutzer und Rechte. Ein Dump enthält keine CREATE USER-Statements. Erstellen Sie die Datenbankbenutzer auf dem Zielserver manuell und vergeben Sie nur die nötigen Rechte:

CREATE USER 'webuser'@'localhost' IDENTIFIED BY 'starkesPasswort';
GRANT SELECT, INSERT, UPDATE, DELETE ON datenbank.* TO 'webuser'@'localhost';
FLUSH PRIVILEGES;

Prüfen Sie nach dem Import die Zeilenzahlen der wichtigsten Tabellen auf beiden Servern. Bei WordPress sind das wp_posts, wp_postmeta und wp_options. Weicht eine Zahl ab, war der Dump unvollständig. Denken Sie außerdem daran, in der wp-config.php oder .env-Datei die neuen Zugangsdaten einzutragen.

Schritt 7: Webserver, PHP und SSL konfigurieren

Installieren Sie auf dem Zielserver den gleichen Webserver-Stack. Bei nginx legen Sie einen vHost unter /etc/nginx/sites-available/example.com an und verlinken ihn nach sites-enabled. Wichtig sind korrekte root- und index-Direktiven sowie die PHP-FPM-Socket-Zuordnung.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;
    root /var/www/html;
    index index.php index.html;

    client_max_body_size 64M;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Installieren Sie PHP 8.3 oder 8.4 – beide sind 2026 aktiv unterstützt. PHP 8.4 bringt Property Hooks und schnellere JIT-Kompilierung; bei typischen WordPress-Setups messen wir 8 bis 15 % mehr Requests pro Sekunde gegenüber 8.2. Passen Sie memory_limit (256M), upload_max_filesize (64M) und opcache.memory_consumption (256) an.

Für SSL nutzen Sie Let's Encrypt via certbot. Der Befehl richtet Zertifikat, Renewal-Timer und HTTP-zu-HTTPS-Redirect in einem Rutsch ein:

certbot --nginx -d example.com -d www.example.com --redirect --agree-tos -m admin@example.com

Erzwingen Sie TLS 1.3 und moderne Cipher Suites, aktivieren Sie HSTS erst nach erfolgreichem Test (add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;). Prüfen Sie das Ergebnis mit openssl s_client -connect example.com:443 -tls1_3 und über den SSL Labs Test – Ziel ist ein A+ Rating.

Schritt 8: Testphase auf dem neuen Server

Testen Sie die neue Installation, bevor DNS umgestellt wird. Der eleganteste Weg ist ein temporärer Eintrag in /etc/hosts auf Ihrem lokalen Rechner, der die Domain auf die neue IP zwingt:

# /etc/hosts (lokal)
203.0.113.10  example.com www.example.com

Alternativ prüfen Sie per curl mit erzwungener Auflösung, ohne die lokale Konfiguration zu ändern:

curl -I --resolve example.com:443:203.0.113.10 https://example.com
curl -s --resolve example.com:443:203.0.113.10 https://example.com | head -50

Arbeiten Sie diese Checkliste ab:

Startseite, Unterseiten, 404-Seite laden korrekt
Login in Backend und Admin-Panel funktioniert
Formulare senden Mails (SMTP testen, nicht mail())
Checkout-Prozess inklusive Zahlungsanbieter-Callback
Bilder und Assets werden ausgeliefert (kein Mixed Content)
Cronjobs laufen (Logs prüfen)
Redirects von alten URLs greifen
Cache-Plugin leert korrekt

Messen Sie zusätzlich die Ladezeit mit curl -w "@curl-format.txt" -o /dev/null -s https://example.com oder ab -n 500 -c 20. Vergleichen Sie TTFB alt gegen neu – ein gut konfigurierter neuer Server sollte mindestens 20 % schneller sein, sonst stimmt etwas mit Opcache oder Datenbank-Indizes nicht.

Schritt 9: Der Cutover – DNS umstellen

Wählen Sie ein Zeitfenster mit niedrigem Traffic, idealerweise Dienstag bis Donnerstag zwischen 2:00 und 5:00 Uhr. Setzen Sie die Live-Seite in den Wartungsmodus, damit während des Wechsels keine Bestellungen oder Kommentare verloren gehen, die nur in der alten Datenbank landen würden.

Der Ablauf in Kurzform:

Wartungsmodus auf dem alten Server aktivieren
Letzten inkrementellen rsync-Lauf ausführen
Finalen Datenbank-Dump erstellen und importieren
A-Records für example.com und www auf die neue IP ändern
Wartungsmodus auf dem neuen Server deaktivieren
Propagierung beobachten

Die Propagierung prüfen Sie mit mehreren Resolvern:

dig @1.1.1.1 +short example.com
dig @8.8.8.8 +short example.com
dig @9.9.9.9 +short example.com

Bei TTL 300 ist die Umstellung nach spätestens 10 Minuten bei über 95 % der Nutzer angekommen. Behalten Sie den alten Server mindestens 14 Tage online, aber schalten Sie ihn in den Read-Only-Modus. So können Sie bei Problemen binnen Minuten zurückrollen, indem Sie den A-Record wieder auf die alte IP zeigen lassen.

Schritt 10: Nach der Migration – Monitoring und Aufräumen

Nach dem Cutover beginnt die Beobachtungsphase. Installieren Sie ein Monitoring, das Erreichbarkeit, Antwortzeit und Zertifikatsablauf überwacht. Uptime Kuma ist selbst gehostet kostenlos, Netdata liefert detaillierte Systemmetriken mit einem Ein-Zeilen-Installer.

curl -Ss https://get.netdata.cloud/kickstart.sh | bash

Achten Sie in den ersten 48 Stunden auf diese Kennzahlen: HTTP-5xx-Rate (Ziel: unter 0,1 %), durchschnittliche Antwortzeit, CPU-Last, freier RAM und Datenbankverbindungen. Steigt die 5xx-Rate, prüfen Sie zuerst /var/log/nginx/error.log und /var/log/php8.3-fpm.log.

Räumen Sie danach auf: alte DNS-Einträge entfernen, verwaiste Subdomains löschen, SSL-Zertifikate auf dem alten Server widerrufen, Backups rotieren. Aktualisieren Sie außerdem Ihre Dokumentation – Server-IP, Zugangsdaten, Cronjobs und Deployment-Pipeline. Und kündigen Sie den alten Vertrag erst, wenn die neue Umgebung zwei Wochen stabil läuft.

Zum Schluss lohnt ein Performance-Tuning: aktivieren Sie Brotli-Kompression, HTTP/3 (QUIC) in nginx 1.25+, einen Redis-Object-Cache und ein CDN für statische Assets. In Kombination mit dem frischen PHP 8.4 bringt das typischerweise 30 bis 50 % schnellere Ladezeiten gegenüber dem alten Setup.

FAQ

Wie lange dauert eine Website-Migration auf einen neuen Server?

Für ein typisches WordPress- oder Shopware-Projekt mit 5 bis 50 GB Daten dauert die technische Migration 3 bis 6 Stunden. Hinzu kommen 24 bis 48 Stunden Beobachtungsphase nach dem DNS-Cutover. Der kritischste Teil ist die DNS-Propagierung, die bei TTL 300 nach etwa 10 Minuten bei den meisten Nutzern abgeschlossen ist.

Muss ich während der Migration die Domain umstellen?

Nein, die Domain bleibt gleich. Sie ändern nur den A-Record, der auf die neue Server-IP zeigt. Die Domain selbst muss nicht transferiert werden, solange Sie Zugriff auf die DNS-Verwaltung haben. Nur wenn Sie gleichzeitig den Registrar wechseln wollen, ist ein zusätzlicher Auth-Code und eine Wartezeit von 5 bis 7 Tagen einzuplanen.

Was passiert mit E-Mails während des Serverumzugs?

E-Mails laufen über MX-Records und sind unabhängig von der Website-IP. Wenn Sie Mail auf demselben Server hosten, müssen Sie Postfix oder Dovecot mitmigrieren und den MX-Record separat umstellen. Planen Sie dafür ein eigenes Wartungsfenster ein, denn während der MX-Propagierung können Mails verzögert oder abgelehnt werden.

Wie rollbacke ich eine fehlgeschlagene Migration?

Der Rollback ist einfach, solange der alte Server noch läuft: Setzen Sie den A-Record zurück auf die alte IP. Innerhalb der DNS-TTL (bei 300 Sekunden also 5 Minuten) sind alle Nutzer wieder auf dem alten System. Deshalb sollten Sie den Quellserver mindestens 14 Tage nach dem Cutover nicht abschalten oder kündigen.

Kann ich die Migration ohne Ausfallzeit durchführen?

Eine echte Null-Ausfallzeit ist bei klassischem Hosting schwer, aber nahezu ausfallfrei möglich. Nutzen Sie inkrementelle rsync-Läufe, einen finalen kurzen Wartungsmodus von 5 bis 15 Minuten für den letzten Datenbank-Dump und eine niedrige DNS-TTL. Bei statischen Sites oder solchen mit Read-Only-Phase lässt sich der Wechsel komplett ohne sichtbare Unterbrechung durchführen.