Ein Website-Umzug wirkt oft wie eine reine DNS-Änderung, kann aber schnell zu Ausfällen, Datenverlust oder schlechteren Rankings führen. In diesem Beitrag zeige ich, was bei einer website migration tatsächlich übertragen wird, wie ich solche Projekte plane und welche Rolle Hosting, DevOps, Sicherheit und SEO dabei spielen. Dazu gehören konkrete Schritte, realistische Zeitfenster und ein belastbarer Rückfallplan.
Ein geplanter Umzug schützt Betrieb, Daten und Sichtbarkeit
- Bestandsaufnahme von Dateien, Datenbanken, DNS, Cronjobs, E-Mails und Schnittstellen verhindert Überraschungen.
- Staging und Tests machen technische Fehler sichtbar, bevor der neue Server produktiv geht.
- DNS mit niedriger TTL und ein klarer Umschaltzeitpunkt reduzieren die wahrgenommene Ausfallzeit.
- 301-Weiterleitungen sind bei geänderten URLs entscheidend für Nutzer und Suchmaschinen.
- Rollback-Plan und Monitoring geben dem Team eine sichere Möglichkeit, bei Problemen zurückzukehren.
Was bei einer Website-Migration tatsächlich umzieht
Bei einem Umzug wird eine Website aus ihrer bisherigen technischen Umgebung in ein neues Hosting, eine andere Cloud oder ein neues CMS übertragen. Dabei geht es nicht nur um HTML-Dateien. Meist müssen auch Datenbanken, Uploads, Konfigurationen, Zertifikate, Cronjobs und externe Dienste berücksichtigt werden.
Der englische Begriff website migration beschreibt deshalb mehrere unterschiedliche Szenarien. Ich trenne sie von Anfang an, weil jede Variante andere Risiken und Tests erfordert.
| Variante | Was sich ändert | Typisches Risiko |
|---|---|---|
| Hosting-Wechsel | Server, IP-Adresse oder Rechenzentrum | DNS-Fehler, falsche PHP-Version oder fehlende Dienste |
| CMS-Wechsel | Technologie und oft auch URL-Struktur | Datenverlust, Funktionsfehler und Redirect-Lücken |
| Domain-Wechsel | Adresse der Website | Rankingverluste durch fehlerhafte Weiterleitungen |
| Cloud- oder Plattformwechsel | Deployment, Netzwerk und Betriebsmodell | Fehlende Automatisierung, Kostenkontrolle oder Observability |
Ein einfacher Wechsel von einem Managed-Hosting-Paket zu einem anderen kann in wenigen Stunden erledigt sein. Eine Migration eines Onlineshops mit Warenkorb, Kundenkonten und laufenden Bestellungen ist dagegen ein kontinuierlicher Datenabgleich, kein einmaliges Kopieren.
Die Planung entscheidet über den späteren Erfolg
Ich beginne nie mit dem Kopieren der Dateien. Zuerst entsteht eine vollständige Übersicht über die bestehende Umgebung. Dazu gehören Hostingvertrag, Domainverwaltung, DNS-Zonen, Datenbanken, Dateipfade, E-Mail-Versand, Zahlungsanbieter, Analytics, Suchmaschinenzugänge und alle automatisierten Aufgaben.
Eine belastbare Inventarliste erstellen
Besonders häufig werden Cronjobs, versteckte Subdomains und externe API-Schlüssel vergessen. Eine Website kann im Browser funktionieren und trotzdem im Hintergrund Rechnungen versenden, Feeds erzeugen oder Daten aus einem CRM abrufen. Genau diese Funktionen fallen nach einem Umzug oft zuerst aus.
- Technologie, Versionen und benötigte Laufzeitumgebung dokumentieren
- Gesamten Webspace und alle Datenbanken erfassen
- DNS-Einträge inklusive SPF, DKIM und DMARC prüfen
- Uploads, Mediendateien und private Verzeichnisse kontrollieren
- Formulare, Webhooks, Zahlungsdienste und APIs testen
- Backups auf einem unabhängigen Speicher ablegen und testweise wiederherstellen
Ein Backup gilt für mich erst dann als brauchbar, wenn eine Wiederherstellung erfolgreich getestet wurde. Eine Datei mit dem Namen backup-final-2.zip ist noch kein Notfallplan.
Zeitfenster und Aufwand realistisch einschätzen
Eine kleine Unternehmenswebsite mit gleichbleibender Domain lässt sich technisch oft in einem bis drei Arbeitstagen migrieren. Bei einem Shop, einer mehrsprachigen Website oder einem CMS-Wechsel sind eher mehrere Wochen für Analyse, Tests, Datenabgleich und Abnahme einzuplanen.
Für den eigentlichen Umschaltvorgang strebe ich bei gut vorbereiteten Projekten eine Unterbrechung von null bis 30 Minuten an. Das ist kein Versprechen für jede Plattform, sondern ein sinnvoller Zielwert. Entscheidend sind Datenbankgröße, Schreibzugriffe, DNS-Konfiguration und die Möglichkeit, beide Systeme kurzzeitig parallel zu betreiben.
Der technische Ablauf Schritt für Schritt
Ein sauberer Ablauf trennt Vorbereitung, Übertragung, Umschaltung und Kontrolle. So lässt sich jeder Fehler einer Phase zuordnen, statt während des Livebetriebs hektisch nach der Ursache zu suchen.
- Zielumgebung vorbereiten. Server, Datenbank, Laufzeitversionen, Firewall, Benutzerrechte und TLS-Zertifikat werden eingerichtet.
- Staging-System aufbauen. Die Website läuft zunächst unter einer geschützten Testadresse. Suchmaschinen dürfen diese Umgebung nicht indexieren.
- Dateien und Datenbank übertragen. Große Datenmengen sollten nicht über den Browser kopiert werden. Für Datenbanken nutze ich einen reproduzierbaren Export- und Importprozess.
- Konfiguration anpassen. Zugangsdaten, Pfade, Umgebungsvariablen, Mailversand und API-Endpunkte werden auf die neue Umgebung abgestimmt.
- Automatisierte Tests ausführen. Startseite, Login, Suche, Formulare, Checkout, Medien, Redirects und wichtige Schnittstellen müssen geprüft werden.
- Letzte Synchronisierung durchführen. Bei Websites mit laufenden Bestellungen oder Beiträgen wird ein kurzer Schreibstopp oder ein finaler Datenabgleich eingeplant.
- DNS umschalten und überwachen. Erst wenn die neue Umgebung stabil ist, wird der Datenverkehr vollständig auf sie geleitet.
DevOps macht den Umzug wiederholbar
Bei regelmäßig betriebenen Projekten sollte die Infrastruktur nicht nur manuell im Hostingpanel angelegt werden. Mit Infrastructure as Code, etwa über Terraform oder OpenTofu, werden Server, Netzwerke und Berechtigungen als versionierte Konfiguration beschrieben.
Eine CI/CD-Pipeline übernimmt anschließend Build, Tests und Deployment. Das bedeutet nicht, dass jede kleine Website eine komplexe Kubernetes-Landschaft braucht. Oft reicht eine schlanke Pipeline mit automatischen Backups, einem Staging-Deployment und einem überprüften Produktions-Release.
Wichtig ist außerdem, dass Passwörter und API-Schlüssel nicht im Repository liegen. Sie gehören in einen Secret-Manager oder in geschützte Umgebungsvariablen. Dieser Schritt wirkt unspektakulär, verhindert aber, dass ein Serverumzug versehentlich vertrauliche Zugangsdaten offenlegt.
SEO, Daten und Sicherheit dürfen nicht nachträglich kommen
Technisch kann eine Website erreichbar sein und trotzdem geschäftlich verlieren. Nach einer Migration können Rankings sinken, Formulare unbemerkt ausfallen oder personenbezogene Daten in einer falsch konfigurierten Umgebung landen. Deshalb prüfe ich diese Bereiche parallel zur Infrastruktur.
URLs und Weiterleitungen sauber behandeln
Bleiben Domain und Pfade identisch, braucht ein reiner Hostingwechsel normalerweise keine neuen Weiterleitungen. Ändern sich URLs, sollten alte Adressen mit direkten 301-Weiterleitungen auf die jeweils passende neue Seite zeigen.
Weiterleitungsketten wie alte URL zu Zwischen-URL zu Ziel-URL erschweren Crawling und Analyse. Ich erstelle deshalb vor dem Launch eine Tabelle mit alten und neuen Adressen und teste sie automatisiert. Auch Canonical-Tags, XML-Sitemap, interne Links und hreflang-Verweise gehören in diese Kontrolle.
Google Search Central weist darauf hin, dass sich die Verarbeitung eines größeren Umzugs über mehrere Wochen ziehen kann. Ein kurzfristiger Rückgang bei Crawling oder Sichtbarkeit ist nicht automatisch ein Fehler. Dauerhafte 404-Seiten, falsche Canonicals oder blockierte Ressourcen sind dagegen klare Warnsignale.
Datenschutz und Zugriffsschutz prüfen
Für Unternehmen in Deutschland ist der Standort des Hostings allein nicht die komplette Datenschutzprüfung. Entscheidend sind unter anderem Auftragsverarbeitung, Unterauftragsverarbeiter, technische Schutzmaßnahmen und Datenflüsse. Ein Anbieter in der EU kann organisatorisch besser passen, ist aber nicht automatisch in jeder Konfiguration rechtskonform.
- TLS-Zertifikate und sichere Weiterleitung auf HTTPS kontrollieren
- Produktive Daten nur verschlüsselt übertragen
- SSH- und Administrationszugänge auf notwendige Personen beschränken
- Backups verschlüsseln und Aufbewahrungsfristen definieren
- Logging datensparsam konfigurieren
- Firewall, Updates und Rechte nach dem Umschalten erneut prüfen
Lesen Sie auch: Logfile-Analyse im Hosting - Ursachen schneller erkennen
Funktionstests mit echten Nutzungsszenarien
Ein HTTP-Status von 200 sagt wenig über die Qualität einer Migration aus. Ich teste lieber konkrete Abläufe. Bei einem Shop lege ich beispielsweise einen Testartikel in den Warenkorb, führe den Checkout bis zur sicheren Testzahlung durch und prüfe anschließend, ob Bestellung, E-Mail und Lagerbestand korrekt verarbeitet werden.
Bei einer redaktionellen Website gehören Login, Bild-Upload, Suche, Kontaktformular und Newsletter-Anmeldung auf die Prüfliste. Zusätzlich messe ich Antwortzeit, Fehlerquote und Ressourcenverbrauch, weil eine neue Plattform nicht automatisch schneller oder günstiger ist.
Welche Strategie für den Umzug passt
Nicht jedes Projekt sollte auf dieselbe Weise live gehen. Ich wähle die Strategie nach Änderungsrisiko, Datenmenge, erwarteter Last und der Frage, wie schnell ein Rückweg möglich sein muss.
| Strategie | Geeignet für | Stärke | Grenze |
|---|---|---|---|
| Direkter Cutover | Kleine Websites mit wenig Schreibzugriffen | Einfach und kostengünstig | Weniger Spielraum bei Fehlern |
| Blue-Green-Deployment | Websites mit kritischer Verfügbarkeit | Alte und neue Umgebung können parallel bereitstehen | Zusätzliche Infrastruktur und sorgfältige Datensynchronisierung nötig |
| Migration in Wellen | Großen Portalen oder vielen Mandanten | Risiko wird auf kleinere Einheiten verteilt | Mehrere Umschaltungen und längere Projektlaufzeit |
| Lift and shift | Schnellem Wechsel ohne größere Architekturänderung | Wenig Änderungen am Anwendungscode | Alte technische Schwächen werden mitgenommen |
| Replatforming | Verbesserung von Skalierung, Betrieb oder Deployment | Langfristig bessere Automatisierung möglich | Höherer Test- und Abstimmungsaufwand |
Ein Blue-Green-Ansatz klingt zunächst nach der professionellsten Lösung, ist aber nicht immer wirtschaftlich. Für eine kleine Website mit wenigen Änderungen pro Woche kann ein getesteter Direktwechsel sinnvoller sein. Bei einem Shop mit laufenden Bestellungen würde ich dagegen kaum auf einen Rückfallweg verzichten.
Die häufigsten Fehler und wie ich sie vermeide
Die meisten Probleme entstehen nicht durch spektakuläre Serverfehler, sondern durch kleine Lücken in der Vorbereitung. Diese Punkte sehe ich besonders oft:
- DNS zu früh ändern. Die neue Umgebung muss vollständig getestet sein, bevor der Traffic umgeleitet wird.
- Nur die Dateien kopieren. Datenbanken, Uploads, Konfigurationen und Hintergrundprozesse gehören genauso zur Website.
- Alte PHP- oder Datenbankversion übernehmen. Kompatibilität sollte geprüft werden, statt veraltete Abhängigkeiten blind mitzunehmen.
- Keinen Schreibstopp planen. Neue Bestellungen oder Beiträge können sonst zwischen alter und neuer Datenbank verloren gehen.
- Redirects erst nach dem Launch erstellen. Die Zuordnung alter und neuer URLs gehört in die Vorbereitungsphase.
- Monitoring vergessen. Ohne Logs, Uptime-Prüfung und Fehlerraten bleibt ein schleichender Ausfall leicht unbemerkt.
- Rollback nur theoretisch beschreiben. Ein Rückweg muss mit konkreten Zuständigkeiten, Schritten und Zeitgrenzen ausführbar sein.
Ich lege für den Launch außerdem eine klare Abbruchregel fest. Wenn beispielsweise zentrale Transaktionen fehlschlagen, die Datenbank nicht konsistent ist oder die Fehlerquote deutlich über dem Normalwert liegt, wird nicht weiter improvisiert, sondern auf die alte Umgebung zurückgeschaltet.
Was nach dem Umschalten noch geprüft werden muss
Der Wechsel ist nicht beendet, sobald die neue IP-Adresse antwortet. In den ersten 24 bis 72 Stunden beobachte ich Serverlogs, Monitoring, Suchzugriffe, Formulare, Transaktionen und Supportmeldungen besonders aufmerksam.
DNS-Einträge können je nach Resolver unterschiedlich lange zwischengespeichert werden. Deshalb sollte die alte Umgebung nicht sofort gelöscht werden. Ich halte sie mindestens so lange erreichbar, bis der Datenverkehr stabil auf der neuen Plattform ankommt und kein wichtiger Zugriff mehr dort landet.
Nach der technischen Stabilisierung lohnt sich ein Kosten- und Performancevergleich. Stimmen Ressourcenverbrauch, Backupgröße, Ladezeiten und monatliche Hostingkosten mit der Planung überein? Eine Migration ist erst dann gelungen, wenn sie nicht nur funktioniert, sondern den Betrieb messbar verbessert oder zumindest verlässlich fortführt.
Ein guter Umzug endet mit einem belastbaren Betriebsmodell
Die beste Migration ist nicht die mit dem spektakulärsten Cloud-Setup, sondern die, nach der das Team den Betrieb versteht und sicher beherrscht. Dazu gehören dokumentierte Zugänge, wiederholbare Deployments, getestete Backups, klare Verantwortlichkeiten und ein Monitoring, das Probleme meldet, bevor Kunden sie entdecken.
Mein wichtigster Rat lautet deshalb, die Umschaltung als einen kleinen Teil des Projekts zu behandeln. Analyse, Test, Synchronisierung, Rollback und Nachkontrolle entscheiden weit stärker über den Erfolg als die Wahl eines einzelnen Hostinganbieters.
