Was Sie beim Wechsel zu einem anderen Webhosting-Anbieter beachten sollten

Die Migration einer Website zu einem neuen Hosting-Anbieter ist eine der risikoreichsten Infrastrukturoperationen, die ein Website-Betreiber durchführen kann. Korrekt ausgeführt, führt sie zu null Datenverlust, vernachlässigbarer Ausfallzeit und messbar besserer Leistung. Nachlässig durchgeführt, erzeugt sie beschädigte Datenbanken, DNS-Fehler, SEO-Ranking-Einbrüche und stundenlange Notfallwiederherstellungsarbeiten.

Dieser Leitfaden behandelt jede kritische Phase einer Hosting-Migration — von der Vorab-Prüfung und Kompatibilitätsvalidierung über die DNS-Umschaltmechanik bis hin zur Überwachung nach der Migration — mit der technischen Tiefe, die für eine reibungslose Ausführung erforderlich ist.

Phase 1: Prüfen Sie Ihre aktuelle Hosting-Umgebung, bevor Sie etwas anfassen

Der mit Abstand häufigste Migrationsfehlschlag entsteht durch das Überspringen einer gründlichen Prüfung der bestehenden Umgebung. Bevor Sie einen neuen Anbieter evaluieren, benötigen Sie ein genaues Inventar dessen, was Sie tatsächlich betreiben.

Traffic- und Ressourcen-Profiling

Rufen Sie mindestens 90 Tage Server-Ressourcendaten ab — nicht nur Seitenaufrufzahlen. Die relevanten Metriken sind:

• Maximale gleichzeitige Verbindungen — nicht der durchschnittliche Traffic, sondern die Spitzenauslastung, die Ihr Server bewältigen muss
• Speicherverbrauch pro PHP-Worker oder Anwendungsprozess
• Disk I/O-Muster — besonders relevant, wenn Sie eine datenbankintensive Anwendung wie WooCommerce oder ein benutzerdefiniertes CRM betreiben
• Bandbreitenauslastung — monatliche Übertragungsgesamtmengen im Vergleich zum Limit Ihres aktuellen Tarifs

Wenn Ihr aktueller Host cPanel oder Plesk bereitstellt, sind diese Daten unter den Abschnitten zur Ressourcennutzung oder AWStats zugänglich. Auf einem Linux VPS führen Sie Folgendes aus, um einen Basis-Snapshot zu erfassen:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Diese Ausgabe zeigt Ihnen, ob Ihr Engpass CPU, RAM oder Disk ist — was direkt bestimmt, ob Sie einen größeren Shared-Tarif, einen VPS oder einen Dedicated Server benötigen.

Software-Stack-Inventar

Dokumentieren Sie jede Komponente Ihres Stacks mit genauen Versionsnummern:

• PHP-Version (z. B. 8.1, 8.2) und aktive Erweiterungen (mbstring, curl, gd, imagick, redis)
• MySQL- oder MariaDB-Version und Storage-Engine (InnoDB vs. MyISAM ist für Migrations-Tools relevant)
• Webserver-Software: Apache, Nginx, LiteSpeed oder eine Reverse-Proxy-Kombination
• Alle kompilierten Module, benutzerdefinierte .htaccess-Regeln oder nginx.conf-Location-Blöcke
• Cron-Jobs — exportieren Sie diese aus crontab -l und dokumentieren Sie sie separat
• SSL-Zertifikatstyp und Aussteller (Let’s Encrypt, kommerzielle CA, Wildcard)

Selbst eine fehlende PHP-Erweiterung auf dem Zielserver kann Funktionen still und leise beschädigen, die nur bei bestimmten Benutzeraktionen auftreten — ein Fehler, der nach der Migration notorisch schwer zu verfolgen ist.

Phase 2: Evaluieren und wählen Sie die richtige Hosting-Stufe

Die Wahl der falschen Hosting-Stufe ist ein struktureller Fehler, der innerhalb von Monaten zu einer zweiten Migration zwingt. Ordnen Sie Ihre Prüfungsergebnisse der richtigen Infrastrukturklasse zu.

Vergleich der Hosting-Stufen

Wichtige Entscheidungsregel: Wenn Ihre Anwendung eine spezifische PHP-FPM-Pool-Konfiguration, Redis-Socket-Verbindungen, benutzerdefinierte Nginx-Rewrites oder einen Daemon-Prozess erfordert, ist Shared Hosting architektonisch inkompatibel. Sie benötigen mindestens einen VPS mit Root-Zugriff.

Für WordPress- oder Joomla-Websites mit moderatem Traffic bietet ein VPS mit cPanel die vertraute Control-Panel-Oberfläche bei gleichzeitiger Beibehaltung der Isolierung und Leistung einer virtuellen Maschine.

Kriterien zur Anbieter-Evaluierung

Jenseits von Marketingversprechen sollten Sie Anbieter anhand dieser überprüfbaren technischen Faktoren bewerten:

• Uptime-SLA mit finanziellen Strafklauseln — eine 99,9%-SLA ohne Entschädigung ist bedeutungslos
• Rechenzentrum-Tier-Bewertung (Tier III oder Tier IV für Produktions-Workloads)
• Netzwerkredundanz — BGP Multi-Homing, mehrere Upstream-Anbieter
• Speichertyp — NVMe SSD versus SATA SSD versus rotierende Festplatte (Latenzunterschiede sind erheblich)
• Backup-Richtlinie — Häufigkeit, Aufbewahrungszeitraum, ob Backups extern gespeichert werden
• Support-Reaktionszeit-SLA — unterscheiden Sie zwischen Erstantwortzeit und Lösungszeit

Phase 3: Erstellen und verifizieren Sie ein vollständiges Backup

Keine Migration sollte ohne ein verifiziertes, wiederherstellbares Backup beginnen. „Verifiziert” bedeutet, dass Sie die Wiederherstellung tatsächlich getestet haben — nicht nur bestätigt haben, dass eine Backup-Datei existiert.

Was ein vollständiges Backup enthalten muss

• Web-Root-Dateien — das gesamte Dokumenten-Root, einschließlich versteckter Dateien wie .htaccess und .env
• Alle Datenbanken — exportiert als .sql-Dumps, nicht nur als Dateikopie des Datenbankverzeichnisses
• E-Mail-Daten — wenn Sie E-Mail-Hosting verwenden, das an Ihre Domain gebunden ist, exportieren Sie Postfächer vor DNS-Änderungen
• Cron-Jobs — crontab -l > crontab_backup.txt
• SSL-Zertifikate und private Schlüssel — wenn Sie ein kommerzielles Zertifikat verwenden, exportieren Sie die vollständige Kette
• Server-Konfigurationsdateien — /etc/nginx/, /etc/apache2/, /etc/php/, benutzerdefinierte my.cnf-Einstellungen

Durchführung eines Datenbankexports

Für MySQL/MariaDB verwenden Sie mysqldump mit Optionen, die vollständige Wiedergabetreue gewährleisten:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

Das Flag --single-transaction ist für InnoDB-Tabellen entscheidend — es erstellt einen konsistenten Snapshot ohne Tabellensperrung, was bedeutet, dass Ihre Live-Website während des Dumps weiterhin Anfragen bedient.

Überprüfung der Backup-Integrität

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Ein Backup, dessen Wiederherstellung Sie nicht getestet haben, ist kein Backup — es ist ein falsches Sicherheitsgefühl.

Phase 4: Kompatibilität auf dem Zielserver validieren

Bevor Sie Produktionsdaten übertragen, richten Sie die neue Umgebung ein und validieren Sie die Kompatibilität mithilfe eines Staging-Ansatzes.

PHP-Version und Erweiterungsverifizierung

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Vergleichen Sie diese Ausgabe mit Ihrem Inventar aus Phase 1. Jede fehlende Erweiterung muss vor der Migration installiert werden, nicht danach.

Datenbank-Kompatibilitätsprüfung

Bei der Migration von MySQL 5.7 zu MySQL 8.0 (ein häufiges Szenario) sollten Sie diese Breaking Changes beachten:

• Der utf8mb3-Zeichensatz ist veraltet; Spalten benötigen möglicherweise explizite Zeichensatzdeklarationen
• Das GROUP BY-Verhalten hat sich geändert — Abfragen, die in 5.7 funktionierten, können in 8.0 ohne ONLY_FULL_GROUP_BY-Modus-Anpassung fehlschlagen
• NO_ZERO_DATE ist im Strict-Modus standardmäßig aktiviert, was Datumsfelder mit 0000-00-00 ablehnt

Testen Sie Ihren SQL-Dump gegen die MySQL-Zielversion, bevor Sie den Produktions-Traffic umschalten.

Übersetzung der Webserver-Konfiguration

Bei der Migration von Apache zu Nginx (ein häufiges Szenario beim Wechsel zu einem leistungsoptimierten VPS) werden Ihre .htaccess-Regeln nicht automatisch übersetzt. Häufige Konvertierungen:

Apache .htaccess-Weiterleitung:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx-Äquivalent im server-Block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Das Fehlen dieser Übersetzung ist eine der häufigsten Ursachen für 404-Fehler und Weiterleitungsschleifen nach der Migration.

Phase 5: Migration mit minimaler Ausfallzeit durchführen

Wählen Sie das Migrationsfenster strategisch

Analysieren Sie Ihre Google Analytics- oder Server-Logs, um Ihr Traffic-schwächstes Fenster zu identifizieren — typischerweise zwischen 02:00 und 05:00 Uhr in der Zeitzone Ihrer Hauptzielgruppe an einem Dienstag oder Mittwoch. Vermeiden Sie Freitage; wenn etwas schiefgeht, werden Ihre Support-Optionen am Wochenende erheblich eingeschränkt.

Der Staging-First-Migrations-Workflow

1. Zeigen Sie eine Subdomain auf den neuen Server (z. B. staging.example.com) mithilfe eines A-Records, ohne die Produktions-DNS zu berühren
2. Übertragen Sie alle Dateien und Datenbanken auf den neuen Server
3. Aktualisieren Sie den Datenbankverbindungsstring der Anwendung, um auf die neue Datenbank zu zeigen
4. Ändern Sie Ihre lokale /etc/hosts-Datei, um die Produktionsdomain auf die IP des neuen Servers aufzulösen — dies ermöglicht Ihnen, die vollständige Produktionskonfiguration zu testen, ohne Live-Benutzer zu beeinflussen:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Führen Sie einen vollständigen Funktionstest durch — jedes Formular, jeden Zahlungsablauf, jedes Login-System, jeden API-Endpunkt und jeden Medien-Upload
2. Führen Sie Leistungs-Benchmarks durch mit ab (Apache Benchmark) oder wrk:

ab -n 1000 -c 50 https://example.com/

1. Erst nach Bestehen aller Tests mit der DNS-Umschaltung fortfahren

SSL-Zertifikatskonfiguration

Stellen Sie sicher, dass Ihr SSL-Zertifikat auf dem neuen Server installiert und validiert ist, bevor die DNS-Umschaltung erfolgt. Bei Verwendung von Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Wenn Sie ein kommerzielles Zertifikat von einem Anbieter wie den über SSL-Zertifikate verfügbaren verwenden, installieren Sie die vollständige Zertifikatskette (Zertifikat + Zwischen-CA + Root-CA), um Kettenvalidierungsfehler bei älteren Clients zu vermeiden.

Phase 6: DNS-Umschaltung — Der technisch sensibelste Schritt

DNS-Propagierung wird weitgehend missverstanden. Die 48-Stunden-Angabe ist eine Worst-Case-Obergrenze, keine typische Dauer. In der Praxis respektieren die meisten Resolver den TTL-Wert des geänderten Eintrags.

TTL-Reduzierung vor der Umschaltung

Mindestens 24–48 Stunden vor dem Migrationsfenster reduzieren Sie den TTL Ihrer A-Records und CNAME-Records auf 300 Sekunden (5 Minuten):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Das bedeutet, dass nach der Aktualisierung des Eintrags auf die neue IP der alte zwischengespeicherte Wert für die meisten Resolver innerhalb von 5 Minuten abläuft — nicht nach 48 Stunden. Dies ist die wirkungsvollste Technik zur Minimierung des DNS-Propagierungsfensters.

Nameserver- vs. A-Record-Aktualisierungen

Es gibt zwei unterschiedliche DNS-Umschaltungsansätze:

• Nur A-Records ändern (während dieselben autoritativen Nameserver beibehalten werden): Die Propagierung folgt dem TTL des Eintrags. Schnellster Ansatz, wenn Ihr Domain-Registrar direkte Eintrags-Verwaltung ermöglicht.
• Nameserver ändern (auf die DNS des neuen Hosts zeigen): Nameserver-TTLs betragen typischerweise 24–48 Stunden und liegen nicht unter Ihrer direkten Kontrolle. Dieser Ansatz dauert länger.

Bevorzugen Sie A-Record-Aktualisierungen, wenn möglich. Verwalten Sie das DNS Ihrer Domain über Ihr Domain-Registrierung-Control-Panel für direkte Eintrags-Kontrolle.

Den alten Server während der Propagierung aktiv halten

Kündigen oder schalten Sie den alten Hosting-Plan nicht sofort nach der DNS-Umschaltung ab. Halten Sie ihn mindestens 72 Stunden lang aktiv. Während der Propagierung werden ein Teil Ihrer Benutzer noch die alte IP auflösen — diese Anfragen müssen weiterhin bedient werden. Das vorzeitige Abschalten des alten Servers verursacht einen echten Ausfall für diese Benutzer.

Phase 7: Überwachung und Validierung nach der Migration

Uptime- und Leistungsüberwachung

Konfigurieren Sie externe Uptime-Überwachung unmittelbar nach der DNS-Umschaltung — nicht nachdem Sie glauben, dass die Propagierung abgeschlossen ist. Einzusetzende Tools:

• UptimeRobot oder Better Uptime — HTTP(S)-Prüfungen alle 1–5 Minuten von mehreren geografischen Standorten
• Google Search Console — beobachten Sie die Coverage- und Core Web Vitals-Berichte auf Anomalien in den 7 Tagen nach der Migration
• New Relic oder Datadog — Leistungsüberwachung auf Anwendungsebene, wenn Ihre Anwendung dies erfordert

Identifizierung und Behebung von Fehlern nach der Migration

Führen Sie sofort einen Crawl der neuen Website mit Screaming Frog oder einem wget-Mirror durch:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Häufige Probleme nach der Migration und ihre Ursachen:

Fest kodierte URLs in WordPress-Datenbanken korrigieren

Ein häufiges und subtiles Problem: WordPress speichert die Website-URL in der Datenbank, und viele Themes und Plugins speichern absolute URLs in serialisierten Daten. Nach der Migration zu einer neuen Domain oder einem neuen Protokoll führen Sie Folgendes aus:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

Das Flag --precise behandelt PHP-serialisierte Daten korrekt, was eine naive Zeichenkettenersetzung beschädigen würde.

Phase 8: Den alten Hosting-Plan kündigen

Kündigen Sie den alten Plan erst, nachdem alle folgenden Bedingungen bestätigt sind:

• DNS-Propagierung ist abgeschlossen (mit dig +trace example.com von mehreren Standorten überprüfen)
• Uptime-Überwachung zeigt 100% Verfügbarkeit für mindestens 72 aufeinanderfolgende Stunden
• Keine 404-Fehler oder defekten Links in Crawl-Logs erkannt
• E-Mail-Zustellung funktioniert korrekt auf dem neuen Server
• Analytics zeigen normale Traffic-Muster ohne anomale Einbrüche
• Sie haben eine lokale Kopie aller Backup-Dateien unabhängig von beiden Hosting-Anbietern

Technische Schlüssel-Checkliste

Verwenden Sie dies als Ihre Migrations-Ausführungscheckliste:

Vor der Migration

• [ ] 90-Tage-Ressourcennutzungs-Baseline exportiert (CPU, RAM, I/O, Bandbreite)
• [ ] Vollständigen Software-Stack mit genauen Versionsnummern dokumentiert
• [ ] DNS-TTL mindestens 24 Stunden vor der Umschaltung auf 300 Sekunden reduziert
• [ ] Vollständiges Backup erstellt und getestet (Dateien + Datenbanken + Cron-Jobs + E-Mail)
• [ ] PHP-Version und alle erforderlichen Erweiterungen auf dem Zielserver validiert
• [ ] .htaccess-Regeln in Nginx-Format übersetzt, falls Webserver gewechselt wird
• [ ] SSL-Zertifikat auf neuem Server vor DNS-Änderung installiert und validiert

Während der Migration

• [ ] Dateien mit rsync mit Prüfsummenverifizierung übertragen (rsync -avz --checksum)
• [ ] Datenbank importiert und Zeilenanzahl mit Quelle abgeglichen
• [ ] Vollständige Website-Funktionalität über /etc/hosts-Override vor DNS-Änderung getestet
• [ ] Anwendungs-Konfigurationsdateien aktualisiert (Datenbankhost, Anmeldedaten, Website-URL)

Nach der Migration

• [ ] Externe Uptime-Überwachung innerhalb von 5 Minuten nach DNS-Umschaltung aktiv
• [ ] Alter Server mindestens 72 Stunden nach der Umschaltung weiterhin aktiv
• [ ] Vollständiger Website-Crawl abgeschlossen; alle 404-Fehler und defekten Links behoben
• [ ] Fest kodierte URLs in der Datenbank korrigiert (insbesondere für WordPress)
• [ ] Google Search Console 7 Tage nach der Migration überwacht
• [ ] Alter Hosting-Plan erst nach Bestätigung aller obigen Punkte gekündigt

Häufig gestellte Fragen

Wie lange dauert die DNS-Propagierung tatsächlich, und kann ich sie beschleunigen?

Die Dauer der DNS-Propagierung wird durch den TTL-Wert des geänderten Eintrags bestimmt, nicht durch ein festes 48-Stunden-Fenster. Wenn Sie Ihren A-Record-TTL mindestens 24 Stunden vor der Migration auf 300 Sekunden reduzieren, werden die meisten Resolver die neue IP innerhalb von 5–10 Minuten nach der Änderung übernehmen. Die 48-Stunden-Angabe gilt für Nameserver-Delegierungsänderungen, deren TTLs außerhalb Ihrer Kontrolle liegen.

Wirkt sich die Migration zu einem neuen Host negativ auf meine Google-Suchrankings aus?

Eine korrekt ausgeführte Migration ohne Ausfallzeit, beibehaltener URL-Struktur und gültigem SSL hat keine negativen SEO-Auswirkungen. Rankings können vorübergehend sinken, wenn der neue Server langsamer ist, wenn sich URLs ohne ordnungsgemäße 301-Weiterleitungen ändern oder wenn die Website während des Crawlings nicht erreichbar ist. Überwachen Sie die Coverage- und Core Web Vitals-Berichte der Google Search Console 14 Tage nach der Migration.

Was ist der sicherste Weg, große Datenbanken ohne Datenbeschädigung zu übertragen?

Verwenden Sie mysqldump mit dem Flag --single-transaction für InnoDB-Tabellen, um einen konsistenten Snapshot ohne Tabellensperrungen zu gewährleisten. Übertragen Sie die Dump-Datei über SSH mit scp oder rsync anstatt über phpMyAdmin, das Dateigrößenbeschränkungen und Timeout-Einschränkungen hat, die bei großen Datenbanken zu stiller Kürzung führen.

Muss ich mein SSL-Zertifikat nach der Migration neu installieren?

Ja. SSL-Zertifikate sind an den privaten Schlüssel des Servers gebunden, der auf dem ursprünglichen Server liegt. Sie müssen entweder das Zertifikat auf dem neuen Server neu ausstellen (kostenlos für Let’s Encrypt) oder den privaten Schlüssel und die Zertifikatskette vom alten Server exportieren und auf dem neuen installieren. Stellen Sie sicher, dass das Zertifikat vollständig validiert ist, bevor Sie DNS aktualisieren, damit HTTPS unmittelbar nach der Umschaltung funktioniert.

Wie überprüfe ich, ob meine Migration abgeschlossen ist, bevor ich den alten Plan kündige?

Führen Sie dig +trace example.com @8.8.8.8 und dig +trace example.com @1.1.1.1 aus, um zu bestätigen, dass sowohl Google- als auch Cloudflare-Resolver die IP des neuen Servers zurückgeben. Überprüfen Sie die Uptime-Überwachung auf 72 aufeinanderfolgende Stunden sauberer Antworten. Crawlen Sie die Website auf 404-Fehler und überprüfen Sie die E-Mail-Zustellung. Erst nachdem all diese Punkte bestanden sind, ist es sicher, das alte Hosting-Konto zu kündigen.