Ein Hostingwechsel überträgt eine Anwendung und verändert anschließend ihren öffentlichen Anfrageweg. Beides sollte getrennt vorbereitet werden. Die neue Umgebung muss zuerst mit dem vorgesehenen Datenstand funktionieren; danach wird die Domainumschaltung kontrolliert durchgeführt. Ein erfolgreicher Dateiupload allein ist noch kein abgeschlossener Umzug.

Das Beispiel ist eine redaktionelle WordPress-Website, auf der während der Vorbereitung weiter Inhalte entstehen. Mail bleibt ein eigener Teil des Plans und wird nur verändert, wenn dies tatsächlich zum Auftrag gehört.

Den zu übertragenden Bestand erfassen

Die Liste enthält Dateien, Datenbank, aktive Komponenten, Hauptadresse und relevante Sonderfunktionen. Notieren Sie auch geplante Aufgaben und externe Schnittstellen. Nicht jede benötigte Einstellung liegt im WordPress-Verzeichnis. Manche Regeln befinden sich in der Hostingverwaltung oder bei einem separaten DNS-Anbieter.

Prüfen Sie Eigentum und Zugriffswege für Domain, Hosting und Anwendung. Vor relevanten Änderungen wird der vorhandene Stand gesichert. Eigene neue Zugänge werden projektspezifisch erstellt; fremde Datenbanken oder Secrets werden nicht kopiert. Die neue Umgebung bekommt eine eindeutige Zuordnung, damit spätere Arbeiten den richtigen Bestand treffen.

Die Zielumgebung geschützt vorbereiten

Das neue Hosting wird mit passender Laufzeit, Dateizuordnung und Datenbank eingerichtet. Der konkrete Produktumfang wird geprüft, statt allgemeine Plattformunterstützung mit der tatsächlichen Konfiguration gleichzusetzen. Die Anwendung erhält einen geschützten Prüfweg. Dabei müssen Medien und Downloads ebenso geschützt bleiben wie HTML-Seiten.

Das Ziel wird anhand wichtiger Nutzerwege kontrolliert: öffentlicher Inhalt, Navigation, Suche, Anmeldung und Redaktion. Je nach Website kommen weitere Funktionen hinzu. Mailversand und externe Schreibaktionen werden für die Testphase bewusst behandelt. Der Ratgeber Staging und Übergabe beschreibt diese Grenze. Ein erfolgreicher Test mit künstlich leeren Daten wäre für einen gewachsenen Bestand nur begrenzt aussagekräftig.

Den letzten Datenstand mit der Redaktion abstimmen

Während die Zielumgebung geprüft wird, kann die bisherige Website neue Inhalte erhalten. Vor der Umschaltung wird deshalb ein geeigneter Zeitpunkt für den letzten Transfer vereinbart. Bei einer stark veränderlichen Anwendung können weitere Maßnahmen nötig sein. Der konkrete Ablauf richtet sich nach den Daten und darf neue Geschäftsvorgänge nicht stillschweigend verlieren.

Die Übernahme verbindet zusammenpassende Dateien und Datenbankstände. Adressänderungen werden mit einem für WordPress-Daten geeigneten Verfahren durchgeführt. Strukturierte Werte dürfen nicht durch ein beliebiges Textersetzen beschädigt werden. Nach dem letzten Transfer werden die betroffenen Funktionen erneut geprüft. Die Dokumentation nennt den tatsächlich übernommenen Zeitpunkt und noch offene Punkte.

Beispiel: Umzug mit einem kontrollierten Umschaltpunkt
  1. Bestand → Inventar und Sicherung
  2. Ziel → geschützte Funktionsprüfung
  3. Letzter Transfer → abgestimmter Datenstand
  4. Domain → Umschaltung und unabhängige Prüfung

Textalternative: Die neue Anwendung wird vor der öffentlichen Umschaltung geprüft. Anschließend wird der letzte Datenstand übertragen und der geänderte Anfrageweg aus einer unabhängigen Umgebung kontrolliert.

DNS und TLS als eigene Umstellung prüfen

Die vorgesehenen A- und AAAA-Records werden aus dem tatsächlichen Zielbestand bestimmt. IPv4 und IPv6 erhalten getrennte Prüfungen. Hauptdomain und www können unterschiedliche Antworten besitzen. Der autoritative DNS-Stand wird ebenso dokumentiert wie der normale Resolverstand nach der Umschaltung.

TLS muss für jeden vorgesehenen HTTPS-Namen passen, einschließlich alternativer Namen vor ihrer Weiterleitung. Prüfen Sie Pfad und relevante Parameter am Ziel. DNS und Anfrageweg sowie TLS und Weiterleitungen ergänzen den Ablauf. Ein direkt erzwungener Zieltest ist ein nützlicher Vorabnachweis, beweist aber noch keine korrekte öffentliche Veröffentlichung der DNS-Records.

Mailrecords nur im vorgesehenen Umfang ändern

Websitehosting und Mailhosting können getrennte Zuständigkeiten haben. Eine neue Websiteadresse verlangt deshalb nicht automatisch neue MX-Records. Erfassen Sie den bisherigen Mailweg und den beauftragten Änderungsumfang. Unverändert benötigte Dienste werden nicht nebenbei neu zugeordnet.

Wenn der Mailbetrieb tatsächlich umzieht, braucht er einen eigenen Transfer- und Prüfplan. Persönliche Postfächer, Versand der Anwendung und Domainauthentifizierung werden getrennt betrachtet. Der Ratgeber Mailzuständigkeit erklärt die Stationen. Ein erreichbares IMAP-Konto und eine zugestellte Formularnachricht sind unterschiedliche Ergebnisse, die jeweils nachgewiesen werden müssen.

Den Rückweg bis zur Abnahme erhalten

Nach der Umschaltung wird die Website aus einer unabhängigen Sitzung geprüft. Kontrollieren Sie neue Inhalte, Medien, wichtige Funktionen und die vorgesehenen Weiterleitungen. Notieren Sie tatsächliche Antworten und Auffälligkeiten. Das alte Hosting wird nicht vorzeitig entfernt, solange ein benötigter Rückweg davon abhängt.

Ein Rückwechsel kann inzwischen entstandene Daten betreffen. Deshalb wird vor seiner Durchführung fachlich entschieden, welcher Bestand erhalten werden muss. Erst nach gesichertem Abschluss wird die alte Umgebung kontrolliert stillgelegt. Die Übergabe enthält Zielkonfiguration, übernommene Datenstände und Prüfbelege. Für mehrere Websites im Pro-Rahmen wird jede Umstellung einzeln abgegrenzt.

Quellen und Prüfstand

Produktinformationen können sich ändern. Beispielarchitekturen sind redaktionelle Modelle. Unsere Methode und Grenzen

Weiterlesen

Architekturübersicht, Betriebsübersicht und druckbare Prüfliste.