Ein Hosting-Wechsel ist kein Hexenwerk — aber er verzeiht keine Schlampigkeit. Wer Dateien, Datenbanken, E-Mails und DNS-Einträge ohne klaren Plan umzieht, riskiert tagelange Ausfälle, verlorene Mails und panische Anrufe von Kunden. Diese Checkliste führt Schweizer KMU in zehn klar definierten Schritten durch eine saubere Migration: von der Inventur über die DNS-Strategie bis zum kontrollierten Cutover und den Post-Migration-Checks. Mit konkreten TTL-Werten, Praxis-Befehlen und einem Notfallplan, falls es trotzdem klemmt.
-
1
Inventur: Was wird mitgenommen?
Bevor Sie einen einzigen Megabyte kopieren, listen Sie sämtliche Bestandteile Ihrer aktuellen Web-Präsenz auf. Dazu gehören: alle Web-Dateien (inklusive versteckter Dateien wie .htaccess, .env, robots.txt), MySQL- oder MariaDB-Datenbanken mit ihren Benutzern und Passwörtern, sämtliche E-Mail-Postfächer mit Quota und Aliases, Cronjobs, SSL-Zertifikate, DNS-Zone (A, AAAA, MX, TXT, SPF, DKIM, DMARC, CNAME), die Domain-Registrierung selbst (oft beim Provider mit-registriert), allfällige FTP-Subaccounts und installierte CMS-Versionen mit Plugins. Dokumentieren Sie alles in einer Tabelle inklusive Speicherplatz und letzter Änderung. Dieser Schritt verhindert die häufigste Migration-Panne: vergessene Komponenten, die erst Wochen später schmerzhaft auffallen.Resultat: Vollständige Inventarliste mit Grössen, Zugangsdaten und Abhängigkeiten — die Grundlage für realistische Zeitplanung.
-
2
Vollständige Backups erstellen (lokal + Cloud)
Backups sind Ihre Lebensversicherung. Erstellen Sie mindestens zwei unabhängige Kopien: eine lokal auf Ihrem Rechner, eine in einem Cloud-Storage wie pCloud (Schweizer Anbieter), Infomaniak Swiss Backup oder einem separaten S3-kompatiblen Bucket. Web-Dateien sichern Sie via SFTP/rsync (rsync -avz user@host:/var/www/ ./backup-files/), Datenbanken via mysqldump --single-transaction --routines --triggers --add-drop-table -u user -p datenbank > dump.sql. E-Mails kopieren Sie idealerweise per IMAP mit imapsync oder offlineimap. Prüfen Sie Backups stichprobenartig: Lässt sich der SQL-Dump in eine lokale Test-Datenbank importieren? Lassen sich ZIP-Archive ohne Fehler entpacken? Ein unbestätigtes Backup ist kein Backup.Resultat: Zwei vollständige, geprüfte Backup-Sets an verschiedenen Speicherorten — mit dokumentiertem Zeitstempel.
-
3
Neue Hosting-Umgebung vorbereiten
Bestellen Sie das neue Hosting-Paket frühzeitig — idealerweise zwei bis drei Wochen vor dem geplanten Cutover. So haben Sie genug Puffer für Tests. Legen Sie alle benötigten Konten parallel an: Datenbank(en) mit identischen Namen und Benutzern (das spart Anpassungen in Konfigurations-Dateien), E-Mail-Postfächer mit denselben Adressen und Passwörtern wie beim alten Provider, FTP-Zugänge, gegebenenfalls SSH-Schlüssel hinterlegen. Achten Sie auf identische PHP-Version (idealerweise PHP 8.3 oder 8.4 — vergleichen Sie mit php -v auf dem Alt-Server) und passende Extensions (imagick, gd, intl, mbstring). Reicht der Speicherplatz? Sind die PHP-Limits hoch genug (memory_limit, upload_max_filesize)? Diese Vorbereitung entscheidet, ob die Migration zwei Stunden oder zwei Tage dauert.Resultat: Eine funktionsfähige, leere Hosting-Umgebung mit identischen Eckdaten — bereit zur Befüllung.
-
4
DNS-Strategie planen: TTL frühzeitig senken
Der wichtigste Trick für eine schnelle Umschaltung: Senken Sie die TTL (Time-To-Live) Ihrer DNS-Einträge mindestens 24 — besser 48 — Stunden vor dem Cutover auf 300 Sekunden (5 Minuten). Standard sind oft 3600 bis 86400 Sekunden, was bedeutet, dass weltweite DNS-Resolver bis zu einem Tag lang die alte IP cachen. Mit TTL 300 schalten Sie effektiv innerhalb von Minuten weltweit um. Prüfen Sie aktuelle Werte mit dig +noall +answer cyberdine.ch A oder dig SOA Ihrer-Domain.ch. Planen Sie zudem, ob Sie die Nameserver komplett wechseln (vollständige Zonen-Übernahme beim neuen Provider) oder nur einzelne A-Records anpassen. Letzteres ist schneller, aber unflexibler. Notieren Sie sich alle bestehenden TXT-Records (SPF, DKIM, DMARC, Domain-Verifikationen für Google, Microsoft) — diese werden gerne übersehen.Resultat: TTL auf 300 Sekunden gesetzt, komplette DNS-Zone dokumentiert, Cutover-Strategie definiert.
-
5
Dateien und Datenbanken kopieren
Übertragen Sie nun die Web-Dateien auf den neuen Server. Bei kleinen Sites (unter 1 GB) genügt SFTP via FileZilla. Bei grösseren Datenmengen lohnt sich rsync von Shell zu Shell: rsync -avz -e ssh /var/www/ neuer-server:/var/www/. Importieren Sie die Datenbank: mysql -u user -p datenbank < dump.sql. Passen Sie anschliessend Konfigurationsdateien an: wp-config.php (WordPress), settings.php (Drupal), .env (Laravel) — Datenbank-Host, Benutzer, Passwort. Bei WordPress zusätzlich die siteurl/home noch nicht auf die neue Domain ändern, sondern erst beim Cutover. Setzen Sie korrekte Datei-Berechtigungen (Dateien 644, Ordner 755) und Eigentümer (chown -R www-data:www-data /var/www/site/). Vergessen Sie nicht: Cronjobs neu einrichten, sie kommen nicht automatisch mit.Resultat: Alle Dateien und Datenbanken auf dem neuen Server, Konfiguration angepasst, Cronjobs eingerichtet.
-
6
E-Mail-Konten und IMAP-Sync (kritisch!)
E-Mail-Migration ist der häufigste Stolperstein — und der schmerzhafteste. Legen Sie auf dem neuen Server zuerst alle Postfächer mit identischen Adressen und Passwörtern an. Synchronisieren Sie bestehende Mails per IMAP mit imapsync: imapsync --host1 alt.server.ch --user1 info@kunde.ch --password1 xyz --host2 neu.server.ch --user2 info@kunde.ch --password2 xyz. Das Tool läuft inkrementell — Sie können mehrfach synchronisieren, ohne Duplikate zu erzeugen. Führen Sie einen ersten Sync ein bis zwei Tage vor dem Cutover durch, einen zweiten finalen Sync direkt vor der DNS-Umschaltung, um die letzten Mails zu erfassen. Wichtig: Den Sync nach dem MX-Wechsel nochmals laufen lassen, um Mails einzufangen, die noch beim alten Server eingegangen sind. Informieren Sie Nutzer, dass Passwörter in Outlook/Apple Mail neu eingegeben werden müssen, falls sich Servernamen ändern.Resultat: Alle Postfächer angelegt, bestehende Mails synchronisiert, Sync-Plan für Cutover bereit.
-
7
Testumgebung: Site lokal über hosts-File prüfen
Bevor Sie DNS umschalten, müssen Sie die neue Site gründlich testen — am besten unter der echten Domain. Der Trick: Editieren Sie lokal Ihre hosts-Datei (Windows: C:\Windows\System32\drivers\etc\hosts, macOS/Linux: /etc/hosts) und fügen Sie einen Eintrag wie "185.158.xxx.xxx kunde.ch www.kunde.ch" hinzu. Damit löst nur Ihr Rechner die Domain auf den neuen Server auf, während der Rest der Welt weiterhin den alten Server sieht. Testen Sie: Lädt die Startseite? Funktionieren Login, Kontaktformular, Suche, Shop-Checkout? Werden Bilder ausgeliefert? Spielt das SSL-Zertifikat mit? Prüfen Sie auch Subdomains (shop., blog., mail.). Alternativ bieten viele Provider eine Vorschau-URL wie kunde.ch.neuer-host.ch — diese ist aber wegen absoluter URLs in Datenbanken oft weniger zuverlässig.Resultat: Vollständig getestete neue Umgebung — alle Kernfunktionen verifiziert ohne öffentlichen Eingriff.
-
8
DNS-Cutover: A-Record oder Nameserver umschalten
Jetzt geht es live. Wählen Sie einen verkehrsarmen Zeitpunkt — typischerweise früh morgens oder am Wochenende. Ändern Sie den A-Record (und AAAA bei IPv6) auf die neue Server-IP, oder schalten Sie die Nameserver komplett um. Bei Domain-Registraren wie SWITCH, Hostpoint oder Cyberdine erfolgt die Anpassung im Kunden-Panel. Verifizieren Sie die Propagation mit dig +trace kunde.ch oder über öffentliche Tools wie dnschecker.org. Dank TTL 300 sehen Sie meist innerhalb von 5–15 Minuten den Effekt. Behalten Sie beide Server gleichzeitig laufen — Mails und Traffic werden während der Übergangsphase auf beiden landen. Erhöhen Sie die TTL nach erfolgreicher Migration wieder auf 3600 oder 14400 Sekunden, um die DNS-Last zu reduzieren.Resultat: DNS zeigt weltweit auf neuen Server, beide Server laufen parallel als Sicherheitsnetz.
-
9
Post-Migration-Checks: Funktion, SEO, SSL, E-Mails
Nach dem Cutover beginnt die kritischste Phase. Prüfen Sie systematisch: Lädt die Site unter https:// mit gültigem Zertifikat (Let's Encrypt sollte automatisch greifen, sonst manuell auslösen)? Werden alle Unterseiten korrekt ausgeliefert? Funktionieren Formulare und der Mailversand vom Server (PHPMailer/SMTP)? Sind alle 301-Weiterleitungen aus der .htaccess oder nginx-Konfiguration aktiv? Prüfen Sie die Google Search Console auf Crawling-Fehler. Testen Sie ein- und ausgehende E-Mails von verschiedenen Adressen aus (Gmail, Bluewin, Outlook). Kontrollieren Sie SPF/DKIM/DMARC mit Tools wie mxtoolbox.com — falsch gesetzte Records landen schnell im Spam. Überwachen Sie die Server-Logs der ersten 48 Stunden auf 404er und 500er. Ein zweiter imapsync-Lauf fängt Nachzügler-Mails ein.Resultat: Site, Mails und SEO-Signale vollständig funktional, Logs unauffällig, Monitoring aktiv.
-
10
Alten Provider erst nach 2–4 Wochen kündigen
Widerstehen Sie der Versuchung, sofort beim alten Provider zu kündigen, sobald die neue Site läuft. Lassen Sie den alten Account mindestens zwei, besser vier Wochen aktiv. Gründe: vereinzelte Resolver halten DNS-Caches länger als die TTL vorgibt, manche Mail-Server cachen MX-Records mehrere Tage, und es können vergessene Subdomains, Cronjobs oder externe Integrationen auftauchen, die noch auf die alte Infrastruktur zeigen. Beobachten Sie die Logs des alten Servers — kommt dort noch Traffic an? Wenn nach drei Wochen Ruhe herrscht, können Sie den Kündigungsprozess einleiten. Sichern Sie unbedingt vor der Löschung ein finales Komplett-Backup (Dateien, Datenbanken, Mails) und bewahren Sie es mindestens ein Jahr auf. Erst dann den alten Vertrag auslaufen lassen.Resultat: Sauberer Abschluss mit Sicherheitsnetz — kein verlorener Traffic, kein verlorenes Datum.
Vor der Migration: Was Sie prüfen sollten
Eine erfolgreiche Migration beginnt lange vor dem ersten kopierten Byte. Klären Sie zuerst die Vertragsfragen: Wann läuft Ihr aktueller Hosting-Vertrag aus? Gibt es eine Kündigungsfrist (oft drei Monate vor Vertragsende)? Sind Domains beim selben Provider registriert wie das Hosting, und müssen sie separat transferiert werden? Holen Sie sich rechtzeitig die Zugangsdaten zum Domain-Panel und prüfen Sie, ob der Admin-Kontakt eine aktive E-Mail-Adresse hat — beim .ch-Transfer wird dorthin der Bestätigungslink geschickt.
Klären Sie ausserdem technische Abhängigkeiten: Welche PHP-Version läuft aktuell, und unterstützt der neue Provider sie? Welche PHP-Extensions sind aktiv (imagick, gd, intl, mbstring, soap)? Gibt es spezielle Server-Konfigurationen, etwa ionCube-Loader, eigene SSL-Zertifikate oder Verzeichnis-Passwörter? Welche Cronjobs laufen im Hintergrund — sie kommen bei einem Standard-Backup nicht mit. Notieren Sie sich auch externe Anbindungen: Zahlungsdienstleister mit IP-Whitelist, Mail-Versand über SMTP-Relays wie Mailgun oder SendGrid, oder API-Schnittstellen zu Buchhaltungssoftware. All diese Punkte müssen am neuen Standort identisch verfügbar sein.
Empfehlenswert ist eine kurze Risiko-Einschätzung: Welche Funktion der Website ist geschäftskritisch? Was passiert, wenn sie für drei Stunden ausfällt? Für drei Tage? Diese Antwort entscheidet, ob Sie einen aufwendigen Parallel-Betrieb organisieren oder einen einfachen Cutover am Sonntagmorgen ausreicht.
Häufige Fehler beim Hosting-Wechsel
Der mit Abstand häufigste Fehler ist die vergessene Komponente: Eine Cronjob-Datei, die im Backup nicht enthalten war, ein verstecktes Verzeichnis mit Bilduploads, ein Subdomain wie shop.kunde.ch, der separat konfiguriert werden muss. Eine sorgfältige Inventur in Schritt 1 verhindert das.
An zweiter Stelle steht die DNS-Falle: TTL nicht gesenkt, weshalb die Umschaltung 24 Stunden dauert und Kunden weiterhin auf der alten Site landen. Oder vergessene TXT-Records für SPF, DKIM oder Google Site-Verification — die Folge sind plötzlich abgewiesene Mails oder verlorene Search-Console-Daten.
Klassiker Nummer drei sind hardcodierte URLs in Datenbanken. WordPress speichert die Site-URL absolut, ebenso viele andere CMS. Wenn Sie die Datenbank kopieren und die Site auf einer Test-Subdomain testen wollen, leitet das System Sie permanent auf die alte Live-URL weiter. Lösung: Search-Replace-Tools wie WP-CLI (wp search-replace) oder direkter SQL-Replace, aber Achtung bei serialisierten Daten.
Ebenfalls beliebt: falsche Datei-Berechtigungen nach dem Upload. Ist der Web-Server-Benutzer nicht Eigentümer der Dateien, schlagen Uploads, Cache-Schreibvorgänge und Plugin-Installationen fehl. Setzen Sie chown korrekt und prüfen Sie 644/755 als Standard.
Schliesslich: zu schnelles Kündigen des alten Vertrags. Wer am Cutover-Tag direkt kündigt, hat keine Rückfallebene, wenn etwas schiefgeht. Mindestens zwei Wochen Parallelbetrieb sind Pflicht.
Wenn etwas schiefgeht: Notfallplan
Trotz sorgfältiger Vorbereitung kann etwas klemmen. Halten Sie deshalb einen Notfallplan bereit, bevor Sie den Cutover-Knopf drücken.
Szenario 1: Die neue Site zeigt Fehlermeldungen. Erste Massnahme — DNS auf den alten Server zurückschalten. Da TTL nur 300 Sekunden beträgt, ist die Site innerhalb von Minuten wieder erreichbar. Dann in Ruhe die Logs analysieren: Apache/Nginx-Error-Log, PHP-Error-Log, Datenbank-Verbindungsprobleme. Erst nach behobenem Problem erneut umschalten.
Szenario 2: Mails kommen nicht mehr an. Prüfen Sie zuerst den MX-Record mit dig MX kunde.ch — zeigt er auf den neuen Server? Sind die Postfächer wirklich angelegt und aktiv? Funktioniert SMTP-Auth? Häufig sind es SPF-Probleme: Steht im TXT-Record die IP des neuen Servers? Ein vergessener SPF-Eintrag führt dazu, dass ausgehende Mails als Spam markiert werden.
Szenario 3: SSL-Zertifikat funktioniert nicht. Bei Let\'s Encrypt löst das automatische Renewal meist erst aus, wenn die Domain auf den Server zeigt. Triggern Sie certbot manuell oder kontaktieren Sie den Provider. Bis dahin kann ein temporäres self-signed Cert oder eine Weiterleitung via http auf den alten Server helfen — aber niemals die Site ohne SSL ausliefern.
Szenario 4: Datenverlust oder korrupte Datenbank. Hier rettet Sie das Backup aus Schritt 2 — vorausgesetzt, Sie haben es geprüft. Importieren Sie den letzten verifizierten Dump und stellen Sie nur die fehlenden Datensätze nach.
Wichtig in allen Szenarien: Kommunizieren Sie aktiv. Eine kurze E-Mail an Kunden oder ein Banner auf der Website („Wir migrieren gerade — kurzfristige Störungen möglich") erspart hektische Support-Anfragen.
Kostenloser Transfer-Service von Cyberdine
Wer als KMU nicht selbst migrieren will oder die Verantwortung lieber in erfahrene Hände gibt: Cyberdine Systems übernimmt die komplette Migration bestehender Webseiten kostenlos als Bestandteil jedes Hosting-Vertrags. Seit 1995 betreuen wir Schweizer Unternehmen — vom Einzelhandwerker bis zum mittelständischen Betrieb — und kennen die typischen Stolpersteine aller verbreiteten CMS, Webshops und Mail-Konfigurationen. Wir kümmern uns um Dateien, Datenbanken, Mails inklusive IMAP-Sync, DNS-Strategie und den koordinierten Cutover — Sie liefern nur die Zugangsdaten, wir liefern eine reibungslos laufende Site auf Schweizer Infrastruktur. Kontaktieren Sie uns für ein kostenloses Migrationsgespräch — wir prüfen Ihre bestehende Umgebung und erstellen einen konkreten Zeitplan, bevor Sie sich für irgendetwas entscheiden müssen.
Häufige Fragen
-
Wie lange dauert eine typische Webseiten-Migration?
Eine einfache Visitenkarten-Site mit wenigen Mail-Postfächern lässt sich in 2–4 Stunden migrieren. Eine mittlere KMU-Site mit WordPress, Shop, 10–20 Postfächern und einigen GB Daten benötigt typischerweise einen halben bis ganzen Arbeitstag inklusive Tests. Komplexe Umgebungen mit eigenen Anwendungen, vielen Subdomains oder grossen Datenbanken können sich über mehrere Tage ziehen. Planen Sie immer einen Puffer von 50 Prozent zusätzlich ein.
-
Auf welchen Wert sollte ich die TTL vor der Migration senken?
Setzen Sie die TTL auf 300 Sekunden (5 Minuten) — und zwar mindestens 24, besser 48 Stunden vor dem geplanten Cutover. So sind alle weltweiten DNS-Resolver darauf eingestellt, neue Werte schnell zu übernehmen. Nach erfolgreicher Migration setzen Sie die TTL wieder auf 3600 oder 14400 Sekunden zurück.
-
Was passiert mit E-Mails während der DNS-Umschaltung?
Während der Propagationsphase können Mails sowohl beim alten als auch beim neuen Server eingehen — je nachdem, welchen MX-Record der sendende Server gerade kennt. Deshalb müssen beide Postfächer aktiv bleiben, und nach dem Cutover sollte ein finaler imapsync-Lauf die letzten Nachrichten vom alten auf den neuen Server holen. Verloren geht so nichts.
-
Kann ich die Migration ohne Downtime durchführen?
Ja — mit niedriger TTL, parallelem Betrieb beider Server und gründlichen Vorabtests via hosts-File ist eine Migration praktisch ohne wahrnehmbaren Ausfall möglich. Einzig die DNS-Propagation kann zu kurzzeitig unterschiedlichen Auslieferungen führen. Wer auf identischen Inhalt beider Server achtet, bemerkt davon nichts.
-
Muss ich mein SSL-Zertifikat manuell mitnehmen?
Nein, in den meisten Fällen nicht. Bei Let's Encrypt wird auf dem neuen Server automatisch ein neues Zertifikat ausgestellt, sobald die Domain auf den neuen Server zeigt. Bei kostenpflichtigen Zertifikaten von Anbietern wie Sectigo oder DigiCert können Sie die bestehenden Zertifikatsdateien (.crt, .key, .ca-bundle) in der Regel übertragen — sie sind nicht an einen Server gebunden.
-
Was tun, wenn die Site nach dem Cutover Fehler zeigt?
Erstens: nicht in Panik geraten. Prüfen Sie zuerst die Server-Logs (Apache/Nginx Error Log, PHP-Fehlerlog) — die meisten Probleme sind Pfad-, Berechtigungs- oder Konfigurationsfehler. Datenbankverbindung in der Konfigurationsdatei korrekt? Berechtigungen auf Verzeichnissen passend? Falls Sie in Zeitdruck sind, schalten Sie über DNS kurzzeitig wieder auf den alten Server zurück — er läuft ja noch.
-
Wie übertrage ich meine Domain selbst zum neuen Provider?
Die Domain-Übertragung (Transfer) ist separat von der Website-Migration. Sie benötigen einen AuthCode/EPP-Code vom alten Registrar, hinterlegen ihn beim neuen Provider und bestätigen den Transfer per E-Mail an den Admin-Kontakt. Für .ch-Domains dauert der Transfer dank SWITCH meist nur wenige Stunden, für .com/.net 5–7 Tage. Wichtig: Die Domain darf nicht "Locked" sein und braucht eine aktuelle Admin-Mail-Adresse.
-
Was kostet eine professionelle Migration durch den Provider?
Bei vielen Schweizer Hostern liegt der Aufwand für eine professionelle Migration zwischen 200 und 800 Franken, abhängig von Komplexität. Cyberdine Systems bietet die Migration bestehender Webseiten kostenlos als Transfer-Service an — das ist gerade für KMU ohne eigenes IT-Team attraktiv, weil das Risiko technischer Patzer entfällt.
-
Gehen meine SEO-Rankings durch den Hosting-Wechsel verloren?
Nein, ein Hosting-Wechsel allein hat keinen negativen SEO-Effekt, sofern Domain, URL-Struktur und Inhalte gleich bleiben. Wichtig ist, dass alle 301-Weiterleitungen, robots.txt und Sitemap übernommen werden und die Site nach dem Cutover schnell lädt. Achten Sie auf identische Server-Antwortzeiten oder verbessern Sie diese — Geschwindigkeit ist ein Ranking-Faktor.
-
Wann sollte ich besser einen Profi mit der Migration beauftragen?
Wenn Ihr Geschäft direkt von der Website abhängt (Online-Shop, Buchungssystem), Sie keine technische Erfahrung mit DNS, SSH oder Datenbanken haben, oder mehrere Domains und Mail-Postfächer parallel zu migrieren sind — dann lohnt sich der Profi. Die Kosten oder ein kostenloser Transfer-Service sind oft günstiger als ein selbstverursachter Ausfall.