Hoster wechseln ohne Downtime
Praxis-Anleitung in 8 Schritten: Web-Hosting wechseln (z.B. Hostpoint zu Infomaniak oder zu einer Schweizer Cloud), ohne dass Webseite oder Mails ausfallen. Mit konkreten rsync- und mysqldump-Beispielen, TTL-Strategie und kontrolliertem DNS-Cutover.
Bevor Sie anfangen
- SSH- oder mindestens SFTP-Zugang zum alten Hosting
- Vollwertiges Konto beim neuen Hoster (mit DB- und Mail-Verwaltung)
- Zugang zum DNS-Verwaltungstool der Domain (Registrar oder DNS-Provider)
- Liste aller E-Mail-Postfächer mit Passwörtern (für IMAP-Migration)
- Vollständiges Backup von Files und Datenbank, lokal abgelegt
- imapsync installiert (falls Mails migriert werden)
Audit des aktuellen Hostings
Inventar erstellen, bevor irgendetwas migriert wird. Notieren Sie alles, was am alten Hoster läuft: Webseite (Files + Datenbank), Mail-Postfächer, DNS-Records, Cron-Jobs, allfällige Hintergrunddienste.
PHP-Version, Datenbank-Version (MySQL/MariaDB) und installierte Extensions am alten Hosting prüfen. Beim neuen Hoster muss mindestens dieselbe Version verfügbar sein, sonst gibt es nach der Migration ungute Überraschungen.
Gesamtgrösse der Webseite (du -sh /pfad/zur/site) und der Datenbank (mysqldump | wc -c als Schätzung) ermitteln. Wichtig, um die Migrationsdauer abschätzen zu können.
Liste aller Mail-Postfächer mit Grösse und Anzahl Mails. Diese Liste ist später Grundlage für die IMAP-Migration.
# Grösse der Webseite messen du -sh /var/www/html # Grösse der Datenbank mysql -e "SELECT table_schema 'DB', ROUND(SUM(data_length + index_length)/1024/1024,2) 'MB' FROM information_schema.tables GROUP BY table_schema;" # Aktuelle DNS-Records dokumentieren dig +short ihrefirma.ch ANY
Neues Hosting parallel aufsetzen
Beim neuen Anbieter (z.B. Infomaniak, cyon, Hosttech oder Schweizer Cloud) Account anlegen. Webhosting-Paket mit der dokumentierten PHP-Version und mindestens der gleichen Speicher- und DB-Grösse buchen.
Datenbank am neuen Hoster anlegen mit Username und Passwort. Diese Credentials später in wp-config.php bzw. der Config-Datei der Webseite eintragen.
SSH-Zugang oder mindestens SFTP-Zugang sicherstellen. Bei reinem FTP wird die Migration mühsam und langsam.
Wichtig: noch nichts an DNS ändern. Die alte Seite läuft weiter, die neue ist über die Hoster-interne Test-URL oder einen /etc/hosts-Eintrag erreichbar.
# Lokal auf macOS/Linux einen hosts-Eintrag setzen, # um den neuen Server unter der echten Domain zu testen: sudo nano /etc/hosts # Eintrag: 185.123.45.67 ihrefirma.ch www.ihrefirma.ch
Files und Datenbank migrieren
Files via rsync vom alten Server direkt auf den neuen kopieren. Das ist deutlich schneller und sicherer als der Umweg über den eigenen Rechner. Bei sehr grossen Sites mehrere rsync-Durchgänge mit Delta-Sync vor dem Cutover.
Datenbank mit mysqldump exportieren, Datei via SCP auf den neuen Server kopieren, dort mit mysql < importieren. Bei InnoDB-Tabellen kann das mehrere Minuten dauern.
Config-Dateien anpassen: wp-config.php (WordPress), configuration.php (Joomla), .env (Laravel) etc. mit den neuen DB-Credentials.
Bei WordPress: Search-Replace falls die Datenbank absolute URLs enthält. Tool wp-cli oder Better Search Replace-Plugin verwenden, nicht einfach SQL-Find-Replace (Stichwort: serialisierte PHP-Arrays).
# Files via rsync vom alten zum neuen Server rsync -avz --progress -e ssh \ user@alt.server.ch:/var/www/html/ \ user@neu.server.ch:/var/www/html/ # Datenbank exportieren mysqldump -u dbuser -p ihrefirma_db > backup.sql # Auf neuem Server importieren mysql -u newdbuser -p ihrefirma_db < backup.sql # WordPress URLs via WP-CLI ersetzen wp search-replace 'https://alt.url' 'https://neu.url' --all-tables
Staging-URL gründlich testen
Mit dem hosts-Eintrag aus Schritt 2 oder einer Test-Subdomain (z.B. neu.ihrefirma.ch) die Seite aufrufen. Alle wichtigen Pfade durchklicken: Home, Kontakt, Login-Bereich, Suchfunktion.
Formulare testen: Kontaktformular abschicken, Newsletter-Anmeldung, eventuell Bezahlung im Test-Modus. Mail-Versand prüfen (häufig kommt von der neuen IP keine Mail durch wegen SPF/DKIM).
Performance grob messen: PageSpeed Insights gegen die Staging-URL oder Lighthouse lokal. Wenn der neue Server langsamer ist, jetzt Caching, OpCache und Datenbank-Indizes prüfen.
Bilder, CSS, JS, Schriften: alle Pfade müssen funktionieren. Browser-Konsole offen halten, 404er sehen Sie da als erstes.
Mail-Migration falls beim Hoster
Falls die Mails beim alten Hoster liegen (nicht bei einem externen Provider wie ProtonMail): am neuen Hoster die gleichen Postfächer anlegen, gleiche Adressen, neue Passwörter.
Mit imapsync (Linux/macOS) die Inhalte rüberkopieren. Funktioniert pro Postfach und kopiert Ordnerstruktur, Flags und Anhänge.
Mehrere Durchgänge: erster Sync vor 1-2 Tagen, danach täglich Delta-Syncs, finaler Sync direkt vor dem MX-Cutover. So gehen keine Mails verloren, die in der Migration ankommen.
Mail-Clients (Outlook, Apple Mail, Thunderbird) erst nach erfolgreichem MX-Cutover umstellen. Server-Adresse, IMAP/POP-Settings und neues Passwort eintragen.
# imapsync-Beispiel: ein Postfach migrieren imapsync \ --host1 mail.alt.ch --user1 info@ihrefirma.ch --password1 'altPW' \ --host2 mail.neu.ch --user2 info@ihrefirma.ch --password2 'neuPW' \ --ssl1 --ssl2 \ --automap
DNS-TTL auf 300 Sekunden reduzieren
Mindestens 24 bis 48 Stunden vor dem geplanten Cutover die TTL aller relevanten DNS-Records auf 300 Sekunden (5 Minuten) reduzieren. Records: A, AAAA, MX, sowie CNAMEs für www und Subdomains.
Hintergrund: Die TTL sagt Resolvern, wie lange sie einen Eintrag cachen sollen. Standard ist meist 3600 oder 86400 Sekunden. Mit hoher TTL sehen manche Clients nach dem Cutover noch 1 Tag lang die alten IPs.
Beim DNS-Provider (Hostpoint, Infomaniak, Cloudflare, Gandi etc.) im DNS-Editor jeden Record bearbeiten und TTL auf 300 setzen.
Geduld: erst nach Ablauf der alten TTL ist die neue TTL wirklich überall gültig. Deshalb der Vorlauf von mindestens 24 Stunden.
# Aktuelle TTL prüfen dig ihrefirma.ch +noall +answer # Beispiel-Output (TTL = mittlere Spalte) ihrefirma.ch. 3600 IN A 185.55.66.77
DNS-Cutover ausführen
Cutover idealerweise am Sonntagabend oder ausserhalb der Geschäftszeiten. So merken weniger Besucher und Kunden eine eventuelle kurze Hickser-Phase.
Beim DNS-Provider A-Record (und ggf. AAAA für IPv6) auf die neue IP umstellen. MX-Records gleichzeitig umstellen wenn Mail ebenfalls migriert wurde.
Wichtig: alter Server bleibt vorerst online. Clients mit gecachter alter IP landen dort weiter und sehen die funktionierende Seite, bis ihr Cache abläuft.
Mit dig von mehreren Standorten aus prüfen, ob die Welt schon die neue IP sieht. Tools wie whatsmydns.net zeigen weltweite Propagation.
# Propagation prüfen dig @8.8.8.8 ihrefirma.ch +short # Google DNS dig @1.1.1.1 ihrefirma.ch +short # Cloudflare DNS dig @9.9.9.9 ihrefirma.ch +short # Quad9 (Schweiz) # MX-Records prüfen dig ihrefirma.ch MX +short
Monitoring für 14 Tage
Beide Server laufen lassen. Logs auf der neuen Maschine täglich kurz prüfen: Apache/Nginx Access-Logs, Error-Logs, Mail-Logs.
Uptime-Monitoring (UptimeRobot, Better Uptime, Hetrix) gegen die Domain laufen lassen. Bei Ausfällen sofort Alarm.
SSL-Zertifikat auf dem neuen Server verifizieren: Let's Encrypt korrekt erneuert, Browser zeigt grünes Schloss, kein Mixed-Content.
Erst nach 14 Tagen ohne Probleme alte Maschine kündigen oder runterfahren. Dann TTL wieder auf 3600 oder 86400 setzen, damit das Internet effizienter mit Ihrer Domain umgeht.
Häufige Fehler vermeiden
TTL nicht rechtzeitig reduziert
Wer am Cutover-Tag die TTL reduziert, hat keinen schnellen Effekt. Resolver cachen den alten Wert weiter. Deshalb 24-48 Std. vorher auf 300 setzen.
Mail-Cutover zu früh
Wenn die MX-Records umgestellt werden, bevor der finale imapsync gelaufen ist, gehen frische Mails verloren oder landen aufgeteilt auf zwei Servern. Finaler Sync immer kurz vor MX-Cutover.
Alte Maschine zu schnell abgeschaltet
Kunden mit langer DNS-Cache-Zeit oder schlecht konfigurierten ISPs sehen noch 7-14 Tage die alte IP. Wer den alten Server sofort kündigt, killt für diese Besucher die Seite.
SSL-Zertifikat vergessen
Let's Encrypt muss auf dem neuen Server neu ausgestellt werden. Das geht aber erst, wenn die Domain auf die neue IP zeigt. Häufige Lösung: Zertifikat vor Cutover via DNS-Challenge ausstellen.
Was wenn etwas nicht klappt?
Webseite zeigt nach Cutover 500 Internal Server Error
Meist falsche PHP-Version oder fehlende PHP-Extension. Beim neuen Hoster im Control-Panel PHP-Version auf die alte umstellen. Error-Log via SSH (tail -f /var/log/...) zeigt die exakte Ursache.
Mails kommen nicht an oder landen im Spam
SPF- und DKIM-Records am DNS-Provider auf den neuen Mail-Server anpassen. Die alten Provider-Includes funktionieren nicht mehr. Siehe unsere SPF/DKIM/DMARC-Anleitung.
Bilder oder CSS laden nicht (404)
Häufig falsche Pfade oder Permissions. chown auf den Webserver-User setzen (z.B. www-data), Verzeichnisse mit 755, Files mit 644. WordPress: media.url in DB prüfen.
Einige Besucher sehen weiterhin die alte Seite
Normal in den ersten Stunden nach Cutover. Resolver mit hartnäckigem Cache. Lösung: alter Server bleibt für 14 Tage parallel online und zeigt identische Inhalte. Optional dort einen 301-Redirect auf die neue IP setzen.
Lieber von uns migrieren lassen?
Wir übernehmen den kompletten Wechsel inkl. Backup, paralleler Aufsetzung, Staging-Tests, DNS-Cutover und 14 Tage Monitoring. Ab CHF 980 für eine Standard-Webseite.
Verwandte Anleitungen und Services
Vertiefen oder direkt machen lassen.
Häufige Fragen
Wie lange dauert ein Hoster-Wechsel ohne Downtime?
Aktive Arbeit 3-6 Stunden für eine typische KMU-Webseite. Plus 24-48 Std. TTL-Vorlauf und 14 Tage paralleler Betrieb mit Monitoring. E-Commerce mit grossen DBs kann länger dauern.
Was passiert mit den Mails während der Migration?
Wenn die Mails beim Hoster liegen, werden sie via imapsync auf den neuen Server kopiert. Mit mehreren Sync-Durchgängen und einem finalen Delta-Sync direkt vor dem MX-Cutover geht keine Mail verloren.
Warum muss die DNS-TTL vorher reduziert werden?
Die TTL bestimmt, wie lange ein DNS-Eintrag gecacht wird. Mit Standard-TTL sehen Clients alte IPs noch bis zu 24 Std. nach Umstellung. Mit TTL 300 sind alle innerhalb von 5 Min. umgestellt.
Kann ich die Domain beim Wechsel behalten?
Ja. Domain und Hosting sind getrennt. Sie können den Hoster wechseln und die Domain beim alten Registrar lassen. Alternativ Transfer-Code anfordern und mitumziehen.
Was kostet ein professioneller Hoster-Wechsel?
Bei AmuraDesign ab CHF 980 für eine Standard-WordPress-Seite inkl. Backup, paralleler Aufsetzung, Staging-Tests, DNS-Cutover und 14 Tage Monitoring. E-Commerce auf Anfrage.