WordPress zu einem neuen Hoster umziehen: Ablauf ohne Ausfall mit WP-CLI und DNS-Umstellung

Ein Hosterwechsel ist für viele kleine Unternehmen ein Projekt, das man vor sich herschiebt: Die Website soll weiterlaufen, Kontaktanfragen dürfen nicht verloren gehen, und E-Mails hängen oft an derselben Domain. Der Umzug selbst ist technisch überschaubar, wenn die Domain gleich bleibt. Dateien und Datenbank werden kopiert, auf dem neuen Server geprüft, und erst dann wird die Domain per DNS umgestellt. Der Ausfall lässt sich so auf wenige Minuten oder gar null reduzieren. Diese Anleitung beschreibt den Ablauf mit WP-CLI in der richtigen Reihenfolge, mit Prüfsummen, einem Test des neuen Servers vor der Umstellung und einem klaren Rückweg. Export, Prüfsummen, Import und Wartungsmodus haben wir auf einer Testinstanz mit WordPress 7.1.2 durchgespielt.

Voraussetzungen

• WordPress: eine aktuelle Version, getestet mit WordPress 7.1.2 auf PHP 8.4. Der neue Hoster sollte dieselbe oder eine neuere, von Ihren Plugins unterstützte PHP-Version anbieten.
• Rolle: Administrator im WordPress-Backend beider Umgebungen.
• Zugang: SSH mit WP-CLI bei altem und neuem Hoster (getestet mit WP-CLI 2.12.0). Ohne SSH gehen die Schritte auch per SFTP und phpMyAdmin, sind dann aber fehleranfälliger.
• DNS: Zugang zur DNS-Verwaltung der Domain. Liegt DNS beim alten Hoster, planen Sie den Umzug der Zone gesondert, siehe Domain umziehen ohne Ausfall.
• E-Mail: Klarheit, wo die Postfächer liegen. Ein Webhosting-Umzug darf die MX-Einträge nicht versehentlich mit ändern.
• Backup: eine vollständige, geprüfte Sicherung beim alten Hoster, die unabhängig vom Umzug aufbewahrt wird.
• Neues Paket: ausreichend Speicherplatz für mindestens die doppelte Größe der Website, da Archive und entpackte Dateien zeitweise nebeneinander liegen.

Schritt 1: Umzug planen und TTL senken

Die TTL (Time to Live) eines DNS-Eintrags legt fest, wie lange andere Server die Antwort zwischenspeichern. Steht sie auf 86400 Sekunden, sehen manche Besucher die neue Adresse erst nach einem Tag. Senken Sie die TTL der Einträge für @ und www ein bis zwei Tage vor dem Umzug auf 300 Sekunden. Warten Sie mindestens die alte TTL ab, bevor Sie umstellen.

dig +noall +answer www.ihre-firma.de A

Die zweite Spalte der Ausgabe ist die aktuelle TTL in Sekunden. Legen Sie außerdem fest:

• einen Termin mit wenig Betrieb, etwa früh morgens an einem Werktag, damit Sie bei Problemen den Hoster erreichen,
• wer während der Umstellung erreichbar ist,
• was als Rückweg gilt: DNS zurück auf die alte Adresse.

Verifizieren: dig zeigt für die Einträge eine TTL von 300 Sekunden, und die Wartezeit der alten TTL ist abgelaufen.

Schritt 2: Dateien und Datenbank beim alten Hoster sichern

Melden Sie sich per SSH beim alten Hoster an und wechseln Sie in das WordPress-Verzeichnis. Exportieren Sie die Datenbank mit WP-CLI und packen Sie die Dateien:

cd /pfad/zu/wordpress
wp db export ../umzug.sql
tar -czf ../umzug-dateien.tar.gz --exclude=wp-content/cache .
cd ..
sha256sum umzug.sql umzug-dateien.tar.gz > umzug.sha256

wp db export nutzt das Dump-Programm des Servers. Im Labor mit MariaDB 11.8 begann die Datei mit der Zeile „MariaDB dump 10.19-11.8.8-MariaDB“. Das Cache-Verzeichnis lassen Sie weg, weil es auf dem neuen Server neu entsteht. Legen Sie beide Dateien außerhalb des öffentlichen Verzeichnisses ab, also nicht im WordPress-Ordner, sonst sind sie womöglich über den Browser abrufbar.

Notieren Sie außerdem Werte, die sich nicht in den Dateien befinden: PHP-Version und Limits, Cronjobs des Servers, eigene Einträge in der Webserver-Konfiguration und externe Dienste, die auf die IP-Adresse des Servers eingeschränkt sind, etwa ein SMTP-Relay oder eine Zahlungsschnittstelle.

Verifizieren: Beide Dateien sind vorhanden, umzug.sql beginnt mit einer Kopfzeile des Dump-Programms, und umzug.sha256 enthält zwei Zeilen.

Schritt 3: Übertragen und Prüfsummen kontrollieren

Kopieren Sie die drei Dateien auf den neuen Server, am einfachsten direkt von Server zu Server per scp oder rsync. Prüfen Sie danach auf dem neuen Server die Prüfsummen:

sha256sum -c umzug.sha256

umzug.sql: OK
umzug-dateien.tar.gz: OK

Im Labor haben wir die SQL-Datei absichtlich um eine Zeile verlängert. sha256sum meldete daraufhin „umzug.sql: FAILED“ und „WARNING: 1 computed checksum did NOT match“. Eine solche Datei übertragen Sie neu, statt sie einzuspielen. Abgebrochene Übertragungen fallen sonst erst auf, wenn Inhalte fehlen.

Verifizieren: Beide Dateien melden „OK“.

Schritt 4: WordPress beim neuen Hoster einrichten

Legen Sie beim neuen Hoster eine leere Datenbank mit eigenem Benutzer an und notieren Sie Name, Benutzer, Passwort und Host. Entpacken Sie die Dateien in das Web-Verzeichnis der Domain und tragen Sie die neuen Zugangsdaten in die wp-config.php ein:

cd /pfad/zum/neuen/webverzeichnis
tar -xzf ~/umzug-dateien.tar.gz
wp config set DB_NAME neuer_db_name
wp config set DB_USER neuer_db_benutzer
wp config set DB_PASSWORD 'neues-passwort'
wp config set DB_HOST localhost
wp db import ~/umzug.sql

Im Labor meldete der Import „Success: Imported from …“, und die Zahl der Beiträge und Seiten stimmte vor und nach dem Umzug überein. Weil die Domain gleich bleibt, sind siteurl und home bereits richtig, ein wp search-replace ist nicht nötig. Nur bei einem Domainwechsel brauchen Sie ihn, und dann immer mit WP-CLI statt per SQL, weil sonst serialisierte Daten beschädigt werden.

Prüfen Sie danach die Dateirechte und vergleichen Sie Kennzahlen mit dem alten Server:

wp option get siteurl
wp post list --post_type=any --format=count
wp core verify-checksums
wp plugin list --status=active --format=count

Hinweise zu Eigentümer und Rechten stehen in Dateirechte richtig setzen.

Verifizieren: siteurl zeigt die bisherige Adresse, die Zahl der Inhalte und aktiven Plugins stimmt mit dem alten Server überein, und wp core verify-checksums meldet keine veränderten Core-Dateien.

Schritt 5: Den neuen Server vor der Umstellung testen

Die Domain zeigt noch auf den alten Server. Um die neue Installation unter der echten Domain zu sehen, lenken Sie nur Ihren eigenen Rechner um. Mit curl geht das ohne Änderung am System:

curl -I --resolve www.ihre-firma.de:443:203.0.113.20 https://www.ihre-firma.de/

203.0.113.20 steht für die IP-Adresse des neuen Servers. Für einen Test im Browser tragen Sie dieselbe Zuordnung vorübergehend in die Hosts-Datei ein, unter Windows C:\Windows\System32\drivers\etc\hosts, unter macOS und Linux /etc/hosts:

203.0.113.20   www.ihre-firma.de ihre-firma.de

Prüfen Sie dann: Startseite, einige Unterseiten, Anmeldung im Backend, Bilder, Kontaktformular mit echtem Versand, Shop bis vor die Zahlung und Werkzeuge → Website-Zustand. Für HTTPS braucht der neue Server vorab ein Zertifikat. Die übliche HTTP-01-Prüfung von Let's Encrypt ruft laut Dokumentation eine Datei unter der Domain ab und funktioniert deshalb erst, wenn DNS auf den neuen Server zeigt. Fragen Sie den neuen Hoster, ob er das Zertifikat vorher per DNS-01 ausstellen kann, oder planen Sie die wenigen Minuten nach der Umstellung ein.

Verifizieren: Mit Hosts-Eintrag laufen alle geprüften Funktionen auf dem neuen Server, und eine Testnachricht über das Kontaktformular ist angekommen. Entfernen Sie danach den Hosts-Eintrag.

Schritt 6: Letzte Synchronisation und DNS umstellen

Zwischen Export und Umstellung können auf dem alten Server neue Inhalte entstanden sein: Bestellungen, Kommentare, Formulareingaben. Bei einer reinen Informationsseite ohne Änderungen können Sie direkt umstellen. Bei einem Shop oder einer Website mit Kundenkonten gehen Sie so vor:

1. Alte Website in den Wartungsmodus setzen: wp maintenance-mode activate. Im Labor antwortete die Website danach mit „HTTP/1.1 503 Service Unavailable“, auch das Backend.
2. Datenbank erneut exportieren, übertragen, Prüfsumme kontrollieren und auf dem neuen Server einspielen, geänderte Uploads mit rsync nachziehen.
3. DNS-Einträge für @ und www auf die neue IP-Adresse ändern. MX-Einträge bleiben unverändert, wenn die Postfächer nicht mit umziehen.
4. Den alten Server im Wartungsmodus lassen, damit niemand mehr dort bestellt, der noch die alte Adresse im Zwischenspeicher hat.

Mit einer TTL von 300 Sekunden erreichen die meisten Besucher nach wenigen Minuten den neuen Server. Beobachten Sie die Umstellung mit dig und die Zugriffe im Access-Log beider Server.

Verifizieren: dig +short www.ihre-firma.de liefert die neue IP-Adresse, das Access-Log des neuen Servers zeigt Besucher, und auf dem alten Server kommen nur noch vereinzelte Anfragen an.

Schritt 7: Nacharbeiten und Rückweg

Nach der Umstellung erledigen Sie die Punkte, die nicht in den Dateien stecken: Server-Cronjobs neu anlegen, Backup beim neuen Hoster einrichten und einmal testen, Uptime-Überwachung prüfen, IP-Freigaben bei externen Diensten anpassen. Heben Sie die TTL nach einigen Tagen wieder an. Kündigen Sie den alten Vertrag erst, wenn eine Woche lang alles läuft und eine Sicherung vom neuen Server vorliegt. Bis dahin ist der Rückweg einfach: DNS zurück auf die alte IP-Adresse, Wartungsmodus dort beenden.

Der Umzug ist ein guter Anlass, die laufende Pflege neu zu ordnen, denn Backups und Updates müssen beim neuen Hoster ohnehin neu eingerichtet werden. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher mit vier Wochen Aufbewahrung.

Verifizieren: Der erste Backup-Lauf beim neuen Hoster ist erfolgreich, Server-Cronjobs laufen, und der Website-Zustand zeigt keine neuen kritischen Meldungen.

Typische Fehler

• „Error establishing a database connection“: Zugangsdaten in wp-config.php passen nicht zur neuen Datenbank, oft ist DB_HOST beim neuen Hoster nicht localhost.
• Prüfsumme „FAILED“: Übertragung abgebrochen oder Datei im Textmodus übertragen. Neu übertragen, nicht einspielen.
• Weiterleitung auf eine falsche Adresse: siteurl oder home wurden versehentlich geändert, oder die Hosts-Datei ist noch aktiv. Werte mit wp option get prüfen.
• Bestellungen gehen verloren: Die alte Website lief nach dem letzten Export ohne Wartungsmodus weiter. Wartungsmodus vor dem finalen Export setzen.
• E-Mails kommen nicht mehr an: MX-Einträge wurden beim DNS-Umzug mit geändert oder fehlen in der neuen Zone.
• Zertifikatswarnung direkt nach der Umstellung: Auf dem neuen Server fehlt noch das Zertifikat. Vorab mit dem Hoster klären, siehe Schritt 5.

Häufige Fragen

Geht der Umzug auch mit einem Migrations-Plugin?

Ja, viele Plugins exportieren Dateien und Datenbank in ein Archiv. Bei großen Websites stoßen sie auf Limits bei Upload-Größe und Laufzeit. Der Ablauf mit Test vor der DNS-Umstellung bleibt derselbe.

Wie lange ist die Website nicht erreichbar?

Bei einer Website ohne neue Inhalte gar nicht, beide Server liefern dieselben Seiten. Bei einem Shop dauert die Pause so lange wie der letzte Export und Import, bei kleineren Websites meist wenige Minuten.

Muss ich Google über den Umzug informieren?

Nein, bei gleicher Domain ändert sich für Suchmaschinen nur die IP-Adresse.

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4, MariaDB 11.8 und WP-CLI 2.12.0: wp db export, Dateiarchiv mit tar, Prüfsummen mit sha256sum inklusive absichtlich beschädigter Datei, wp db reset und wp db import mit Vergleich der Inhaltszahl, wp core verify-checksums, wp maintenance-mode mit Statuscode 503. Nicht getestet: Übertragung zwischen zwei echten Hostern, DNS-Umstellung und Zertifikatsausstellung, da das Labor keine echten Domains nutzt.

Fazit

Ein Hosterumzug ohne Ausfall folgt einer festen Reihenfolge: TTL senken, sichern, mit Prüfsummen übertragen, einspielen, unter der echten Domain testen und erst dann DNS umstellen. Bei Shops sichert der Wartungsmodus während der letzten Synchronisation die Daten. Der alte Hoster bleibt so lange bestehen, bis der neue eine Woche stabil läuft. Soll die technische Pflege nach dem Umzug mit Updates und Backups dauerhaft jemand übernehmen, finden Sie das bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Domain umziehen ohne Ausfall: DNS, E-Mail und Website
• WordPress-Wiederherstellung auf einer Testinstanz testen
• WordPress-Dateirechte richtig setzen
• WordPress Advanced Administration: Moving WordPress
• WP-CLI: wp db export und wp search-replace
• Let's Encrypt: Challenge Types