Von cPanel auf einen VPS umziehen – ohne Ausfallzeit

Die meisten bleiben beim Shared Hosting, lange nachdem sie ihm entwachsen sind – und selten, weil ein VPS zu teuer wäre. Sondern weil der Umzug riskant wirkt. Ein Dutzend Websites, eine Handvoll Datenbanken, Postfächer, die Kunden täglich nutzen, DNS verteilt auf zwei Registrare – und die nagende Sorge, dass etwas einen ganzen Tag offline ist, während man es herausfindet. Die gute Nachricht: Ein Umzug in der richtigen Reihenfolge hat überhaupt keine sichtbare Ausfallzeit. Der Trick ist, dass fast die gesamte Arbeit vor der ersten DNS-Änderung passiert. Hier ist der Ablauf.

Schritt 0: Bestandsaufnahme, bevor Sie irgendetwas anfassen

Jede schmerzhafte Umzugsgeschichte beginnt mit „wir hatten vergessen…". Bevor Sie ein einziges Byte kopieren, notieren Sie, was tatsächlich auf dem alten Konto lebt:

• Domains: Haupt-, Addon- und geparkte Domains, Subdomains – und wo das DNS der jeweiligen Domain gehostet wird (Registrar, Shared Hoster, Cloudflare…).
• Datenbanken: jede MySQL-Datenbank und welche Website sie nutzt. Alte cPanel-Konten sammeln verwaiste Datenbanken aus aufgegebenen Installationen; jetzt ist der Moment, sie zu löschen.
• PHP-Version und Erweiterungen pro Website. Eine Seite, die seit Jahren still auf PHP 7.4 läuft, übersteht 8.3 nicht unbedingt am ersten Tag.
• Cronjobs – unsichtbar, bis der nächtliche Export nicht mehr ankommt.
• E-Mail: Postfächer, Weiterleitungen, Autoresponder, Catch-alls – und grob, wie viel Mail gespeichert ist.
• .htaccess-Regeln: Weiterleitungen, passwortgeschützte Ordner, Rewrite-Regeln. Läuft Ihr neuer Server mit Nginx, wird keine davon gelesen. Sie müssen übersetzt werden.
• SSL: welche Domains Zertifikate haben und ob kostenpflichtige Zertifikate übernommen werden müssen.

Diese Liste wird am Ende zu Ihrem Testplan.

Schritt 1: Den DNS-TTL ein bis zwei Tage vorher senken

DNS-Einträge tragen einen TTL (Time to Live): wie lange Resolver die Antwort zwischenspeichern dürfen. Shared Hoster nutzen oft 14400 Sekunden (4 Stunden) oder sogar 86400 (einen ganzen Tag). Ändern Sie den A-Eintrag bei einem TTL von einem Tag, landen manche Besucher bis zu einen Tag lang weiter auf dem alten Server.

Deshalb gilt: 24 bis 48 Stunden vor dem Umzug den TTL der A-, AAAA- und MX-Einträge auf 300 Sekunden senken. Dann warten, bis der alte TTL abgelaufen ist. Prüfen Sie, was die Welt gerade sieht:

dig +noall +answer example.com A
dig +noall +answer example.com MX

Die zweite Spalte ist der verbleibende TTL. Sobald dort 300 steht, verbreitet sich eine Umschaltung in etwa fünf Minuten – ein Rückweg bei Bedarf ebenso.

Schritt 2: Ein vollständiges Backup-Archiv holen

In cPanel nutzen Sie Sicherung → Vollständige Kontosicherung herunterladen. Haben Sie Root-Zugriff auf den alten Server, erzeugt /scripts/pkgacct benutzername dasselbe Archiv schneller. In Plesk geht es über den Backup-Manager. Das Archiv enthält das Home-Verzeichnis (mit public_html), jede Datenbank als SQL-Dump, die Postfächer und die DNS-Zonendaten.

Holen Sie es direkt auf den neuen Server statt über Ihren Laptop – cPanel kann das Backup per SCP an einen entfernten Server schieben, oder Sie laden es mit wget von der neuen Maschine aus herunter. Mehrere Gigabyte über einen Heimanschluss sind genau die Stelle, an der Umzüge ins Stocken geraten.

Trauen Sie dem Komplettarchiv nicht (sehr große Konten laufen manchmal in Timeouts), kopieren Sie Dateien und Datenbanken getrennt:

# auf dem neuen Server: das Web-Root kopieren
rsync -avz --progress olduser@old-host:public_html/ /var/www/example/public_html/

# beim alten Hoster: eine Datenbank exportieren
mysqldump --single-transaction --routines --triggers olduser_wp > olduser_wp.sql

--single-transaction liefert einen konsistenten InnoDB-Snapshot, ohne die Live-Seite zu sperren.

Schritt 3: Die Website auf dem VPS neu aufbauen

Legen Sie auf dem neuen Server die Website an – eigener Linux-Benutzer, Web-Root, PHP-FPM-Pool und Vhost – und importieren Sie dann Dateien und Daten:

mysql -e "CREATE DATABASE example_wp; CREATE USER 'example_wp'@'localhost' IDENTIFIED BY 'ein-langes-zufaelliges-passwort'; GRANT ALL ON example_wp.* TO 'example_wp'@'localhost';"
mysql example_wp < olduser_wp.sql

cPanel stellt Datenbanknamen den Kontonamen voran (olduser_wp). Auf dem neuen Server verwenden Sie fast sicher andere Namen, Benutzer und Passwörter – passen Sie also die Konfiguration der Anwendung an: wp-config.php, die .env von Laravel und so weiter. Korrigieren Sie danach die Besitzrechte, sodass der Benutzer der Website seine Dateien besitzt, und übernehmen Sie die PHP-Version, auf der die Seite bisher lief. Das PHP-Upgrade folgt später, als eigener, bewusster Schritt.

Schritt 4: Den neuen Server testen, bevor das DNS ihn kennt

Sie können den neuen Server unter der echten Domain aufrufen, ohne das öffentliche DNS zu ändern. Tragen Sie die neue IP für die Domain in Ihre lokale hosts-Datei ein, oder testen Sie auf der Kommandozeile:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Klicken Sie sich durch die Seite, melden Sie sich im Admin-Bereich an, schicken Sie ein Formular ab, prüfen Sie das Fehlerlog. Hier finden Sie die fehlende PHP-Erweiterung, den fest einprogrammierten absoluten Pfad nach /home/olduser/ und die Weiterleitung, die nur in der .htaccess existierte.

Schritt 5: E-Mail – der Teil, den alle unterschätzen

Websites sind statisch genug, um sie zweimal zu kopieren; E-Mail nicht. Während des Umzugs kommt weiter neue Post an, und Nutzer merken sofort, wenn etwas fehlt. Sie haben drei Optionen:

1. E-Mail vorerst dort lassen, wo sie ist, und nur die Websites umziehen. Die MX-Einträge zeigen weiter auf den alten Hoster. Völlig legitim – und es teilt einen riskanten Umzug in zwei einfache.
2. E-Mail zu einem spezialisierten Mail-Anbieter umziehen.
3. E-Mail auf Ihrem VPS hosten. Legen Sie die Postfächer auf dem neuen Server an und kopieren Sie vorhandene Nachrichten per IMAP mit imapsync:

imapsync --host1 old-host.example --user1 info@example.com --password1 'alt' \
         --host2 new-host.example --user2 info@example.com --password2 'neu'

Lassen Sie es einmal vor der Umschaltung laufen und noch einmal nach dem MX-Wechsel, um Nachzügler mitzunehmen. Bevor Sie Mail auf Ihren eigenen Server holen, lesen Sie sich in SPF, DKIM, DMARC und Reverse DNS ein – eine neue IP ohne Reputation ist genau das, dem Spamfilter misstrauen.

Schritt 6: Die Umschaltung

Mit einem TTL von 300 Sekunden und einem getesteten Server ist die Umschaltung selbst unspektakulär:

1. Änderungen einfrieren auf dynamischen Seiten (keine neuen Beiträge, Bestellungen oder Plugin-Updates in der nächsten Stunde).
2. Letzte Delta-Synchronisation: rsync erneut ausführen (nur geänderte Dateien werden übertragen) und die Datenbanken neu exportieren und importieren.
3. A- und AAAA-Einträge auf die neue IP umstellen. MX nur umstellen, wenn Sie die E-Mail jetzt mit umziehen.
4. SSL-Zertifikate ausstellen, sobald das DNS auf den neuen Server auflöst – die HTTP-Challenge von Let's Encrypt verlangt, dass die Domain auf die Maschine zeigt, die das Zertifikat anfordert.
5. Das Zugriffslog des alten Servers beobachten. Versiegt dort der Traffic, ist die Verbreitung abgeschlossen.
6. Das alte Hosting mindestens eine Woche behalten. Es ist Ihr Rückweg und das Archiv für alles, was Sie vergessen haben.

Fallen, aus denen „es war das ganze Wochenende down"-Geschichten entstehen

• DNS mit 24-Stunden-TTL umstellen. Einen langen TTL kann man nachträglich nicht rückgängig machen. Senken Sie ihn zuerst.
• .htaccess unter Nginx. Weiterleitungen und geschützte Ordner hören still auf zu funktionieren. Übersetzen Sie sie in die Serverkonfiguration.
• Fest einprogrammierte Pfade und URLs. Durchsuchen Sie Code und Datenbank nach /home/olduser und nach http://-Varianten der Domain.
• Vergessene Cronjobs. Legen Sie sie neu an, mit dem richtigen PHP-Binary für die Version der Seite.
• Das alte Konto zu früh kündigen. Kündigen Sie erst, wenn der neue Server eine Woche lang alles ausgeliefert hat – Web und Mail.
• Alles auf einmal ändern. Neuer Server, neue PHP-Version, neues Mail-Setup und ein Theme-Update am selben Abend – dann wissen Sie nicht, welche Änderung etwas kaputt gemacht hat. Erst umziehen, dann modernisieren.

Wie ShadowPanel den Umzug automatisiert

ShadowPanel ist ein selbstgehostetes Hosting-Control-Panel, und der Abschied von cPanel oder Plesk ist dort ein eingebauter Ablauf statt eines Nachmittags voller Shell-Befehle.

• Ein cPanel- oder Plesk-Backup-Archiv importieren. Legen Sie das Archiv per SFTP in den Migrationsordner des Panels (die richtige Wahl für große Backups) oder laden Sie kleinere im Browser hoch. Das Panel untersucht es nur lesend, erkennt, ob es von cPanel oder Plesk stammt, und listet die gefundenen Domains, Datenbanken und Postfächer auf.
• Auswählen, was mitkommt. Wählen Sie Zieldomain und PHP-Version, ob die Dateien importiert werden sollen, welche Datenbanken und welche Postfächer. Die Migration läuft dann als Hintergrundjob: Sie legt die Website mit eigenem, isoliertem Linux-Benutzer, PHP-FPM-Pool und Nginx-Vhost an, kopiert das Web-Root an seinen Platz und importiert jede Datenbank unter einem neuen, verwalteten Namen, Benutzer und Passwort. Das Ergebnis ordnet jeder ursprünglichen Datenbank ihren neuen Namen zu – die App-Konfiguration anzupassen ist damit eine Sache von zwei Minuten.
• Postfächer werden mit neuen Passwörtern angelegt, die am Ende einmalig angezeigt werden, damit Sie sie weitergeben können – Passwort-Hashes des alten Hosters lassen sich nicht wiederverwenden. Gespeicherte Nachrichten werden nicht kopiert; das imapsync aus Schritt 5 gilt also weiterhin.
• Eine Website schon von Hand kopiert? Die Funktion Bestehende Website importieren übernimmt eine Seite, die bereits auf der Festplatte des Servers liegt. Sie zeigt vorab Größe, Dateianzahl, erkannte Anwendung und PHP-Version an und ermittelt die Datenbank aus wp-config.php oder .env. Dann kopiert sie die Dateien in die verwaltete Struktur – sie verschiebt sie nie, das Original bleibt also unangetastet –, sichert einen eventuell vorhandenen Vhost und übernimmt oder stellt das SSL-Zertifikat aus.
• Für die .htaccess-Lücke gibt es im Panel Weiterleitungen und passwortgeschützte Pfade pro Website, und Zertifikate werden automatisch ausgestellt und erneuert (siehe kostenloses SSL mit Let's Encrypt).

Beide Import-Werkzeuge sind Administratoren vorbehalten, da sie auf den gesamten Server wirken. Falls Sie noch keinen Server gewählt haben: ein Hosting-Panel auf einem Hetzner-VPS installieren deckt die Einrichtung von Anfang bis Ende ab.

Fazit

Ein Umzug ohne Ausfallzeit ist vor allem eine Frage der Reihenfolge: Bestandsaufnahme, TTL früh senken, auf dem neuen Server aufbauen und testen, während der alte weiter ausliefert, E-Mail als eigenes Projekt behandeln, dann das DNS mit kurzem TTL umstellen – mit dem alten Hoster als Sicherheitsnetz. Keiner der Schritte ist schwer. Weh tut es, wenn man einen überspringt. ShadowPanel nimmt ein cPanel- oder Plesk-Archiv und macht aus dem Neuaufbau – Website, Isolation, Dateien, Datenbanken, Postfächer – einen geführten Import, damit Ihre Aufmerksamkeit dem Testen gilt statt der Verrohrung.

curl -fsSL https://shadowpanel.de/install.sh | bash

Preise ansehen und herunterladen →