Die meisten Migrationen von Websites und Anwendungen sind nicht wegen der Technologie schwierig. Sie sind schwierig, weil sich in der alten Umgebung über Jahre undokumentierte Entscheidungen angesammelt haben: ein Cronjob, den jemand in Eile angelegt hat, eine Mail-Weiterleitung, auf die das Vertriebsteam angewiesen ist, eine fest codierte IP-Adresse in einem Payment-Callback.
Dieser Leitfaden beschreibt eine Migrationsmethode, die die Ausfallzeit bei typischen Web-Stacks im Bereich von Minuten statt Stunden hält: Content-Websites, E-Commerce-Shops, Kundenportale und Fachanwendungen, die auf Shared Hosting, einem einzelnen VPS oder einem alternden physischen Server laufen.
Was minimale Ausfallzeit tatsächlich bedeutet
Null Ausfallzeit ist möglich, erfordert aber meist eine Anwendung, die gleichzeitig an zwei Orten gegen eine gemeinsame oder replizierte Datenbank laufen kann. Die meisten Legacy-Stacks können das nicht. Ein ehrlicheres Ziel ist ein kurzer, geplanter Schreibstopp: der Zeitraum zwischen dem Stoppen der Schreibvorgänge auf dem alten System und dem Annehmen von Schreibvorgängen auf dem neuen. Für eine Website mit einigen Gigabyte Daten und einem gut geprobten Plan beträgt dieses Zeitfenster üblicherweise 5 bis 30 Minuten.
Legen Sie das Ziel schriftlich fest, bevor die Arbeit beginnt. Nennen Sie den maximal akzeptablen Schreibstopp, den maximal akzeptablen Datenverlust (idealerweise keiner) und die Tageszeit mit dem geringsten Traffic.
Zuerst eine vollständige Bestandsaufnahme
Das Inventar ist der beste Einzelindikator für eine saubere Migration. Erheben Sie es aus dem laufenden System, nicht aus dem Gedächtnis oder aus alter Dokumentation, und weisen Sie jedem Element einen Verantwortlichen zu.
- Domains und DNS. Jede Domain und Subdomain, der Registrar, der autoritative DNS-Anbieter und ein vollständiger Export der aktuellen Records, einschließlich der zur Verifizierung genutzten TXT-Records.
- Anwendungen und Laufzeitumgebungen. Sprachversionen (zum Beispiel PHP 8.1 gegenüber 8.3), Webserver und Module, Erweiterungen, Composer- oder npm-Abhängigkeiten sowie kompilierte Binärdateien.
- Datenspeicher. Datenbank-Engines und Versionen, Datenbankgrößen, Pfade und Größen der Dateiablagen, Objektanzahlen sowie Session- oder Cache-Speicher.
- Geplante und Hintergrundaufgaben. Cron-Einträge, Queue-Worker, Backup-Skripte und jeder Job, der unter einem bestimmten Benutzerkonto läuft.
- Integrationen. Payment-Gateways, Webhooks, SMTP-Relays, APIs, die Ihre ausgehende IP-Adresse auf einer Allowlist führen, sowie SSO- oder LDAP-Anbindungen.
- Zertifikate und Secrets. TLS-Zertifikate und ihre Erneuerungsmethode, API-Schlüssel, Umgebungsdateien und in der Konfiguration hinterlegte Zugangsdaten.
- E-Mail. Postfächer, Aliasse, Weiterleitungen, Verteilerlisten, Postfachgrößen und die Clients, mit denen sich die Nutzer verbinden.
Durchsuchen Sie erstens Codebasis und Konfiguration nach fest codierten IP-Adressen und absoluten Dateipfaden. Prüfen Sie zweitens die ausgehenden Verbindungen über einen normalen Geschäftstag (mit einem Werkzeug wie ss oder netstat oder anhand von Firewall-Logs), um Integrationen zu finden, an die sich niemand erinnert hat.
DNS und Zeitplan vorbereiten
DNS-Caching ist der Hauptgrund dafür, dass Nutzer nach der Umstellung weiterhin den alten Server erreichen. Hat Ihr A-Record eine TTL von 86.400 Sekunden (24 Stunden), können manche Besucher nach der Änderung noch einen ganzen Tag lang die alte IP-Adresse aufrufen.
Senken Sie die TTL jedes Eintrags, den Sie ändern wollen, auf 300 Sekunden, und zwar mindestens eine volle alte TTL vor der Umstellung, idealerweise 48 Stunden im Voraus. Manche Resolver und Unternehmensproxys ignorieren kurze TTLs, planen Sie also in jedem Fall mit einem Rest an Traffic, der noch mehrere Stunden lang zum alten Server geht.
Prüfen Sie außerdem, wer die Konten bei Registrar und DNS-Anbieter kontrolliert, dass die Zwei-Faktor-Authentifizierung funktioniert und dass sich die Personen, die die Umstellung durchführen, anmelden können.
Daten synchronisieren, ohne das Geschäft einzufrieren
Ziel ist es, fast alle Daten zu übertragen, während das alte System noch live ist, damit die abschließende Synchronisierung während des Schreibstopps klein bleibt. Eine 1-Gbps-Leitung überträgt bei voller Auslastung rund 10 TB pro Tag, aber reale Migrationen erreichen selten die Leitungsrate, weil der Quellserver, Grenzen des Shared Hostings oder viele kleine Dateien die Übertragung bremsen.
- Dateien. Führen Sie mit einem Tool wie rsync eine erste vollständige Kopie durch und wiederholen Sie danach täglich inkrementelle Läufe. Jeder Lauf überträgt nur Änderungen, sodass der letzte Durchgang während der Umstellung oft nur Sekunden bis wenige Minuten dauert.
- Datenbanken unter einigen Gigabyte. Ein Dump und Restore während des Freeze ist meist vertretbar. Messen Sie die Dauer einer Testwiederherstellung, damit Sie die tatsächliche Zeit kennen.
- Größere oder stärker ausgelastete Datenbanken. Richten Sie eine Replikation vom alten auf den neuen Server ein, lassen Sie sie aufholen und stufen Sie das Replikat bei der Umstellung hoch. Das verkürzt den Freeze auf die Zeit, die nötig ist, um Schreibvorgänge zu stoppen und zu bestätigen, dass das Replikat aktuell ist.
- Uploads und Nutzerinhalte. Laden Nutzer laufend Dateien hoch, nehmen Sie die Upload-Verzeichnisse entweder in die finale Synchronisierung auf oder leiten Sie Uploads vorübergehend auf einen gemeinsamen Object Storage um, den beide Seiten erreichen.
Prüfen Sie Daten, statt sie vorauszusetzen. Vergleichen Sie die Zeilenzahlen wichtiger Tabellen, Prüfsummen oder Dateianzahlen im Speicher sowie die letzte Bestell-, Beitrags- oder Datensatz-ID auf beiden Seiten.
Behandeln Sie die E-Mail-Migration als eigenes Projekt
E-Mail liegt oft im selben Shared-Hosting-Konto wie die Website, und sie fällt auf andere Weise aus. Behandeln Sie E-Mail als eigenen Arbeitsstrang mit eigenem Umstellungszeitpunkt, auch wenn das Ziel derselbe Anbieter ist.
Legen Sie zuerst die Postfächer auf der neuen Plattform an und kopieren Sie dann die vorhandenen E-Mails mit einem IMAP-Synchronisierungstool, wobei nach der Änderung der MX-Records ein letzter inkrementeller Durchlauf folgt. Veröffentlichen Sie vor der Umstellung SPF-, DKIM- und DMARC-Records für die neuen sendenden Server und lassen Sie den alten Server mindestens eine Woche lang weiter E-Mails annehmen, damit Nachrichten von Absendern mit veraltetem DNS nicht abgewiesen werden.
Umstellungs- und Rollback-Plan schreiben
Ein Umstellungsplan ist ein nummeriertes Runbook mit Uhrzeiten, Verantwortlichen und einer Go/No-Go-Entscheidung bei jedem kritischen Schritt. Proben Sie ihn mindestens einmal an einer Staging-Kopie und messen Sie dabei jeden Schritt, damit das eigentliche Zeitfenster keine Überraschungen bereithält.
Ein typischer Ablauf sieht so aus: das Zeitfenster ankündigen, eine Wartungsseite aktivieren oder die Anwendung auf schreibgeschützt setzen, die finale Synchronisierung von Dateien und Datenbank ausführen, die Prüfungen durchführen, DNS-Records aktualisieren, die neue Umgebung über ihre neue Adresse testen und dann Schreibzugriffe wieder freigeben.
Legen Sie im Voraus fest, welche Bedingungen einen Rollback auslösen (zum Beispiel Checkout-Fehler über einer vereinbarten Rate oder eine fehlgeschlagene Datenprüfung) und wer befugt ist, ihn auszurufen. Lassen Sie die alte Umgebung 7 bis 14 Tage lang intakt und in Betrieb.
Validieren, dann optimieren
Die Validierung beginnt in dem Moment, in dem DNS umgestellt wird, und dauert mehrere Tage. Testen Sie von außerhalb Ihres Netzwerks und aus mehr als einem Land, wenn Ihre Nutzer international sind.
- Funktionsprüfungen. Startseite, Login, Suche, Formulare, Checkout und jede geschäftskritische Transaktion, Ende zu Ende mit Testkonten durchgespielt.
- Technische Prüfungen. Gültiges TLS auf jedem Hostnamen, korrekte Weiterleitungen, keine Mixed-Content-Warnungen, HTTP-Statuscodes bei einem Crawl der wichtigsten URLs und saubere Fehlerlogs.
- Hintergrundprozesse. Prüfen Sie, ob Cronjobs planmäßig gelaufen sind, Queues abgearbeitet werden, Backups abgeschlossen wurden und ausgehende E-Mails zugestellt werden.
- Integrationen. Bitten Sie Partner, ihre IP-Allowlists zu aktualisieren, und prüfen Sie dann, ob Zahlungs-Callbacks und Webhooks in der neuen Umgebung ankommen.
Migrationen beginnen meist mit konservativer Dimensionierung. Prüfen Sie daher nach ein bis zwei Wochen realem Traffic die Metriken für CPU, Arbeitsspeicher und Festplatte und skalieren Sie nach oben oder unten. Aktivieren Sie Object Caching (zum Beispiel Redis) und ein CDN für statische Assets, passen Sie die Speichereinstellungen der Datenbank an die neue Hardware an und setzen Sie Alarmschwellen auf Basis beobachteter Ausgangswerte statt auf Standardwerte. Führen Sie zum Schluss eine Testwiederherstellung aus dem neuen Backup-System durch.
Schritt-für-Schritt-Checkliste für die Migration
- Zwei bis vier Wochen vorher. Bestandsaufnahme abschließen, Verantwortliche benennen, Schreibstopp und Ziele für Datenverlust festlegen und das Umstellungsfenster wählen.
- Zwei Wochen vorher. Die neue Umgebung bereitstellen, Laufzeitversionen angleichen, die Anwendung auf Staging deployen und eine erste vollständige Datenkopie durchführen.
- Eine Woche vorher. Die Umstellung auf Staging proben, jeden Schritt zeitlich messen, das Runbook und die Rollback-Auslöser finalisieren und den Zugang zu Registrar und DNS bestätigen.
- Achtundvierzig Stunden vorher. TTLs auf 300 Sekunden senken, tägliche inkrementelle Synchronisierungen oder Datenbankreplikation starten und Nutzer sowie Partner informieren.
- Tag der Umstellung. Wartungsseite aktivieren, finale Synchronisierung ausführen, Datenprüfungen durchführen, DNS- und MX-Records umstellen, über die neue Adresse validieren und Schreibzugriffe wieder freigeben.
- Die ersten 72 Stunden. Fehler und Performance überwachen, täglich Funktionsprüfungen durchführen, verbleibende E-Mails synchronisieren und den Rollback-Weg bereithalten.
- Nach zwei Wochen. Ressourcen bedarfsgerecht dimensionieren, Caching und CDN aktivieren, eine vollständige Wiederherstellung testen, TTLs wieder auf normale Werte anheben und die alte Umgebung außer Betrieb nehmen.
Wie Vonahost unterstützen kann
Die Managed Cloud von Vonahost läuft auf der eigenen Plattform von Vonahost, auf AWS oder auf Google Cloud, mit CDN, Backups, SSL, Monitoring, Staging-Umgebungen, Redis und Elasticsearch inklusive. Sie wählen das Land, in dem jeder Server läuft, und Daten werden nicht ohne Ihre Zustimmung verschoben.
Wenn Sie einen Umzug von Shared Hosting oder einem älteren Server planen, kann Vonahost Ihr Inventar prüfen und eine Zielumgebung vorschlagen. Jedes Angebot nennt Konfiguration, Standort, die Verantwortlichkeiten auf beiden Seiten und den Monatspreis in US-Dollar, sodass der Umfang der Migration vor Beginn der Arbeiten feststeht.