Ein Hostingwechsel beginnt mit einer Bestandsaufnahme. Wer zuerst kündigt und danach nach Datenbankzugängen sucht, macht aus einem planbaren Projekt einen Zeitdruckfall. Dieser Ratgeber führt von den vorhandenen Diensten bis zur dokumentierten Abnahme. Er eignet sich für eine persönliche Website, einen Shop und ein Agenturprojekt; die Unterschiede liegen vor allem darin, welche Daten während des Umzugs weiter entstehen.

Das Ziel vor dem Termin festlegen

Schreiben Sie einen kurzen Umzugsauftrag: Welche Website wechselt wohin, welche Adresse bleibt gleich und welches Problem soll gelöst werden? Ein knapp gewordenes Speicherlimit verlangt eine andere Auswahl als fehlende Unterstützung für die Anwendung. Ohne diese Entscheidung wird ein neuer Tarif schnell nach derselben einzigen Zahl ausgewählt, die schon beim alten Paket nicht aussagekräftig war. Der Kriterienvergleich hilft, technische Mussbedingungen vor der Bestellung festzuhalten.

Definieren Sie anschließend eine fachliche Abnahme. Eine grüne Startseite genügt für einen Shop nicht: Anmeldung, Warenkorb, Zahlung im erlaubten Testmodus, Bestellverwaltung und Versandübergabe gehören zum Ablauf. Bei einer Beratungswebsite sind Formulare, Downloadlinks und die redaktionelle Pflege wichtiger. Schreiben Sie diese Funktionen als konkrete Tätigkeiten auf. Das Ziel lautet dann beispielsweise: Eine berechtigte Person kann sich anmelden, einen Entwurf bearbeiten und dessen Bild korrekt veröffentlichen.

Ein Inventar, das Abhängigkeiten sichtbar macht

Erfassen Sie Dateien, Datenbanken, Anwendungen, Versionen, Domains, Subdomains und geplante Aufgaben. Ordnen Sie jedem Bestandteil einen Speicherort und eine zuständige Person zu. Notieren Sie Zugangswege, ohne Passwörter in die Projektliste zu kopieren. Ein Verweis auf einen geschützten Passwortmanager reicht. Für WordPress erinnert die offizielle Migrationsanleitung daran, sowohl Verzeichnisinhalte als auch Datenbank zu sichern. Ein Inhalts-Export allein ist daher keine vollständige Kopie der Installation.

Fragen Sie gezielt nach Dingen außerhalb des sichtbaren Webverzeichnisses. Gibt es einen externen Mediendienst, einen Zahlungsanbieter, eine Versandsoftware, einen Suchindex oder einen Import aus einer Warenwirtschaft? Wo laufen Hintergrundjobs? Welche Gegenstellen erlauben nur bekannte IP-Adressen? Solche Abhängigkeiten können nach einem scheinbar erfolgreichen Umzug ausfallen. Halten Sie ebenfalls fest, ob Mail beim bisherigen Anbieter liegt. Eine Websiteverlagerung darf die Mailzustellung nicht versehentlich mit verändern.

Arbeitsinventar für den Wechsel
Bereich Aufzeichnen Abnahmeschritt
Anwendung Versionen, Erweiterungen und Sondercode Wichtigste Benutzerabläufe ausführen
Daten Dateien, Datenbank, externe Ablagen Stichproben und Import prüfen
Domain Registrar, Nameserver, DNS-Verantwortliche Adressen und HTTPS prüfen
Integration API-Ziele, IP-Freigaben, Aufgaben Kontrollierten Testlauf verfolgen
Organisation Freigabe, Erreichbarkeit, Rückfallzuständigkeit Entscheidung schriftlich bestätigen

Den neuen Tarif an der Anwendung prüfen

Vergleichen Sie die neue Umgebung mit Ihrem Inventar. Sind die benötigte PHP-Version, Datenbankfunktionen, Dateigrößen und Zugriffsrechte tatsächlich vorhanden? Unterstützte Software beim Hersteller und verfügbare Software im gewählten Hostingpaket sind zwei getrennte Fragen. Eine Produktseite kann einen Überblick liefern; besondere Anforderungen sollten vor dem Wechsel schriftlich geklärt werden. Das gilt auch für Shellzugang, eigene Aufgaben, zusätzliche Module und Grenzen gleichzeitiger Prozesse.

Planen Sie Upgrades mit Bedacht. Ein Umzug, eine neue PHP-Version, ein neues Theme und ein anderes Zahlungsplugin am selben Abend erschweren die Fehlersuche. Es kann sinnvoll sein, eine notwendige Kompatibilitätskorrektur vorab in einer Testkopie vorzunehmen und anschließend diesen bekannten Stand zu übertragen. Der Ratgeber PHP-Version und Kompatibilität erläutert diese Prüfung. Ist die alte Laufzeit nicht mehr unterstützt, brauchen Sie allerdings eine konkrete Modernisierungsentscheidung und sollten deren Behebung nicht unbegrenzt verschieben.

Eine geschützte Testkopie aufbauen

Die Zielumgebung sollte zunächst unter kontrolliertem Zugang erreichbar sein. Ein Passwortschutz vor der Anwendung ist für eine öffentliche Testdomain häufig geeigneter als nur eine WordPress-Einstellung gegen Suchmaschinen. Prüfen Sie auch Bilder, Downloads, Schnittstellen und Sitemaps. Die Kopie kann sonst vertrauliche Daten ausliefern, obwohl die Startseite eine Anmeldemaske zeigt. Der Artikel Staging und Produktivbetrieb behandelt Schutz und Übernahme ausführlicher.

Testen Sie den späteren Hostnamen möglichst ohne eine vorzeitige öffentliche Umschaltung, etwa mit einer fachgerecht eingerichteten lokalen Namenszuordnung. Dabei müssen die korrekte Domain, TLS-Namensprüfung und Anwendungskonfiguration erhalten bleiben. Ein Aufruf über eine IP-Adresse kann andere virtuelle Hosts oder abweichende Cookiebedingungen treffen. Dokumentieren Sie deshalb, wie die Testperson den neuen Server erreicht hat. Andernfalls lässt sich später kaum beurteilen, ob die erfolgreich betrachtete Seite wirklich aus der Zielumgebung kam.

Datenkopie und Datenstopp koordinieren

Eine erste Kopie dient der technischen Prüfung. Danach entstehen auf der bisherigen Website oft weiterhin Änderungen. Bei einem Blog sind das neue Beiträge und Kommentare, bei einem Shop Bestellungen, Lagerbewegungen und Kundenkonten. Legen Sie deshalb fest, welche Daten vor der Umschaltung nochmals übertragen werden und wann Schreibvorgänge kurz pausieren. Der entscheidende Punkt ist ein eindeutiger letzter gültiger Datenstand. Zwei gleichzeitig beschreibbare Installationen können widersprüchliche Wirklichkeiten erzeugen.

Unterscheiden Sie Besucherzugriff und administrative Arbeit. Eine redaktionelle Sperre kann bei einer selten geänderten Website reichen, wenn keine anderen Schreibvorgänge stattfinden. Bei Transaktionen müssen auch Integrationen und Hintergrundprozesse betrachtet werden. Vereinbaren Sie das Wartungsfenster mit den Personen, die Bestellungen oder Anfragen bearbeiten. Eine statische Wartungsinformation sollte erläutern, wann der Dienst wieder geprüft werden kann. Vermeiden Sie genaue Wiederanlaufversprechen, solange die benötigten Schritte noch nicht praktisch bekannt sind.

  1. Bestand sichern
  2. Zielkopie testen
  3. Schreibvorgänge koordinieren
  4. Letzte Daten übertragen
  5. DNS umstellen
  6. Fachlich abnehmen

DNS und Domainverwaltung getrennt behandeln

Eine Website kann auf einen neuen Server zeigen, während die Domain beim bisherigen Registrar verwaltet bleibt. Umgekehrt verschiebt ein Registrarwechsel keine Anwendungsdateien. Für .de beschreibt DENIC den Providerwechsel mit AuthInfo. Dieser Verwaltungsschritt gehört nur dann in den Auftrag, wenn er tatsächlich gewünscht ist. Geben Sie den AuthInfo-Code ausschließlich über einen sicheren Kanal an die berechtigte Stelle weiter und prüfen Sie, wer danach DNS verwaltet.

Vor der öffentlichen Umschaltung benötigen Sie eine vollständige DNS-Liste und die tatsächlichen Zieladressen. Prüfen Sie IPv4 und IPv6 getrennt; eine alte IPv6-Adresse kann einen Teil der Besucher weiterhin zum bisherigen Server führen. Ebenso müssen Hauptdomain und www berücksichtigt werden. Mailbezogene Einträge bleiben gezielt unter ihrer bisherigen Verantwortung, wenn Mail nicht Teil des Umzugs ist. Eine Schrittfolge und typische Fehler finden Sie unter Domain und DNS beim Umzug.

Eine Rückfallentscheidung vorbereiten

Ein Rückfall ist keine bloße Anweisung, die alte IP-Adresse wieder einzutragen. Sobald neue Bestellungen auf dem Zielserver entstehen, hat die alte Kopie einen veralteten Datenstand. Legen Sie vorher fest, welche Fehler einen Abbruch rechtfertigen, wer darüber entscheidet und wie neue Daten gesichert werden. Eine fehlende zentrale Bestellfunktion ist anders zu behandeln als ein kleines Darstellungsproblem im Footer. Diese Kriterien sollten aus der fachlichen Abnahme folgen.

Bewahren Sie die vorige Umgebung zunächst kontrolliert auf. Sie darf jedoch nicht unbemerkt ebenfalls Bestellungen oder externe Aufgaben weiterverarbeiten. Entscheiden Sie, ob sie nur für berechtigte Prüfung erreichbar bleibt oder vollständig angehalten wird. Dokumentieren Sie die Aufbewahrungsfrist und die spätere Löschung. Der alte Vertrag sollte erst beendet werden, wenn Datenexport, Zielbetrieb und erforderliche Übergangsphase geklärt sind. Die Vertragsprüfung hilft, Fristen mit dem technischen Ablauf abzugleichen.

Beispiel: Eine kleine Unternehmenswebsite

Als Planungsbeispiel zieht eine Website mit Kontaktformular und gelegentlichen Downloads um. Das Team erfasst zuerst die Installation und stellt fest, dass Formularnachrichten an einen externen Maildienst übergeben werden. Auf der geschützten Zielkopie werden ein Formular mit erlaubten Testdaten, ein PDF-Download, die Redaktionsanmeldung und die mobile Navigation geprüft. Der Maildienst benötigt eine gesonderte Freigabe für den Versandweg. Damit ist sichtbar, welche Aufgabe zur Website gehört und welche einen anderen Dienst betrifft.

Vor dem Wechsel pausiert die Redaktion ihre Änderungen. Ein frischer Datenbankstand und die zuletzt hochgeladenen Dateien werden übertragen. Nach der Umschaltung prüft das Team die wichtigen URLs, beide Adressfamilien und die Formularverarbeitung erneut. Erst dann endet die Schreibpause. Dieses Beispiel beschreibt einen sinnvollen Ablauf, kein hier durchgeführtes Kundenprojekt. Ein Shop würde zusätzliche Schritte für Transaktionen und Datenabgleich verlangen; die kleine Website darf deshalb nicht als pauschale Vorlage für jeden Geschäftsprozess dienen.

Abnahme und Übergabe festhalten

Planen Sie auch die Kommunikation während des Wechsels. Eine Person hält den aktuellen Stand zusammen und beantwortet Rückfragen aus Redaktion, Kundenservice und Technik. Dafür reicht bei einem kleinen Projekt ein gemeinsames Protokoll mit klaren Zeitpunkten. Entscheidend ist, dass niemand aufgrund einer alten Nachricht wieder Änderungen auf der bisherigen Installation vornimmt. Die Meldung „neuer Server bereit“ sollte deshalb nicht mit der Meldung „Redaktion wieder freigegeben“ verwechselt werden. Beide beziehen sich auf unterschiedliche Voraussetzungen.

Prüfen Sie nach der Umschaltung zusätzlich Inhalte, die selten aufgerufen werden. Dazu gehören ein älterer Beitrag mit Sonderzeichen in der Adresse, ein größeres Dokument und eine Seite mit besonderen Layoutblöcken. Solche Stichproben ergänzen die zentralen Funktionen und decken Pfad- oder Zeichensatzprobleme auf. Wählen Sie die Beispiele vor dem Wechsel aus, damit der Vergleich denselben Umfang hat. Notieren Sie, welche Teile bewusst nicht getestet wurden; so kann die Übergabe die wirkliche Prüftiefe vermitteln.

Die erste Betriebsphase benötigt eine eigene Beobachtung. Kontrollieren Sie, ob erwartete Hintergrundaufgaben ausgeführt werden, ob Fehlerprotokolle neue Auffälligkeiten zeigen und ob die zuständigen Personen die Verwaltungsoberfläche erreichen. Ein einzelner erfolgreicher Aufruf beendet diese Aufgaben nicht. Die Beobachtungsdauer sollte sich am Projekt und seinen Abläufen orientieren. Ein nur wöchentlich laufender Import wird erst dann praktisch beurteilt, wenn er kontrolliert ausgeführt oder sein nächster regulärer Durchlauf geprüft wurde.

Notieren Sie pro Prüfung Datum, Ziel, Ergebnis und verantwortliche Person. Wenn ein Test fehlschlägt, bleibt der Fehler in der Liste stehen, bis eine neue Prüfung die Korrektur bestätigt. Ein Screenshot der Startseite ersetzt keinen Formular- oder Anmeldungstest. Halten Sie außerdem fest, welche Backups vorhanden sind und ob eine Wiederherstellung geprüft wurde. Für den laufenden Betrieb benötigen die Verantwortlichen den neuen Supportweg und eine klare Zuständigkeit für Updates.

  • Alle benötigten Daten und Integrationen sind im Inventar erfasst.
  • Die Zielkopie wurde über den richtigen Hostnamen fachlich geprüft.
  • Der letzte Datenstand und die Schreibpause sind eindeutig festgelegt.
  • DNS, HTTPS und Weiterleitungen wurden nach der Umschaltung erneut kontrolliert.
  • Rückfall, alte Umgebung und Vertragsende haben konkrete Verantwortliche.

Für die Produktauswahl ergibt sich daraus eine nützliche Reihenfolge: erst notwendige Funktionen, dann Betriebsaufgaben und schließlich Preis und Laufzeit vergleichen. Die Produktübersicht unterstützt diese Einordnung. Die beste Vorbereitung ist abgeschlossen, wenn ein anderes berechtigtes Teammitglied den Plan lesen und die Entscheidungen nachvollziehen kann. Dann hängt der Wechsel nicht mehr ausschließlich vom Gedächtnis der Person ab, die ihn vorbereitet hat.