Domainumzug und TTL: Eine Umschaltung ohne blinde Flecken planen
Bei einem Umzug können Domainverwaltung, DNS, Website und E-Mail an unterschiedliche Stellen wechseln. Nicht jede dieser Änderungen muss gleichzeitig stattfinden. Ein sauberer Ablauf trennt deshalb den Registrartransfer von der Änderung der DNS-Ziele und vom Kopieren der Anwendung. Mit einem dokumentierten Bestand, einem getesteten Ziel und einem vereinbarten Umschaltpunkt lassen sich Abhängigkeiten besser kontrollieren. Eine kurze TTL hilft dabei, ersetzt aber weder Tests noch die Planung für neue Daten während des Wechsels.

In diesem Artikel
Den gewünschten Wechsel genau benennen
Schreibe auf, was sich ändern soll und was bleiben darf. Wird nur das Websiteziel neu gesetzt? Wechselt die öffentliche DNS-Verwaltung? Sollen auch Postfächer, Versanddienste oder die Domainregistrierung umziehen? Diese Fragen bestimmen verschiedene Arbeitsschritte. Ein Transfercode für den Registrar ist zum Beispiel kein Zugang zur Datenbank und kein Nachweis, dass sämtliche bisherigen DNS-Einträge am neuen Ort vorhanden sind.
Erfasse neben der Hauptdomain auch www, weitere Subdomains, Mailziele und Verifikationsdaten. Prüfe, welche Nameserver öffentlich zuständig sind. Eine im Hostingpanel angezeigte Zone kann von der tatsächlich delegierten Zone abweichen. Für die Dokumentation genügt eine übersichtliche Liste aus Name, Typ, Wert und zugehörigem Dienst; Zugangsdaten selbst gehören in eine geschützte Verwaltung.
Das neue Ziel vor der Umschaltung testen
Kopiere Anwendung und Datenbank in die vorgesehene Zielumgebung und verwende einen geeigneten Testzugang. Dabei können Domainabhängigkeiten, Zertifikate und Weiterleitungen eine Rolle spielen. Eine Vorschau unter einer anderen Adresse kann nicht jede Eigenschaft des späteren Live-Aufrufs abbilden. Plane deshalb auch Tests unter dem echten Hostnamen ein, soweit das technisch vorbereitet werden kann.
Kontrolliere Startseite, Inhaltsseiten, Medien, Anmeldung und die geschäftlich wichtigen Aktionen. Prüfe außerdem geplante Jobs und ausgehende Verbindungen. In Testkopien sollten produktive Zahlungen, echte Benachrichtigungen und zeitgesteuerte Aktionen bewusst behandelt werden. Sonst löst eine eigentlich isolierte Prüfung bereits Vorgänge bei Kunden oder angebundenen Diensten aus.
TTL mit dem bisherigen Cache-Zustand planen
Wenn eine niedrigere TTL beim Umschalten helfen soll, muss sie rechtzeitig vorher veröffentlicht werden. Resolver, die eine Antwort noch mit der alten Lebensdauer erhalten haben, dürfen sie zunächst weiterverwenden. Wie lange du warten solltest, hängt daher auch vom vorherigen Wert ab. Das spätere Zurücksetzen eines Eintrags beendet bereits bestehende Verbindungen ebenfalls nicht unmittelbar.
Bei einem Nameserverwechsel kommen weitere Cache-Zustände hinzu. Ändere nicht auf Verdacht gleichzeitig jede TTL und jeden Eintrag. Plane einzelne, nachvollziehbare Schritte und prüfe jeweils die autoritativen Antworten. Negative Caches können bei zuvor nicht vorhandenen Namen ebenfalls relevant sein. Eine pauschale Aussage wie „nach wenigen Minuten ist weltweit alles umgestellt“ ist daher keine belastbare Planung.
Neue Daten während des Wechsels berücksichtigen
Ein Blog ohne neue Beiträge lässt sich anders umschalten als ein Shop mit laufenden Bestellungen. Wenn die Quelle nach dem ersten Kopieren weiter beschrieben wird, entsteht ein Unterschied zum Zielbestand. Kläre deshalb, ob eine kurze Schreibpause, eine abschließende Synchronisation oder ein anwendungsspezifischer Migrationsweg vorgesehen ist. Eine alte Datenbank blind über den neueren Stand zu kopieren kann aktuelle Daten verlieren lassen.
Halte fest, welche Instanz zu welchem Zeitpunkt führend ist. Dazu gehören auch Formulareingänge, Benutzerregistrierungen und Uploads. Bei einem Rückweg muss ebenfalls entschieden werden, wie seit der Umschaltung neu entstandene Daten erhalten bleiben. DNS zurückzustellen ist nur ein technischer Teil dieser Entscheidung; es führt getrennte Datenbestände nicht automatisch wieder zusammen.
Umschalten, beobachten und erst danach aufräumen
Prüfe nach der Änderung Apex und www sowie die verwendeten Adressfamilien. Kontrolliere HTTPS und den vorgesehenen Umgang mit alten URLs. Teste E-Mail getrennt, wenn entsprechende Dienste vom Wechsel betroffen sind. Bewahre vorherige Werte, getestete Sicherungen und die alte Umgebung so lange auf, wie es der vereinbarte Ablauf erfordert. Eine feste allgemeingültige Aufbewahrungszeit ergibt sich daraus nicht.
Dokumentiere schließlich den tatsächlichen Endzustand: aktuelle Verwaltungsstellen, Zieladressen, Sicherungsweg und Zuständigkeiten. Entferne überholte Testkopien und Zugänge erst nach bewusster Freigabe. So bleibt nicht eine zufällige Mischung aus alten Weiterleitungen, doppelten Hintergrundjobs und unklaren Mailwegen zurück, obwohl die Startseite im Browser bereits richtig aussieht.
- Bestand und gewünschte Änderungen getrennt aufschreiben.
- Zielumgebung einschließlich wichtiger Funktionen testen.
- Vorherige TTL und Cache-Wirkung berücksichtigen.
- Schreibpause oder abschließende Datenübernahme vereinbaren.
- Nach der Umschaltung Website und Mail getrennt prüfen.
Quellen & Dokumentation
Primärquellen, geprüft am 3. November 2026. Angaben gelten im beschriebenen Zusammenhang; die konkrete Umgebung und der gebuchte Leistungsumfang bleiben maßgeblich.

