Hoster wechseln? Wir ziehen Ihre Website kostenlos um

Der Umzug, in der Reihenfolge, in der er wirklich abläuft

Ein Umzug scheitert selten an der Technik, fast immer an der Reihenfolge. Der TTL, der erst nach der Umschaltung gesenkt wird; das MX, das geändert wird, bevor die Postfächer existieren; der alte Vertrag, der gekündigt wird, bevor jemand die Protokolle gelesen hat — jede dieser Vertauschungen kostet einen halben Tag. Hier die vollständige Abfolge, von der ersten Bestandsaufnahme bis zur Kündigung.

Die Tagesangaben gelten für eine gewöhnliche Website oder einen gewöhnlichen Server. Ein Shop in der Hochsaison oder ein Bestand von mehreren Dutzend Postfächern bedeutet, dieselben Schritte zu strecken — nicht, welche auszulassen.

1. T-7 — Aufnehmen, was tatsächlich läuft. Die Websites und ihre Domains, die eingesetzte PHP-Version, die Datenbanken und ihre Engine, die Postfächer und ihr Volumen, die geplanten Aufgaben, die Zertifikate und ihr Ablaufdatum, sowie alle Dienste Dritter, die Ihre aktuelle IP-Adresse kennen (Zahlungsanbieter, SMTP-Relay, Webhooks). Diese Liste, nicht Ihr Gedächtnis, ist am Ende die Prüfgrundlage.
2. T-7 — Das Ziel am realen Verbrauch bemessen, nicht am Tarif, den Sie heute bezahlen. Messen Sie den tatsächlich belegten Speicher, die Größe der Datenbanken, den wirklich genutzten Arbeitsspeicher. Eine Website, die in 6 GB passt, braucht keinen 200-GB-Tarif, nur weil der alte ihn auswies.
3. T-5 — Das neue Hosting eröffnen und die Kopie aufbauen. Dateien und Datenbanken werden ein erstes Mal vollständig übertragen, ohne dass sich öffentlich etwas ändert. Diese Kopie muss nicht sekundenaktuell sein: Sie dient dem Nachweis, dass die Anwendung startet.
4. T-3 — Änderungen auf dem alten Server einfrieren. Keine neuen Beiträge, keine Erweiterungs-Updates, keine Theme-Anpassungen bis zur Umschaltung. Alles, was danach geschrieben wird, muss von Hand nachsynchronisiert werden.
5. T-2 — Den TTL senken, bei allen Einträgen, die sich ändern werden, auf 300 Sekunden. Dieser Schritt erfolgt mindestens 48 Stunden vor der Umschaltung, aus dem im DNS-Abschnitt erläuterten Grund. Es ist der Schritt, der am häufigsten zu spät gemacht wird — und der einzige, der sich nicht nachholen lässt.
6. T-1 — Die Kopie unter ihrem echten Domainnamen testen, ohne das öffentliche DNS anzufassen: Ändern Sie die hosts-Datei Ihres Rechners, sodass die Domain auf die neue IP-Adresse zeigt. Sie sehen dann genau das, was Ihre Besucher sehen werden — absolute Links und Weiterleitungen eingeschlossen.
7. T-1 — Die Ziel-DNS-Zone vorbereiten, ohne sie zu veröffentlichen. Notieren Sie die exakten Werte der Einträge A, AAAA, MX, SPF, DKIM, DMARC und CAA, die Sie setzen werden. Vorher aufgeschrieben, müssen sie am Umschalttag nicht improvisiert werden, wenn die Website bereits halb umgezogen ist.
8. Umschalttag — Die Differenz nachsynchronisieren. Ein zweiter Kopierlauf überträgt nur, was sich seit T-5 geändert hat, danach ersetzt ein frischer Datenbank-Export den vorherigen. Dieser kurze zweite Lauf bestimmt das tatsächliche Ausfallfenster.
9. Umschalttag — Die neuen DNS-Einträge veröffentlichen. Mit einem zwei Tage zuvor gesetzten TTL von 300 Sekunden greift die Umschaltung für die meisten Besucher innerhalb von Minuten, nicht innerhalb von vierundzwanzig Stunden.
10. Umschalttag — Die Prüfungen abarbeiten, in der unten angegebenen Reihenfolge. Haken Sie nichts aus dem Gedächtnis ab: Öffnen Sie die Liste und testen Sie wirklich.
11. T+1 — Den TTL wieder anheben, auf seinen üblichen Wert; 3600 Sekunden genügen in den meisten Fällen. Ein dauerhaft kurzer TTL vervielfacht ohne Nutzen die Anfragen an Ihre Nameserver.
12. T+7 — Den alten Vertrag kündigen, nicht früher. Warten Sie, bis Sie Post in den neuen Postfächern erhalten, beim neuen Hoster eine Sicherung zurückgespielt und die Fehlerprotokolle gelesen haben. Eine Kündigung löscht die Daten oft noch am selben Tag.

Was übertragen wird — und womit

Ein Hosting ist kein einzelner Block, sondern ein Stapel von Bestandteilen, die sich jeweils mit ihrem eigenen Werkzeug bewegen. Sie getrennt zu behandeln verhindert den häufigsten Fehler: die Dateien zu kopieren und zu hoffen, der Rest folge von selbst.

• Die Dateien. rsync über SSH, wenn beide Seiten es erlauben, sonst SFTP. Zwei Durchläufe sind besser als einer: ein vollständiger, während die Website läuft, und ein zweiter kurz vor der Umschaltung, der nur die Unterschiede aufnimmt. Prüfen Sie danach, ob Rechte, Eigentümer und symbolische Verknüpfungen überlebt haben — ein falsch eingestellter FTP-Client bügelt sie kommentarlos platt.
• Die Datenbanken. mysqldump --single-transaction --quick für MySQL und MariaDB, pg_dump -Fc für PostgreSQL. Notieren Sie Zeichensatz und Kollation der Quelldatenbank und legen Sie die Zieldatenbank mit denselben an: genau dieses Detail verwandelt Umlaute nach dem Import in unlesbare Zeichen.
• Die Panel-Sicherung. Wird Ihr aktuelles Hosting über ein Panel verwaltet, ist dessen integrierter Export — Dateien, Datenbanken, Postfächer und Einstellungen in einem Archiv — oft der sicherste Weg. Unsere Webhosting-Tarife enthalten das Plesk-Panel, das eigene Werkzeuge für Sicherung und Rückspielung mitbringt.
• Das Festplatten-Abbild, für einen ganzen Server. Auf einem VPS oder dedizierten Server gibt es zwei Wege: die Platte so kopieren, wie sie ist (Abbild als raw oder qcow2, oder blockweise Kopie aus einem Rettungssystem), oder mit einem sauberen System beginnen und die Anwendung neu darauf ausrollen. Gibt Ihr aktueller Hoster keinen Zugriff auf das Abbild, bleibt nur der zweite Weg — und bei einem mehrere Jahre alten System empfehlen wir ihn ohnehin.
• Die Zertifikate. Verschieben Sie sie nicht: Ein Let's-Encrypt-Zertifikat wird auf dem neuen Server in Sekunden neu ausgestellt, sobald die Domain dorthin zeigt. Bezahlen Sie ein Zertifikat mit erweiterter Validierung, exportieren Sie den privaten Schlüssel vor der Kündigung, sonst müssen Sie es neu kaufen.
• Die Postfächer. Eine IMAP-Synchronisation kopiert Nachrichten, Ordnerstruktur und Gelesen-Status von einem Server auf den anderen. Führen Sie sie zweimal aus, wie bei den Dateien: einmal vor der Umschaltung, einmal danach, um die zwischenzeitlich eingegangenen Nachrichten nachzuholen.
• Geplante Aufgaben und Dienste. cron-Jobs, systemd-Timer, Warteschlangen und Dauerprozesse stehen in keiner Website-Sicherung. Übertragen Sie sie von Hand und prüfen Sie danach, ob sie nach der Umschaltung tatsächlich laufen — nicht nur, ob sie eingetragen sind.
• Die Geheimnisse. Autorisierte SSH-Schlüssel, API-Token, Anwendungs-Schlüssel zur Verschlüsselung, Dienst-Zugangsdaten: Sie liegen oft außerhalb des Website-Verzeichnisses und gehen lautlos verloren. Eine Anwendung, die startet, aber ihre gespeicherten Daten nicht mehr entschlüsselt, ist fast immer ein auf dem alten Server zurückgelassener Schlüssel.

DNS: was vorher vorbereitet wird, was am Umschalttag wechselt

DNS ist der Teil des Umzugs, den Sie nicht allein steuern. Zwischen Ihrer Zone und Ihren Besuchern stehen Resolver, die die alte Antwort genau so lange im Speicher halten, wie Sie es ihnen angekündigt haben. Diese Dauer heißt TTL, und sie ist der einzige Hebel, mit dem sich die Umschaltung verkürzen lässt.

Daher die Regel: den TTL vorher senken, nie mittendrin. Steht Ihr TTL heute auf 86400 Sekunden und Sie setzen ihn am Morgen der Umschaltung auf 300, halten sich Resolver mit dem alten Wert weitere vierundzwanzig Stunden daran. Senken Sie ihn 48 Stunden früher, läuft der alte Wert von selbst ab, und die Umschaltung wird zur Sache von Minuten.

1. 48 Stunden vorher: den TTL auf 300 Sekunden senken, bei jedem Eintrag, den Sie ändern werden — mindestens A und AAAA, dazu MX und zugehörige CNAME, falls auch die Mail umzieht. Der TTL wird in der DNS-Zone gesetzt, dort wo diese Zone liegt: in den meisten Fällen bei Ihrem Registrar.
2. Die aktuelle Zone festhalten, bevor Sie sie anfassen. Eine Abfrage dig ihredomain.de ANY oder ein Zonen-Export aus der Oberfläche liefert den Ausgangszustand. Bewahren Sie ihn auf: Er ist Ihr Rückweg, falls etwas schiefgeht.
3. A und AAAA. Der A-Eintrag trägt die IPv4-Adresse des neuen Hostings, AAAA seine IPv6-Adresse, sofern vorhanden. Vergessen Sie weder www noch die tatsächlich genutzten Subdomains: ein webmail, eine api, eine Vorproduktion. Vergessen werden genau die, die man selbst nie aufruft.
4. MX: der Eintrag, den man vergisst. Er benennt den Server, der Ihre Post empfängt, und ist unabhängig von dem, der die Website hostet. Bleibt Ihre Mail, wo sie ist, fassen Sie ihn nicht an — das ist der klassische Fehler der Umschaltung nach dem Motto „alle IPs der Zone ersetzen“, der die Post an einen Server umleitet, der sie nicht kennt. Zieht die Mail mit um, ändern Sie den MX erst, wenn die Postfächer angelegt und synchronisiert sind.
5. SPF. Ein einzelner TXT-Eintrag, der die Server auflistet, die in Ihrem Namen senden dürfen. Verweist er weiter auf das alte Hosting, landen Nachrichten vom neuen Server im Spam oder werden abgewiesen. Tragen Sie den neuen Server vor der Umschaltung ein, entfernen Sie den alten nach bestätigtem Umzug — und behalten Sie genau einen SPF-Eintrag: zwei heben sich gegenseitig auf.
6. DKIM. Die Signatur erzeugt der sendende Server; geprüft wird sie gegen einen öffentlichen Schlüssel, der unter einem Selektor in Ihrer Zone veröffentlicht ist. Veröffentlichen Sie den Selektor des neuen Servers vor der Umschaltung und lassen Sie den alten einige Tage stehen: Zwei Selektoren koexistieren problemlos, anders als beim SPF.
7. DMARC. Er sagt Empfängern, was mit Nachrichten geschehen soll, die die vorigen Prüfungen nicht bestehen. Bleiben Sie während eines Umzugs bei p=none mit einer Report-Adresse: Sie beobachten, ohne etwas zu zerstören, und verschärfen die Richtlinie, sobald SPF und DKIM auf beiden Seiten sauber sind.
8. CAA, falls vorhanden. Dieser Eintrag listet die Zertifizierungsstellen, die für Ihre Domain ausstellen dürfen. Nennt er die Stelle Ihres neuen Hosters nicht, scheitert die Ausstellung lautlos und die Website bleibt auf ungültigem HTTPS, ohne dass irgendwo eine klare Fehlermeldung erscheint.
9. Reverse DNS (PTR). Er wird nicht in Ihrer Zone gesetzt, sondern auf der IP-Adresse, also beim Hoster, dem sie gehört. Er zählt, sobald Ihr Server selbst Mail versendet: Ohne PTR, der zum angekündigten Namen passt, weist ein Teil der Empfänger die Nachricht ab. Bei uns lässt sich der Reverse DNS auf Anfrage anpassen.

Die tatsächliche Ausfallzeit — und wie sie fast auf null sinkt

Die Unterbrechung, die die meisten fürchten — „meine Website ist während der DNS-Propagation nicht erreichbar“ — gibt es nicht, wenn beide Hostings gleichzeitig antworten. Während der Propagation landet ein Teil der Besucher auf dem alten Server, ein Teil auf dem neuen, und beide liefern die Website aus. Niemand sieht einen Fehler.

Das eigentliche Fenster liegt woanders: Es ist der Moment, in dem die Website auf einer Seite noch Schreibvorgänge annimmt, während die Datenbank bereits exportiert wurde. Eine in diesem Fenster aufgegebene Bestellung wird auf dem alten Server gespeichert und wird auf dem neuen nie existieren. Ausfallzeit zu verringern heißt also, dieses Schreibfenster zu verkleinern — nicht, gegen das DNS zu kämpfen.

• Visitenkarten- oder statische Website: gar keine Unterbrechung. Serverseitig wird nichts geschrieben, die Kopie kann am Vortag entstehen, und die Umschaltung erfordert keine besondere Vorsicht.
• Website mit Datenbank: wenige Minuten. Website auf Nur-Lesen oder Wartung setzen, Datenbank exportieren, importieren, umschalten. Bei einer gewöhnlichen Website passt das in fünf bis fünfzehn Minuten, geplant in einer Randzeit.
• Onlineshop: dasselbe Fenster, aber angekündigt. Informieren Sie das Team, wählen Sie eine wirklich ruhige Zeit — oft früh am Morgen — und vergleichen Sie danach die letzten Bestellungen auf beiden Seiten, bevor Sie den alten Server als entbehrlich betrachten.
• E-Mail: keine Unterbrechung, aber eine Überlappungsphase. Solange das MX nicht überall propagiert ist, treffen weiter Nachrichten auf dem alten Server ein. Behalten Sie den Zugang einige Tage und führen Sie nach der Umschaltung eine zweite IMAP-Synchronisation durch: Das verhindert die verlorene Nachricht.
• Anwendung mit Warteschlange oder Hintergrundjobs: Warteschlange vorher leeren. Ein Job, der zum Exportzeitpunkt läuft, geht verloren oder wird doppelt ausgeführt. Stoppen Sie die Verbraucher, lassen Sie die Warteschlange leerlaufen, exportieren Sie danach.

Nach der Umschaltung: die Prüfungen, der Reihe nach

Diese Liste wird am Umschalttag von oben nach unten abgearbeitet. Die Reihenfolge ist kein Schmuck: Jeder Punkt setzt den vorigen als geprüft voraus, und ein Fehlschlag bei Punkt 2 macht alle folgenden unauswertbar.

1. Die DNS-Auflösung. Fragen Sie einen öffentlichen Resolver und den Ihres Zugangsanbieters ab: Beide müssen die neue Adresse liefern. Solange das nicht der Fall ist, beweist das, was Ihr Browser zeigt, gar nichts.
2. Die Website antwortet, von der richtigen Maschine. curl -I https://ihredomain.de muss einen 200er liefern; im Zweifel erlaubt curl --resolve, die Adresse zu erzwingen und beide Server nebeneinander zu vergleichen.
3. Das Zertifikat. Gültig, auf den richtigen Namen, und auch www abdeckend. Rechnen Sie nach der Propagation mit einigen Minuten für die automatische Ausstellung; dauert es länger als eine Stunde, sehen Sie beim CAA-Eintrag nach.
4. Die Weiterleitungen. HTTP auf HTTPS und www auf die nackte Domain oder umgekehrt — aber nur in eine Richtung, als 301 und nicht als 302, und ohne Kette aus zwei aufeinanderfolgenden Weiterleitungen.
5. Die tiefen Seiten. Die Startseite funktioniert fast immer. Öffnen Sie fünf oder sechs zufällig gewählte interne URLs: Dort zeigen sich verlorene Rewrite-Regeln und absolute Links, die noch auf die alte Domain verweisen.
6. Die Formulare. Senden Sie eine Testnachricht über das Kontaktformular und prüfen Sie, ob sie ankommt. Ein Formular, das „danke“ anzeigt und nichts verschickt, ist der häufigste Fehler nach einem Umzug.
7. Die Zahlung, falls vorhanden. Eine Testbestellung im Sandbox-Modus, bis zur Bestätigung und der zugehörigen E-Mail. Prüfen Sie dabei, ob der Zahlungsanbieter eine IP-Freigabeliste führt, die noch aktualisiert werden muss.
8. Der ausgehende Mailverkehr. Senden Sie eine Nachricht von der Website an eine externe Adresse, öffnen Sie den Kopf der empfangenen Nachricht und lesen Sie die SPF- und DKIM-Ergebnisse. Beide müssen auf „pass“ stehen; andernfalls zurück zum DNS-Abschnitt.
9. Der eingehende Mailverkehr. Schreiben Sie von außen an eine der umgezogenen Adressen und beobachten Sie das alte Postfach noch einige Tage.
10. Die geplanten Aufgaben. Warten Sie einen Durchlauf ab und prüfen Sie dessen Spur, statt sich damit zu begnügen, dass die Zeile in der Aufgabentabelle steht.
11. Die Fehlerprotokolle. Lesen Sie sie die ersten 48 Stunden. Eine fehlende Erweiterung oder ein fest verdrahteter absoluter Pfad zeigt sich dort sofort, meist bevor sich jemand beschwert.
12. Eine erste Sicherung beim neuen Hoster. Erstellen Sie sie und spielen Sie sie einmal zurück, um zu prüfen, dass sie brauchbar ist. Das ist die Bedingung, bevor Sie den alten Vertrag kündigen.

Die Fallen, die einen ganzen Tag kosten

• Der TTL, am selben Tag gesenkt. Er bringt nichts: Der alte, lange Wert liegt bereits im Cache. Ein Teil Ihrer Besucher bleibt den ganzen Tag auf dem alten Server, und Sie suchen eine Störung, die es nicht gibt.
• Das MX, aus Reflex ersetzt. „Alle IPs der Zone“ zu ersetzen nimmt die Post mit der Website mit. Zieht die Mail nicht um, bleibt das MX unangetastet.
• Der SPF, der auf dem alten Server stehen bleibt. Die Website läuft, die E-Mails gehen raus, und niemand bekommt sie — oder sie landen im Spam. Es ist der Fehler, der sich im Nachhinein am schwersten diagnostizieren lässt, weil sichtbar nichts fehlschlägt.
• Der alte Vertrag, zu früh gekündigt. Die Kündigung löscht die Daten, oft noch am selben Tag, und nimmt die nach der Umschaltung eingegangenen Nachrichten sowie die einzige noch frische Kopie der Dateien mit.
• Das Zertifikat, angefordert bevor das DNS zeigt. Die Validierung scheitert, die Website erscheint mit einer Sicherheitswarnung, und der Browser merkt sich den Fehler. Warten Sie die Propagation ab und fordern Sie die Ausstellung danach an.
• Die robots.txt der Vorproduktion, unverändert mitkopiert. Ein aus der Testumgebung geerbtes Disallow: / deindexiert die Website binnen Tagen. Lesen Sie diese Datei direkt nach der Umschaltung noch einmal.
• Die PHP-Version, die sich ungefragt ändert. Neues Hosting stellt oft standardmäßig eine neuere Version bereit. Bilden Sie zuerst die Ausgangsversion nach und aktualisieren Sie danach, wenn der Umzug hinter Ihnen liegt.
• Cache und CDN vergessen. Steht ein CDN vor Ihrer Website, ist nicht der öffentliche A-Eintrag zu ändern, sondern der im CDN hinterlegte Ursprung. Und leeren Sie den Cache nach der Umschaltung, sonst liefern Sie weiter die alte Website aus.
• IP-Freigabelisten bei Dritten. Zahlungsanbieter, SMTP-Relay, Partner-API, entfernte Datenbank: Alles, was nach IP-Adresse filtert, muss die neue vor der Umschaltung kennen, nicht danach.

Einen Server umzuziehen ist etwas anderes, als eine Website umzuziehen

Die beiden Vorgänge teilen sich einen Namen und sonst wenig. Eine Website umziehen heißt: Dateien, eine Datenbank und Postfächer auf ein bereits administriertes Hosting bringen — System, Sicherheitsupdates und Panel kommen mit. Genau das deckt der von uns übernommene Umzug auf unsere Webhosting-Tarife ab.

Einen Server umziehen heißt: eine Maschine neu bauen — System, Pakete, Dienste, Firewall, Benutzer, Zertifikate, Sicherungen. Auf einem KVM-VPS erhalten Sie eine dedizierte IPv4-Adresse, root-Zugang per SSH und ein Panel mit Neustart, Neuinstallation, Snapshots und Konsole. Diese Konsole zählt am Umschalttag: Sie ist es, die Ihnen die Kontrolle zurückgibt, wenn eine Firewall-Regel Ihnen die SSH-Tür zuschlägt.

Unser Rat, wenn die Ausgangsmaschine mehrere Jahre alt ist: Kopieren Sie die Platte nicht, bauen Sie neu. Sonst erben Sie Einstellungen, deren Grund niemand mehr kennt. Erstellen Sie unmittelbar vor jedem heiklen Schritt einen Snapshot — das kostet keine Zeit und verwandelt einen Fehler in ein simples Zurücksetzen. Für eine komplette Infrastruktur beschreiben Sie uns den Bestand in einem Angebot: Wir planen die Abfolge mit Ihnen, statt eine Frist zu nennen, bevor wir die Maschine gesehen haben.

Die Suchmaschinen-Sichtbarkeit während des Umzugs

Den Hoster zu wechseln und dabei Domain und URLs beizubehalten hat für sich genommen keinen Einfluss auf das Ranking: Für eine Suchmaschine ändert sich nur die IP-Adresse, und die ist kein Rankingfaktor. Die nach einem Umzug beobachteten Einbrüche haben fast immer eine andere Ursache.

• URLs, die sich ohne Weiterleitung ändern. Ändert sich die Struktur gleichzeitig mit dem Hosting, erstellen Sie die Zuordnungstabelle vor der Umschaltung und liefern Sie 301 aus, nicht 302. Behalten Sie sie mindestens zwölf Monate.
• Eine ungewollte Indexierungssperre. robots.txt, X-Robots-Tag-Header, ein aus einer Testumgebung geerbtes noindex: Prüfen Sie alle drei noch am selben Tag.
• Eine langsamere Website als vorher. Anwendungs-Cache und Komprimierung müssen auf dem neuen Hosting oft erneut aktiviert werden. Messen Sie die Antwortzeit vorher und nachher, statt sie zu vermuten.
• Eine defekte Sitemap. Prüfen Sie, dass sie erreichbar und aktuell ist, und lassen Sie die Suchmaschine von selbst zurückkommen. Die Crawl-Frequenz stellt sich in wenigen Tagen wieder ein; es gibt nichts zu erzwingen, solange die URLs unverändert sind.