{"id":878,"date":"2026-09-03T05:33:56","date_gmt":"2026-09-03T03:33:56","guid":{"rendered":"https:\/\/gsweb.services\/2026\/09\/03\/domain-umzug-ohne-ausfall\/"},"modified":"2026-09-03T05:33:56","modified_gmt":"2026-09-03T03:33:56","slug":"domain-umzug-ohne-ausfall","status":"publish","type":"post","link":"https:\/\/gsweb.services\/en\/2026\/09\/03\/domain-umzug-ohne-ausfall\/","title":{"rendered":"How to properly plan a domain transfer without downtime"},"content":{"rendered":"

Ein abgelaufener Transfer-Code, ein zu fr\u00fch umgestellter Nameserver oder ein \u00fcbersehener Mail-Eintrag reichen aus, damit Website, Shop oder E-Mail-Kommunikation nicht mehr erreichbar sind. Ein Domain Umzug ohne Ausfall<\/strong> ist deshalb keine reine Verwaltungsaufgabe. Er ist ein geplanter Eingriff in eine gesch\u00e4ftskritische Infrastruktur, bei dem Zust\u00e4ndigkeiten, DNS, Anwendungen und Kommunikation zusammenpassen m\u00fcssen.<\/p>\n

F\u00fcr kleine und mittlere Unternehmen geht es dabei um mehr als die Domain selbst. Unter einer Adresse laufen oft mehrere Dienste: die Unternehmenswebsite, ein Onlineshop, E-Mail-Postf\u00e4cher, API-Schnittstellen, VPN-Zug\u00e4nge oder externe SaaS-Dienste. Wer den Umzug sauber vorbereitet, kann den Registrar wechseln und gleichzeitig die Erreichbarkeit dieser Dienste absichern.<\/p>\n

Was bei einem Domain Umzug wirklich umzieht<\/h2>\n

Zun\u00e4chst sollte klar sein, welcher Umzug \u00fcberhaupt geplant ist. Ein Registrarwechsel \u00fcbertr\u00e4gt die Verwaltung der Domain von einem Anbieter zum anderen. Webspace, Server, Postf\u00e4cher und DNS-Zone k\u00f6nnen dabei unver\u00e4ndert bleiben. In diesem Fall ist ein Ausfall h\u00e4ufig vermeidbar, wenn die bestehenden Nameserver weiter genutzt werden.<\/p>\n

Anders sieht es aus, wenn zus\u00e4tzlich das Hosting, der Mailserver oder der DNS-Provider wechselt. Dann betrifft der Umzug nicht nur die Domainregistrierung, sondern auch die technische Auslieferung der Dienste. Die gr\u00f6\u00dfte Fehlerquelle ist die Annahme, dass ein Domaintransfer automatisch alle Einstellungen mitnimmt. DNS-Zonen, E-Mail-Postf\u00e4cher, Datenbanken, Zertifikate und Weiterleitungen werden in der Regel nicht automatisch \u00fcbertragen.<\/p>\n

Die sichere Reihenfolge lautet daher: Erst die Zielumgebung vollst\u00e4ndig aufbauen und testen, dann die DNS-Steuerung umstellen und erst anschlie\u00dfend den Registrarwechsel durchf\u00fchren, sofern dieser notwendig ist. In manchen Projekten ist es sinnvoll, beide Schritte zeitlich zu trennen. Das reduziert die Komplexit\u00e4t und erleichtert die Fehlersuche.<\/p>\n

Domain Umzug ohne Ausfall beginnt mit einer Bestandsaufnahme<\/h2>\n

Vor dem ersten Auftrag braucht das verantwortliche Team ein vollst\u00e4ndiges Bild der aktuellen Konfiguration. Entscheidend ist nicht, was auf der Website sichtbar ist, sondern welche Dienste die Domain im Hintergrund verwendet. Gerade historisch gewachsene Umgebungen enthalten h\u00e4ufig Eintr\u00e4ge, die niemand mehr aktiv dokumentiert hat, aber noch produktiv ben\u00f6tigt werden.<\/p>\n

Erfassen Sie mindestens die aktuellen Nameserver, alle DNS-Eintr\u00e4ge, den Registrar und die Laufzeit der Domain. Pr\u00fcfen Sie au\u00dferdem, ob ein Transfer-Lock aktiv ist, welcher Auth-Code oder welches AuthInfo-Verfahren f\u00fcr die jeweilige Domainendung erforderlich ist und wer Zugriff auf das Inhaberkonto besitzt. Bei einigen Endungen gelten zus\u00e4tzliche Fristen oder Freigabeprozesse. Diese sollten vor der Terminplanung gekl\u00e4rt sein.<\/p>\n

Besondere Aufmerksamkeit verdienen die Eintr\u00e4ge f\u00fcr E-Mail. Dazu geh\u00f6ren MX-Records sowie SPF-, DKIM- und DMARC-Eintr\u00e4ge. Fehlt hier nur ein Detail, kann die Website weiterhin funktionieren, w\u00e4hrend E-Mails verz\u00f6gert zugestellt, abgewiesen oder als verd\u00e4chtig eingestuft werden. Auch Subdomains wie mail, shop, app, vpn oder autodiscover m\u00fcssen ber\u00fccksichtigt werden.<\/p>\n

Eine belastbare Dokumentation enth\u00e4lt dar\u00fcber hinaus Weiterleitungen, CAA-Eintr\u00e4ge f\u00fcr Zertifikate, TXT-Verifizierungen externer Dienste und gegebenenfalls SRV-Records. Wer nur A- und MX-Records kopiert, \u00fcbersieht oft genau die Konfiguration, die sp\u00e4ter zu schwer erkl\u00e4rbaren St\u00f6rungen f\u00fchrt.<\/p>\n

DNS richtig vorbereiten: Zeit ist ein Sicherheitsfaktor<\/h2>\n

DNS-\u00c4nderungen werden nicht \u00fcberall gleichzeitig sichtbar. Resolver und Endger\u00e4te speichern Antworten f\u00fcr die in der Zone definierte TTL-Zeit. Deshalb kann eine Umstellung je nach Konfiguration noch Stunden nachwirken. Eine niedrige TTL kurz vor dem Wechsel kann hilfreich sein, aber sie ist keine Garantie f\u00fcr eine sofortige globale Aktualisierung. Manche Netze oder Anwendungen cachen l\u00e4nger als vorgesehen.<\/p>\n

Senken Sie die TTL kritischer Eintr\u00e4ge einige Tage vor der geplanten Umstellung auf einen angemessenen Wert, etwa 300 bis 900 Sekunden. Wichtig ist der zeitliche Vorlauf: Die bisher h\u00f6here TTL muss erst aus den Caches verschwinden. Wer die TTL erst f\u00fcnf Minuten vor dem Wechsel reduziert, gewinnt praktisch nichts.<\/p>\n

Die Zielzone sollte vorab vollst\u00e4ndig angelegt sein. Vergleichen Sie jeden Record mit der laufenden Zone und pr\u00fcfen Sie die Aufl\u00f6sung \u00fcber verschiedene Resolver. Falls ein DNS-Provider-Wechsel vorgesehen ist, darf die neue Zone nicht erst nach der Delegation entstehen. Sie muss bereits vollst\u00e4ndig, fehlerfrei und \u00fcber die vorgesehenen Nameserver erreichbar sein.<\/p>\n

DNSSEC verlangt zus\u00e4tzliche Sorgfalt. Bei signierten Zonen m\u00fcssen die DS-Eintr\u00e4ge bei Registry und Registrar zur neuen Signatur passen. Eine falsche oder veraltete DNSSEC-Konfiguration kann dazu f\u00fchren, dass validierende Resolver die gesamte Domain als nicht erreichbar bewerten. Wenn kein eingespielter Prozess f\u00fcr DNSSEC vorhanden ist, sollte dieser Schritt durch erfahrene Administratoren begleitet und mit einem klaren Rollback-Szenario geplant werden.<\/p>\n

Website und Anwendungen parallel betreiben<\/h2>\n

Die neue Hosting- oder Serverumgebung<\/a> sollte nicht erst nach dem DNS-Wechsel getestet werden. Legen Sie Anwendungen, Datenbanken, Dateibest\u00e4nde und Konfigurationen vorab an. Bei dynamischen Systemen reicht eine einmalige Datenkopie h\u00e4ufig nicht aus, weil w\u00e4hrend der Vorbereitung neue Bestellungen, Formulareing\u00e4nge oder Inhalte entstehen k\u00f6nnen.<\/p>\n

Je nach Anwendung ist daher eine finale Synchronisation zum Umschaltzeitpunkt n\u00f6tig. Bei einem Onlineshop kann ein kurzes Wartungsfenster f\u00fcr schreibende Vorg\u00e4nge sinnvoller sein als das Risiko, Bestellungen oder Kundendaten zwischen zwei Datenst\u00e4nden zu verlieren. Das Ziel ist nicht, um jeden Preis jede technische \u00c4nderung unsichtbar zu machen. Das Ziel ist, die gesch\u00e4ftliche Funktion zuverl\u00e4ssig zu erhalten.<\/p>\n

Testen Sie die Zielumgebung vor der \u00f6ffentlichen Umschaltung mit einer tempor\u00e4ren Adresse oder \u00fcber eine lokale Hosts-Datei. Pr\u00fcfen Sie dabei nicht nur die Startseite, sondern auch Login, Kontaktformulare, Warenkorb, Zahlungsabl\u00e4ufe, Dateiuploads, Schnittstellen und geplante Hintergrundprozesse. Kontrollieren Sie, ob das TLS-Zertifikat f\u00fcr alle verwendeten Hostnamen g\u00fcltig ist. Ein Zertifikat nur f\u00fcr www hilft nicht, wenn Kunden die Domain ohne www aufrufen.<\/p>\n

Auch Weiterleitungen geh\u00f6ren in den Test. Eine falsche Umleitung kann einzelne Seiten unzug\u00e4nglich machen, Endlosschleifen erzeugen oder die Auffindbarkeit in Suchmaschinen beeintr\u00e4chtigen. Bei komplexen Projekten ist ein Abgleich der HTTP-Statuscodes ebenso sinnvoll wie ein Blick in die Server- und Anwendungslogs.<\/p>\n

E-Mail nicht als Nebensache behandeln<\/h2>\n

E-Mail ist bei vielen Unternehmen der kritischste Dienst. Selbst wenn eine Website f\u00fcr kurze Zeit eingeschr\u00e4nkt w\u00e4re, kann ein gest\u00f6rter Mailverkehr Angebote, Bestellungen, Supportanfragen und interne Abstimmungen direkt treffen. Bleibt der bestehende Mailserver beim Registrarwechsel unver\u00e4ndert, m\u00fcssen seine DNS-Eintr\u00e4ge unver\u00e4ndert in der neuen Zone vorhanden sein.<\/p>\n

Wechselt auch die Mailplattform, braucht es eine \u00dcbergangsplanung. Postf\u00e4cher m\u00fcssen migriert, Benutzerzug\u00e4nge kommuniziert und mobile Ger\u00e4te gegebenenfalls neu eingerichtet werden. Wichtig ist zudem, dass SPF, DKIM und DMARC bereits vor dem Versand \u00fcber die neue Plattform korrekt eingerichtet sind. Andernfalls funktionieren ausgehende Mails zwar technisch, erreichen Empf\u00e4nger aber m\u00f6glicherweise nicht zuverl\u00e4ssig.<\/p>\n

Planen Sie nach der DNS-\u00c4nderung einen kontrollierten Versand und Empfang mit mehreren externen Empf\u00e4ngern. Pr\u00fcfen Sie nicht nur eine Adresse innerhalb der eigenen Organisation. Unterschiedliche Mailprovider bewerten Authentifizierung und Reputationssignale unterschiedlich.<\/p>\n

Der Umschalttag braucht Verantwortlichkeiten und einen R\u00fcckweg<\/h2>\n

Ein geplanter Wechsel au\u00dferhalb gesch\u00e4ftskritischer Zeiten reduziert den Druck, ersetzt aber keine Vorbereitung. Benennen Sie eine fachlich verantwortliche Person, eine technische Ansprechperson und eine Kontaktm\u00f6glichkeit beim bisherigen sowie beim neuen Provider. Alle Zugangsdaten, Freigaben und Auth-Codes m\u00fcssen vor Beginn vorliegen, nicht erst dann angefordert werden, wenn etwas nicht funktioniert.<\/p>\n

F\u00fcr den eigentlichen Termin hilft ein kurzer, verbindlicher Ablaufplan:<\/p>\n