Website-Migration auf neuen Hoster ohne Ausfall: Anleitung

Ein Hoster-Wechsel klingt nach Stress. Die Angst, dass die Website stundenlang nicht erreichbar ist, hält viele Betreiber davon ab, einen veralteten oder langsamen Anbieter zu verlassen. Dabei lässt sich eine saubere website migration neuer hoster mit der richtigen Reihenfolge fast ohne Downtime durchführen.

Ich habe in den letzten 13 Jahren über 120 WordPress-Projekte betreut und dabei Dutzende Migrationen durchgeführt, von kleinen Unternehmensseiten bis zu WooCommerce-Shops mit mehreren tausend Produkten. Die häufigste Ursache für Ausfälle war nicht das Verfahren selbst, sondern eine falsche Reihenfolge der Schritte: erst Domain umgezogen, dann gemerkt, dass SSL fehlt oder die Datenbank-Verbindung nicht funktioniert. Diese Anleitung zeigt, wie Sie die Reihenfolge von Anfang an richtig angehen und die Seite dabei online halten.

Warum ein Hoster-Wechsel überhaupt nötig wird

Die Gründe für einen Hoster-Wechsel sind meistens handfest: langsame Ladezeiten, schlechter Support, fehlendes PHP 8.3, kein einfacher Staging-Bereich oder schlicht zu hohe Preise für zu wenig Leistung. Manchmal empfehle ich meinen Kunden selbst einen Wechsel, wenn der aktuelle Hoster keine DSGVO-konformen Auftragsverarbeitungsverträge anbietet oder die Server außerhalb der EU liegen.

Ein weiterer häufiger Auslöser: der Hoster hat einfach aufgehört, mit der Zeit zu gehen. PHP 7.4 als höchste verfügbare Version, kein HTTP/2, kein GZIP, keine automatischen Backups, und im Support wartet man 48 Stunden auf eine Antwort. Das sind keine Kleinigkeiten, sondern direkte Einflüsse auf Ladezeit und Google-Ranking.

Für kleine und mittlere Unternehmen in Deutschland haben sich All-Inkl (ab rund 8 EUR/Monat), Mittwald (ab rund 15 EUR/Monat) und Raidboxes (ab rund 15 EUR/Monat) als verlässliche Optionen bewährt. Alle drei betreiben Rechenzentren in Deutschland, stellen AVV-Verträge im Panel bereit und unterstützen Let's Encrypt per Knopfdruck.

Schritt 1: Vollständiges Backup erstellen

Bevor irgendetwas am Live-System verändert wird, brauchen Sie ein vollständiges Backup. Das bedeutet: alle Dateien (WordPress-Core, Plugins, Themes, Uploads) und die komplette Datenbank.

Für WordPress-Seiten nutze ich in der Regel UpdraftPlus oder All-in-One WP Migration. Beide exportieren Dateien und Datenbank in ein einziges Archiv. Das Backup kommt auf Ihren lokalen Rechner, nicht nur in die Cloud des alten Hosters. Das ist kein optionaler Schritt. Wenn beim Import etwas schiefgeht, ist ein lokales Backup der einzige schnelle Weg zurück.

Ein Punkt, den viele übersehen: das Backup sollte auch nach dem Umzug noch eine Woche auf dem alten Server bleiben. Nicht weil etwas schiefgehen muss, sondern weil Kunden manchmal erst Tage nach dem Launch merken, dass ein altes Formular oder eine spezifische Seite fehlt.

Schritt 2: DNS-TTL rechtzeitig reduzieren

Dieser Schritt wird häufig vergessen und kostet dann viel Wartezeit. Die TTL (Time to Live) eines DNS-Eintrags bestimmt, wie lange Server weltweit den alten Wert im Cache behalten. Steht die TTL auf dem Standardwert von 3600 Sekunden (eine Stunde) oder höher, kann die Propagation nach dem Umzug bis zu 48 Stunden dauern.

Mindestens 24 Stunden vor dem geplanten Umzug die TTL aller relevanten DNS-Einträge (A-Record, CNAME, MX) auf 300 Sekunden (5 Minuten) setzen. Nach dem erfolgreichen Umzug können Sie die TTL wieder auf einen normalen Wert erhöhen.

Schritt 3: Neue Umgebung einrichten und WordPress installieren

Jetzt richtet der neue Hoster die Hosting-Umgebung ein. Vor dem Import die Serverparameter prüfen: PHP 8.3, MariaDB 10.6 oder höher, aktiviertes OPcache, ausreichend memory_limit (mindestens 256 MB für WordPress, 512 MB für WooCommerce) und max_execution_time von mindestens 120 Sekunden. Die Domain wird zu diesem Zeitpunkt noch nicht auf den neuen Server gezeigt.

Importieren Sie das Backup auf dem neuen Server:
1. Dateien per FTP in das Webroot hochladen
2. Datenbank neu anlegen und .sql-Datei importieren
3. wp-config.php mit neuen Datenbankdaten anpassen
4. Permalinks nach Login unter Einstellungen einmalig neu speichern

Beim FTP-Upload großer Uploads-Ordner empfehle ich rsync oder ein SSH-Kommando statt eines GUI-FTP-Clients. Viele FTP-Clients brechen bei mehreren tausend Dateien ab oder überspringen stille Fehler. Mit rsync -avz sieht man genau, was übertragen wurde.

Für einfache Seiten nutze ich gerne All-in-One WP Migration. Bei Shops mit über 5.000 Produkten oder einer Datenbankgröße von mehr als 200 MB bevorzuge ich den manuellen Weg per WP-CLI und wp search-replace, weil ich dort genau sehe, was geändert wird.

Schritt 4: Mit Test-URL auf dem neuen Server testen

Die Domain zeigt noch auf den alten Server. Trotzdem können Sie die neue Installation vollständig testen, ohne die Migration abzuschließen. Zwei Methoden:

Methode A: Hosts-Datei. Fügen Sie einen Eintrag in die Hosts-Datei Ihres Rechners ein (Windows: C:WindowsSystem32driversetchosts, macOS/Linux: /etc/hosts):

123.456.78.90   ihredomain.de www.ihredomain.de

Ihre IP-Adresse des neuen Servers finden Sie im Hosting-Panel. Nur Ihr Rechner sieht dadurch die neue Version, alle anderen Besucher landen weiterhin auf dem alten Server.

Methode B: Temporäre Subdomain. Viele Hoster erlauben, eine Subdomain wie neu.ihredomain.de oder staging.ihredomain.de direkt auf den neuen Server zu zeigen. WordPress dort mit der Subdomain-URL installieren, testen, und vor dem DNS-Switch die URL in der Datenbank ersetzen.

Bei einem Kundenprojekt aus Hamburg habe ich Methode B genutzt, um einem WooCommerce-Shop mit aktivem Klarna-Gateway vor dem Umzug auf Mittwald alles zu testen: Produkte, Warenkorb, Bestellprozess, E-Mail-Versand. Der eigentliche DNS-Switch dauerte danach keine zehn Minuten.

Schritt 5: SSL-Zertifikat auf dem neuen Hoster aktivieren

Vor dem DNS-Wechsel sollte das SSL-Zertifikat auf dem neuen Server bereitstehen. Bei allen modernen deutschen Hostern lässt sich Let's Encrypt im Panel per Klick aktivieren. Das geht auch, bevor die Domain auf den neuen Server zeigt, wenn der Hoster einen HTTP-01-Challenge über eine temporäre URL oder einen DNS-01-Challenge unterstützt.

Nach der Installation: SSL-Konfiguration mit dem Qualys SSL Labs Test prüfen. Ein Rating von A oder A+ sollte das Ziel sein.

In WordPress die URL-Einstellungen auf https:// anpassen und alle Datenbankeinträge mit wp search-replace 'http://ihredomain.de' 'https://ihredomain.de' --all-tables aktualisieren.

Schritt 6: DNS umschalten und Propagation beobachten

Wenn die neue Umgebung vollständig getestet ist und SSL funktioniert, ändern Sie den A-Record der Domain auf die IP des neuen Servers. Durch die vorher reduzierte TTL verbreitet sich die Änderung jetzt in 5 bis 15 Minuten weltweit, statt bis zu 48 Stunden.

Den Fortschritt können Sie mit dnschecker.org verfolgen: Das Tool zeigt, von welchen Standorten weltweit die Domain bereits auf den neuen Server zeigt. Erst wenn der größte Teil der Standorte grün ist, ist der Umzug für die meisten Besucher abgeschlossen.

Den alten Server noch 48 bis 72 Stunden aktiv lassen. Besucher, die noch den alten DNS-Eintrag im Cache haben, landen dort und werden bedient. Erst danach den alten Hosting-Vertrag kündigen.

Was nach dem Umzug oft vergessen wird

Ein Hoster-Wechsel betrifft nicht nur den Webserver. Es gibt eine Reihe von Diensten und Konfigurationen, die nach der Migration geprüft werden müssen.

E-Mail-Versand: Viele WordPress-Installationen versenden E-Mails über den Hosting-Server direkt (PHP mail()). Auf dem neuen Server kann das anders konfiguriert sein oder ganz fehlen. Ich richte grundsätzlich ein SMTP-Plugin ein (z.B. WP Mail SMTP) und nutze einen dedizierten Dienst wie Brevo oder Mailgun. Damit ist der Mailversand unabhängig vom Hosting.

Caching und CDN: Falls Sie Cloudflare oder ein anderes CDN verwenden, müssen Sie dort nach dem DNS-Wechsel den Cache leeren. Andernfalls liefert das CDN noch Seiten vom alten Server aus. Auch das serverseitige Caching (z.B. LiteSpeed Cache, WP Rocket) sollte nach dem Import einmal deaktiviert und neu konfiguriert werden.

Externe Dienste und Webhooks: Zahlungsanbieter wie Stripe oder Klarna verwenden Webhook-URLs, um Zahlungsbestätigungen an WordPress zu senden. Diese Webhooks sind an die Domain gebunden und müssen nicht angepasst werden, aber die Erreichbarkeit der neuen Serverumgebung für eingehende Anfragen sollte nach dem Umzug kurz getestet werden. Bei einem Kundenprojekt in Hamburg ist uns nach einem Umzug aufgefallen, dass der neue Server IPv6-Anfragen blockiert hat, was zu sporadisch fehlgeschlagenen Stripe-Webhooks geführt hat. Zehn Minuten Fehlersuche im Server-Log, eine Zeile in der nginx-Konfiguration, Problem gelöst.

Google Search Console und Analytics: In der Search Console die neue Sitemaps-URL einreichen und die Crawling-Rate beobachten. Falls sich etwas an der URL-Struktur geändert hat (was bei einem reinen Hoster-Wechsel nicht vorkommen sollte), müssen Weiterleitungen gesetzt werden. Mehr zum Thema Sichtbarkeit und Auffindbarkeit finden Sie in meinem Bereich SEO-Optimierung.

Rechtliches: DSGVO und AVV beim Hoster-Wechsel

Mit dem Wechsel auf einen neuen Hoster ändern sich auch die datenschutzrechtlichen Verhältnisse. Der neue Hoster verarbeitet personenbezogene Daten (IP-Adressen, Formulareinträge, Bestelldaten) im Auftrag des Websitebetreibers. Laut Art. 28 DSGVO ist deshalb ein Auftragsverarbeitungsvertrag (AVV) abzuschließen.

Seriöse deutsche Anbieter stellen diesen Vertrag im Kundenpanel zum Herunterladen oder zur digitalen Unterzeichnung bereit. Prüfen Sie außerdem, ob der neue Hoster die Server ausschließlich in der EU betreibt. Seit Mai 2024 gilt zudem das TDDDG (früher TTDSG), das unter anderem die Anforderungen an Cookies und Tracking-Dienste regelt.

Ich bin Webentwickler, kein Anwalt. Bei konkreten Fragen zur datenschutzrechtlichen Einordnung empfehle ich einen Datenschutzbeauftragten oder Fachanwalt hinzuzuziehen.

Wenn Sie professionelle Unterstützung bei einem Hoster-Wechsel oder dem Aufbau einer neuen WordPress-Website benötigen, können Sie mich gerne kontaktieren. Ich übernehme auch komplette Migrationen für Kunden aus Hamburg und dem deutschsprachigen Raum, inklusive Testphase, DNS-Umschaltung und SSL-Einrichtung.