Stand: Oktober 2026
Wer sein Hosting wechseln will, ohne dass Besucher eine Fehlerseite sehen, braucht vor allem Geduld. Alter und neuer Server laufen eine Zeit lang parallel. Die DNS-TTL wird ein bis zwei Tage vorher gesenkt. Der Domain-Transfer wird vom Umzug der Website getrennt und erst erledigt, wenn alles stabil läuft. Gekündigt wird der alte Vertrag ganz zum Schluss. Halte dich an diese Reihenfolge, dann merkt die Umstellung praktisch niemand. Die meisten Ausfälle, die man in Foren nachlesen kann, gehen darauf zurück, dass ein Schritt vorgezogen wurde.
Ausfälle entstehen beim DNS und bei der Mail, kaum beim Kopieren
Dateien und Datenbank zu kopieren ist heute Routine. Ein WordPress-Projekt mit ein paar tausend Beiträgen ist in einer Stunde auf einem neuen Server. Heikel wird es danach. Sobald du die IP-Adresse im DNS änderst, kommt diese Änderung nicht überall gleichzeitig an. Resolver bei Internetanbietern, in Firmennetzen und auf den Geräten selbst merken sich den alten Eintrag so lange, wie es die TTL erlaubt. In dieser Phase landet ein Teil der Besucher auf dem neuen Server, ein anderer Teil weiter auf dem alten.
Bei einer reinen Infoseite ist das egal, solange beide Server dieselben Inhalte ausliefern. Bei einem Shop, einem Forum oder einer Seite mit Kontaktformular ist es das nicht. Dann entstehen Bestellungen, Kommentare oder Anfragen auf einem Server, den du gleich abschalten willst. Bei der E-Mail gilt das genauso: Nachrichten, die während der Umstellung beim alten Mailserver eingehen, liegen dort, bis jemand sie abholt.
Der ganze Ablauf unten zielt deshalb darauf, dieses Übergangsfenster kurz zu halten und in dieser Zeit nichts zu verlieren.
Vor dem ersten Klick: die Bestandsaufnahme
Bevor du irgendetwas buchst oder kündigst, schreibst du auf, was das Projekt eigentlich alles umfasst. Das dauert eine halbe Stunde und erspart dir die meisten Überraschungen.
Wo die Domain liegt und wer die Nameserver stellt
Die wichtigste Frage zuerst: Ist die Domain beim aktuellen Hoster registriert, oder liegt sie bei einem separaten Registrar? Und wer betreibt die Nameserver, also wo werden die DNS-Einträge gepflegt? Bei vielen Shared-Hosting-Paketen ist alles in einer Hand. Das ist bequem, macht den Umzug aber riskanter, weil eine Kündigung des Pakets auch die Domain betreffen kann.
Die komplette DNS-Zone sichern
Exportiere oder fotografiere alle DNS-Einträge, nicht nur den A-Record. Typischerweise findest du dort:
- A- und AAAA-Records für die Domain und die www-Variante
- MX-Records für die Mailzustellung
- TXT-Records für SPF, DKIM und DMARC
- TXT-Einträge zur Verifizierung, etwa für die Google Search Console, Microsoft-Dienste oder Newsletter-Tools
- CNAME-Einträge für Subdomains, die auf externe Dienste zeigen, zum Beispiel einen Shop-Checkout oder ein Helpdesk
Gerade die Verifizierungseinträge gehen beim Umzug gern verloren. Die Folge merkt man erst Wochen später, wenn die Search Console plötzlich den Zugriff verweigert oder Newsletter im Spam landen.
Technische Eckdaten und Verträge
Notiere die PHP-Version, die Datenbankversion, die Größe von Webspace und Datenbank, alle Cronjobs und alle Mailpostfächer samt Weiterleitungen. Wirf auch einen Blick in den alten Vertrag: Wie lang ist die Kündigungsfrist, und ist eine Domain inklusive? Für den Ablauf brauchst du je nach Projektgröße zwei bis vier Wochen Überschneidung. Plane die Kündigung so, dass dieser Puffer sicher drin ist.
Der Ablauf in der Reihenfolge, in der er wirklich passiert
1. Neuen Tarif buchen, alten Vertrag nicht anfassen
Du buchst das neue Hosting als eigenständiges Paket, möglichst ohne die Domain gleich mitzuziehen. Viele Hoster bieten beim Bestellprozess an, die Domain per Transfer mitzunehmen. Das kannst du später machen. Fürs Erste brauchst du nur Webspace, Datenbank und, falls die Mail mitziehen soll, Postfächer.
Typischer Fehler: Der alte Vertrag wird am selben Tag gekündigt, „damit man es nicht vergisst“. Bei Paketen mit Inklusivdomain kann das dazu führen, dass die Domain zum Vertragsende freigegeben oder gelöscht wird, wenn bis dahin kein Transfer abgeschlossen ist. Setz dir lieber eine Erinnerung im Kalender.
2. Die TTL senken, und zwar früh genug
Die TTL (Time to Live) legt fest, wie lange Resolver einen DNS-Eintrag zwischenspeichern dürfen. Standardwerte liegen oft bei einer Stunde oder einem ganzen Tag. Senke die TTL der A- und AAAA-Records auf einen niedrigen Wert wie 300 Sekunden, also fünf Minuten.
Entscheidend ist der Zeitpunkt. Die neue, kurze TTL wirkt erst, wenn die alte abgelaufen ist. Stand die TTL auf 86.400 Sekunden, also 24 Stunden, musst du mindestens einen Tag warten, bevor die Umstellung schnell durchläuft. Ein Puffer von 48 Stunden ist entspannter.
Typischer Fehler: Die TTL wird am Umzugstag gesenkt und direkt danach die IP geändert. Dann halten viele Resolver den alten Eintrag trotzdem noch bis zu einem Tag fest. Ebenfalls häufig: Der alte Hoster lässt keine TTL-Änderung zu. Dann bleibt nur, das längere Übergangsfenster einzuplanen und den alten Server entsprechend länger laufen zu lassen.
3. Dateien und Datenbank auf den neuen Server bringen
Der Kopiervorgang selbst ist unspektakulär. Dateien gehen per SFTP oder, wenn beide Seiten SSH erlauben, per rsync rüber. Die Datenbank exportierst du mit mysqldump oder phpMyAdmin und importierst sie beim neuen Hoster. Bei WordPress musst du anschließend die Zugangsdaten in der wp-config.php an die neue Datenbank anpassen.
Achte beim Export auf den Zeichensatz. Wenn alte Tabellen noch in latin1 laufen und neu als utf8mb4 importiert werden, oder umgekehrt, siehst du hinterher kaputte Umlaute in Beiträgen und Kommentaren. Bei einer deutschsprachigen Seite fällt das sofort auf.
Typischer Fehler: Absolute Pfade, die auf den alten Server zeigen. Die stecken gern in Cache-Plugins, in der .htaccess, in Sicherheits-Plugins oder in selbstgeschriebenen Skripten. Die Seite lädt dann, aber der Cache schreibt ins Leere oder ein Plugin wirft Fehler im Hintergrund. Leere nach dem Import alle Caches und such im Code nach dem alten Serverpfad.
4. Testen, bevor das DNS umgestellt ist
Hier entscheidet sich, ob der Umzug ruhig läuft. Du willst die Seite auf dem neuen Server unter ihrer echten Domain sehen, während der Rest der Welt noch auf dem alten Server landet. Das geht über die hosts-Datei deines Rechners. Unter macOS und Linux liegt sie unter /etc/hosts, unter Windows im Systemordner unter drivers und etc. Dort trägst du die neue IP-Adresse zusammen mit deiner Domain ein. Ab dann löst nur dein Rechner die Domain auf den neuen Server auf.
Klick dich jetzt systematisch durch: Startseite, ein paar Beiträge, Kategorieseiten, Suche, Kontaktformular, Login ins Backend, bei Shops den Checkout bis kurz vor die Zahlung. Prüfe im Fehlerlog des neuen Servers, ob PHP-Warnungen auftauchen, die vorher nicht da waren. Oft liegt es an einer anderen PHP-Version oder einer fehlenden Erweiterung.
Typischer Fehler: Statt der hosts-Datei wird eine temporäre Subdomain des Hosters zum Testen genutzt. Bei WordPress heißt das: Die Site-URL wird umgeschrieben und vor dem Livegang wieder zurück. Dabei gehen serialisierte Daten in der Datenbank kaputt, wenn man ein simples Suchen-und-Ersetzen per SQL macht. Außerdem kann Google die Testadresse indexieren, wenn sie nicht gesperrt ist. Die hosts-Methode vermeidet beides.
5. Das SSL-Zertifikat vorher klären
Viele Hoster stellen kostenlose Zertifikate über Let's Encrypt aus. Die übliche Validierung prüft aber, ob die Domain bereits auf den neuen Server zeigt. Vor der DNS-Umstellung klappt das also nicht. Daraus folgt eine kurze Phase, in der Besucher, die schon auf dem neuen Server landen, eine Zertifikatswarnung sehen können.
Es gibt drei Wege, das zu umgehen. Manche Hoster können ein Zertifikat vorab per DNS-Validierung ausstellen. Alternativ lässt sich ein vorhandenes, noch gültiges Zertifikat samt privatem Schlüssel vom alten Server übernehmen, sofern du Zugriff darauf hast. Oder du hältst das Zeitfenster so kurz, dass das Zertifikat wenige Minuten nach der Umstellung ausgestellt ist. Frag beim neuen Hoster nach, welcher Weg dort geht, bevor du umstellst.
