Website umziehen ohne Ausfall: die komplette Checkliste

„Ohne Ausfall" heißt nicht, dass du beim Umschalten besonders schnell bist. Es heißt, dass der Moment des Umschaltens langweilig ist, weil vorher alles steht. Wer den Umzug als einen Termin plant, an dem etwas passiert, hat schon verloren. Wer ihn als einen Termin plant, an dem etwas aufhört zu passieren, kommt durch.

Und noch eine Ehrlichkeit vorweg: Der Ausfall, den alle fürchten, ist die DNS-Propagation. Der Ausfall, den wir in der Praxis sehen, ist die E-Mail. Websites vertragen es, wenn zwei Stunden lang ein Teil der Besucher noch beim alten Anbieter landet, solange dort dieselbe Seite steht. Postfächer vertragen es nicht, wenn Nachrichten in ein System zugestellt werden, das niemand mehr abruft.

Die meisten misslungenen Umzüge scheitern nicht an einem Schritt, der falsch ausgeführt wurde, sondern an einem, der niemandem eingefallen ist. Deshalb steht am Anfang eine Bestandsaufnahme, und die ist länger als „Dateien und Datenbank".

Was offensichtlich ist: Dateien, Datenbanken, PHP-Version samt aktiver Erweiterungen, Cronjobs, Weiterleitungsregeln aus .htaccess oder Serverkonfiguration.

Was regelmäßig vergessen wird: die komplette DNS-Zone, nicht nur der A-Eintrag. In einer gewachsenen Zone stecken TXT-Einträge zur Domainbestätigung für Dienste, an die sich niemand erinnert, DKIM-Selektoren, SPF, ein CAA-Eintrag, Subdomains für Shop, Portal oder Newsletter, manchmal ein SRV-Eintrag für Telefonie. Zieh die Zone einmal vollständig, bevor du sie neu aufbaust.

Was richtig teuer wird, wenn es fehlt: alles, was auf deine IP-Adresse festgenagelt ist. Zahlungsdienstleister mit IP-Freigabe, Schnittstellen von Warenwirtschaft oder Steuerbüro, ein Newsletter-Versender, dessen Zustellbarkeit an deiner Absender-IP hängt. Diese Freigaben laufen nicht über DNS, sie müssen beim jeweiligen Anbieter geändert werden, und dort sitzt selten jemand, der binnen einer Stunde reagiert. Frag die Freigaben zwei Wochen vorher an.

Bevor du einen Termin zusagst, prüfe die formalen Sperren. Bei generischen Endungen wie .com setzt die Transferrichtlinie der ICANN eine Sperre von 60 Tagen nach der Registrierung, nach einem vorherigen Anbieterwechsel und nach einer Änderung des Domaininhabers. Diese Sperre lässt sich nicht abkürzen, wenn sie einmal läuft. Wer also kurz vor dem Umzug „nur schnell" den Inhaber korrigiert, verschiebt damit den Umzug um zwei Monate.

Bei .de gibt es diese Sperre nicht, dafür braucht es das AuthInfo-Passwort und einen KK-Antrag. Das Verfahren, die Fristen und der Weg, wenn der alte Anbieter nicht mitspielt, stehen ausführlich in unserem Beitrag zum formalen Ablauf eines Domainwechsels.

Wichtig für die Planung: Der Anbieterwechsel der Domain und der Umzug der Website sind zwei verschiedene Vorgänge. Die Zuständigkeit für die Domain zu wechseln ändert nicht, wohin sie zeigt. Du kannst die Website vollständig umziehen, ohne die Domain anzufassen, und die Domain später nachholen. In vielen Projekten ist genau das die ruhigere Reihenfolge.

Die neue Umgebung wird fertig, bevor irgendein DNS-Eintrag sich ändert. Fertig heißt: Die Seite läuft dort unter ihrer echten Domain, nicht unter einer Testadresse. Das ist der Unterschied zwischen einem Test, der etwas beweist, und einem, der nur gut aussieht. Eine Anwendung, die über umzug.beispiel.de läuft, verhält sich anders als dieselbe Anwendung unter www.beispiel.de: absolute URLs in der Datenbank, Cookie-Domains, Weiterleitungen von und auf www, Canonicals, OAuth-Rückadressen.

Der Weg dorthin führt über deinen eigenen Rechner, nicht über DNS. Ein Eintrag in der hosts-Datei zeigt nur für dich auf den neuen Server, während für alle anderen weiter der alte gilt. Für Prüfungen ohne Eingriff ins System reicht curl --resolve.

Die letzte Zeile ist der eigentliche Test: Wenn dort noch die alte Umgebung, eine Staging-Adresse oder localhost auftaucht, stecken absolute URLs in der Datenbank, und die fallen nach dem Umschalten auf.

Ein Punkt, der beim Parallelbetrieb gern klemmt, ist das Zertifikat. Die verbreitete ACME-Prüfung über HTTP-01 verlangt, dass Let's Encrypt deine Domain erreicht — und die zeigt zu diesem Zeitpunkt noch auf den alten Server. Es gibt drei brauchbare Wege: die Prüfung über DNS-01 laufen lassen, die ohne erreichbaren Webserver funktioniert; das bestehende Zertifikat samt Schlüssel mitnehmen, wenn du es hast; oder das Zertifikat unmittelbar nach dem Umschalten ausstellen und die wenigen Minuten Lücke bewusst in ein Zeitfenster mit wenig Verkehr legen. Was du nicht tun willst, ist an dieser Stelle improvisieren, während die Domain schon umgestellt ist. Setzt deine Seite HSTS mit langer Laufzeit, ist die Lücke übrigens keine Warnung im Browser, sondern eine Fehlerseite ohne Weiterklicken.

Die TTL sagt Resolvern, wie lange sie eine Antwort behalten dürfen. Steht sie auf 24 Stunden, kann ein Resolver deine alte IP-Adresse einen Tag lang ausliefern, nachdem du sie geändert hast. Deshalb senkst du sie vorher, üblich ist ein Wert um 300 Sekunden.

Der Haken steckt im Zeitpunkt: Die Senkung muss länger zurückliegen als die alte TTL, sonst haben die Resolver den kurzen Wert noch nicht gesehen. Stand die TTL auf 24 Stunden, senkst du sie mindestens 24 bis 48 Stunden vor dem Umzug, nicht am Morgen davor. Senke alle betroffenen Typen, also A, AAAA und, falls die Mail mitzieht, auch MX und die TXT-Einträge.

Und jetzt die Stelle, an der die verbreitete Anleitung schweigt: Wenn du die Nameserver wechselst statt nur die Einträge, hilft dir deine gesenkte TTL überhaupt nichts. Wie lange die Delegation zwischengespeichert wird, legt nicht deine Zone fest, sondern der Elternbereich. Für .de gibt die DENIC die Delegation mit 86.400 Sekunden heraus, also mit 24 Stunden. Nachprüfbar an unserer eigenen Domain: Die Einträge in der Zone laufen mit kurzer TTL, die Delegation im Elternbereich mit einem Tag.

Daraus folgt eine klare Reihenfolge. Ziehe erst die Inhalte um, dann die Nameserver. Ändere am Umzugstag nur die Einträge innerhalb der bestehenden Zone, denn dort greift deine gesenkte TTL. Muss die Zone selbst wechseln, dann lass die alten Nameserver noch mindestens einen Tag lang dieselben, neuen Werte ausliefern wie die neuen. Solange beide Seiten dasselbe sagen, ist es gleichgültig, welche ein Resolver gerade benutzt — und genau das macht den Umzug unsichtbar.

Bei der Website führt eine halb verteilte Änderung dazu, dass Besucher zwei gleiche Seiten sehen. Bei der E-Mail führt sie dazu, dass Nachrichten auf zwei Systeme verteilt werden. Solange der neue MX-Eintrag noch nicht überall bekannt ist, liefern manche Absender ins neue System und manche ins alte. Beide Postfächer füllen sich, und wer nur das neue abruft, merkt wochenlang nicht, dass etwas fehlt.

Der Ablauf, der das auffängt, hat drei Teile. Erstens ein Vorlauf: Postfächer, Weiterleitungen, Verteiler, Abwesenheitsnotizen und ein etwaiges Sammelpostfach werden im neuen System angelegt, bevor irgendetwas umgestellt wird, und die Bestände einmal vollständig kopiert. Für IMAP nach IMAP ist imapsync das etablierte Werkzeug. Zweitens der Nachlauf: Nach dem Umschalten läuft dieselbe Synchronisierung noch einmal und holt genau die Nachrichten nach, die während der Umstellung im alten System gelandet sind. Ein Lauf reicht selten, plane zwei oder drei über die folgenden Tage. Drittens Geduld: Lass die alten Postfächer zwei bis vier Wochen bestehen und abrufbar. Sie kosten in dieser Zeit wenig und sind die einzige Versicherung gegen einen Absender, dessen Server eine TTL ignoriert.

SPF, DKIM und DMARC gehören vor die Umstellung, nicht danach. Wenn der neue Server versendet, seine Adresse aber nicht im SPF steht, landen die Nachrichten im Spam, und zwar sofort und bei allen. Warum die drei Einträge zusammenhängen, steht im Beitrag zu SPF, DKIM und DMARC. Wer Postfächer und Domain ohnehin zusammen bewegt, findet die Reihenfolge auf unserer Seite zum Domain-Umzug.

Das Umschalten selbst ist unspektakulär: Datenbank ein letztes Mal übertragen, Schreibzugriffe für diese Minuten stilllegen, Einträge ändern. Interessant ist, was danach passiert.

Sieh in den nächsten Tagen in das Zugriffsprotokoll des alten Servers. Kommt dort noch Verkehr an, ist das kein Fehler, sondern Information: irgendwo wird noch die alte Adresse aufgelöst. Deshalb bleibt die alte Umgebung erreichbar und ausliefernd, bis dieser Verkehr versiegt, üblicherweise zwei bis vier Wochen. Sie abzuschalten, weil „das DNS ja durch ist", ist der häufigste selbstgemachte Ausfall beim Umzug.

Die kurze Kontrollliste danach: Weiterleitungen und Statuscodes stimmen noch, ein Formular kommt tatsächlich an, Cronjobs laufen auf dem neuen und nicht mehr auf dem alten Server, Zertifikat gültig und Verlängerung eingerichtet, eine Testmail in beide Richtungen, und zum Abschluss die TTL wieder auf einen normalen Wert. Erst wenn das erledigt ist, kündigst du beim alten Anbieter.

Damit die Liste oben etwas wert ist, gehört das hierhin. Ein Umzug auf unser Webhosting ist die falsche Wahl, wenn deine Anwendung eigene Dienste auf Systemebene braucht, also eigene Prozesse, Queues, Suchdienste oder Container. Dafür ist ein Managed VPS der richtige Ort, und wir sagen das lieber vorher als nach dem Umzug. Ebenso, wenn eine Anwendung nur auf einer PHP-Version läuft, die aus der Sicherheitspflege gefallen ist: Wir können sie bereitstellen, aber das ist dann eine Übergangslösung mit Ablaufdatum, kein Zustand.

Und ein Terminhinweis, der nichts mit Technik zu tun hat: Zieh keinen Shop zwei Wochen vor dem Weihnachtsgeschäft um und keine Vereinsseite drei Tage vor der Mitgliederversammlung. Ein Umzug braucht ein Zeitfenster, in dem jemand hinschauen kann. Wenn dieses Fenster erst im Februar kommt, dann ist der Umzug im Februar.