Website-Umzug: so gelingt die Migration ohne Ausfälle
Ein Umzug ist technisch kein Hexenwerk – aber in der Praxis voller Stolpersteine. Wer unvorbereitet vorgeht, riskiert Downtime, verlorene E-Mails oder SEO-Einbussen.
Ein Website-Umzug betrifft selten nur die Website. Dahinter hängen in der Regel E-Mail-Postfächer, DNS-Zonen, Formulare, Tracking-Integrationen und Redirects – und alles davon kann beim falschen Timing zur Fehlerquelle werden.
Dieser Beitrag zeigt eine bewährte Vorgehensweise aus unserer Projektpraxis: strukturiert, risikoarm und kontrolliert. Der Leitfaden passt für Umzüge vom Homepage-Baukasten zu Craft CMS oder Odoo, vom alten Shared-Hosting zum Hosting oder bei einem Relaunch mit neuer Plattform.
Analyse vor dem Umzug
Bevor irgendetwas umgestellt wird, muss klar sein, was überhaupt betroffen ist. Wir arbeiten dafür mit drei Blickwinkeln:
- Welche Dienste sind betroffen? Website-Hosting, E-Mail, DNS – jedes dieser drei Systeme hat eigene Abhängigkeiten und Umstellungsrisiken.
- Welche Systeme hängen daran? Formulare, Tracking (GA4, Matomo, Meta-Pixel), externe Dienste, CRM- oder Shop-Integrationen.
- Welche Inhalte müssen übernommen werden? Seiten, Medien, SEO-relevante URLs, Meta-Daten und strukturierte Daten.
Ziel ist eine vollständige Liste aller Abhängigkeiten – damit während der Migration keine Überraschungen auftauchen.
Grundprinzip
Drei Leitsätze tragen durch den ganzen Prozess:
- DNS ist die zentrale Steuerung. Wer das DNS kontrolliert, steuert, wohin Website und E-Mail fliessen.
- Website und E-Mail immer getrennt migrieren. Gleichzeitige Umstellung beider Dienste ist der häufigste Auslöser für Downtime und Mailverluste.
- Zuerst stabilisieren, dann umstellen. Neue Umgebung steht und läuft, bevor der Produktiv-Traffic geschaltet wird.
Das bewährte 8-Schritte-Vorgehen
In der Praxis hat sich folgende Reihenfolge etabliert. Jede Karte fasst einen Schritt zusammen:
1. Infrastruktur vorbereiten
- IST-Zustand dokumentieren: bei wem liegen Website, Mail, DNS heute? Der DNS-Analyser macht das in zwei Sekunden.
- Neues Hosting (z. B. Green) bereitstellen.
- E-Mail-Backups erstellen (z. B. im
mbox-Format). - Domain beim neuen Anbieter erfassen — falls auch transferiert wird, Auth-Code rechtzeitig anfordern (1–7 Werktage Vorlauf).
- DNS-Zone vorbereiten – aber nicht aktivieren.
- TTL der bestehenden Records 24–48 h vor dem geplanten Switch auf 300 senken — schnellerer Rollback im Notfall.
Website und E-Mail zeigen weiterhin auf den alten Anbieter. Die neue Umgebung steht im Hintergrund bereit.
2. DNS übernehmen
- DNS-Zone vollständig spiegeln: A, AAAA, CNAME, MX, TXT (SPF, Verifikations-Tokens), CAA — kein Eintrag darf vergessen gehen, sonst fällt beim NS-Switch etwas aus.
- Nameserver auf den neuen Anbieter umstellen.
- A- und MX-Records zeigen weiterhin auf die alten Systeme.
- Falls Cloudflare als Proxy aktiv: orange Wolke pro Eintrag bewusst setzen, sonst zeigt der A-Record nicht auf den echten Origin-Server.
Ergebnis: das DNS läuft neu über den Zielanbieter, Website und E-Mail bleiben unverändert erreichbar. Kein Nutzer merkt etwas.
3. E-Mail migrieren (kritisch)
- Liste aller aktiven Postfächer, Aliase und Verteiler erstellen — auch alte/private Adressen prüfen, an denen oft Banking-Logins, Newsletter oder Behörden hängen.
- Mail-Konten beim neuen Anbieter erstellen, möglichst mit identischen Adressen.
- IMAP-Sync starten (z. B. mit
imapsync, MailStore oder Thunderbird-Drag-and-Drop) — vor dem MX-Switch laufen lassen. - SPF, DKIM und DMARC korrekt setzen — DMARC fehlt oft, ist aber das Sicherheitsnetz gegen Domain-Spoofing.
- MX-Eintrag auf den neuen Anbieter umstellen.
- Senden und Empfangen ausführlich testen.
- Optional: Weiterleitung beim alten Anbieter einrichten.
- Temporäre Abwesenheitsmeldung aktivieren – unten findest du eine Mustervorlage.
Ziel: kein Mailverlust während der Umstellung.
4. Website bleibt vorerst unverändert
Die alte Website läuft weiter über ihren bisherigen Anbieter. Das DNS zeigt bewusst noch dorthin. Keine Downtime, keine gleichzeitigen Risiken – der Mail-Switch darf sich in Ruhe stabilisieren, bevor die Website dran ist.
5. Neue Website vorbereiten
- Subdomain anlegen, z. B.
web.meinedomain.ch. - Subdomain auf die neue Plattform zeigen (Craft, Odoo, Shopify …).
- Bei CMS-Umzug: Versionen dokumentieren — CMS-Version, PHP-/Node-Version, Datenbank-Engine, Plugin-Liste. Auf der Zielumgebung müssen gleichwertige oder neuere Versionen laufen.
- Konfigurations-Dateien separat sichern:
wp-config.php,.env,AdditionalConfiguration.php& Co. Sind oft nicht im Backup. - Bei Walled-Garden-Plattformen (Wix, Jimdo, Squarespace): Inhalte manuell sichern und auf neuer Plattform neu aufbauen — ein 1:1-Export ist nicht möglich.
- Website vollständig testen: Mobile, Performance, SSL, Formulare, Tracking.
Erst wenn die Subdomain-Version einwandfrei läuft, geht es an den Finalschritt.
6. SEO vorbereiten
- Redirects definieren: alte URLs → neue URLs (per
301). - Umsetzung direkt im neuen CMS oder Webserver – nicht erst in der Search Console.
- XML-Sitemap aktualisieren und bereitstellen.
Saubere Redirects sind die wichtigste SEO-Massnahme beim Umzug – sie retten Rankings und Backlinks.
7. Finaler Switch
- A-Record auf die neue Website zeigen lassen.
- CNAME für
wwwebenfalls anpassen. - SSL-Zertifikat auf der neuen Plattform ist bereit.
- Switch zu einer Tageszeit setzen, in der der Support beider Anbieter erreichbar ist — nicht spät abends, am Wochenende oder kurz vor Feiertagen.
- Nach dem Switch TTL der Records wieder hochziehen (auf 3600 oder höher).
Das ist der eigentliche Go-Live der Website.
8. Nachkontrolle
- Website erreichbar? HTTPS korrekt? Formulare funktionieren?
- E-Mail weiterhin stabil, Spam-Score sauber?
- DMARC-Reports prüfen — kommen 24–72 h nach Cutover und zeigen, ob etwas durch SPF/DKIM fällt.
- Monitoring aktiv: Google Search Console, Server-Logs, Performance-Tools.
- Nach 24–72 h erneut prüfen, nach 1 Woche stichprobenartig.
- Bei Auffälligkeiten gezielt nachbessern – Redirects, Meta-Daten, Bilder-Pfade.
E-Mail-Migrations-Dienste: das Rad nicht neu erfinden
Die rein technische Mail-Migration – Postfächer, Ordnerstrukturen, Adressbücher und Kalender von A nach B spiegeln – ist stumpfsinnig, zeitintensiv und fehleranfällig, wenn man sie selbst per IMAP-Sync baut. Spezialisierte Dienste übernehmen den Transfer automatisiert. Ein paar Empfehlungen aus der Praxis:
- Audriga – der de-facto-Standard im DACH-Raum. Überträgt IMAP, Exchange, Microsoft 365, Google Workspace samt Kalender und Kontakten. Viele Schweizer Hoster – unter anderem Hostpoint – setzen direkt auf Audriga, oft als White-Label unter eigener URL.
- Integrierte Migrations-Assistenten beim Ziel-Hoster. Infomaniak hat ein eigenes Tool. Microsoft 365 bringt den Migration Manager mit, Google Workspace den Data Migration Service. Lohnt sich, wenn das Ziel ohnehin eine dieser Plattformen ist.
- imapsync – das Open-Source-Kommandozeilen-Tool für IMAP-zu-IMAP-Transfers. Solide, battle-tested und kostenlos, aber ohne Komfortschicht und mit einer steilen Lernkurve – für technisch versierte Teams.
Unser Tipp: Frag beim Ziel-Hoster nach, ob ein Migrationsdienst enthalten ist. Bei vielen ist er kostenlos oder im Paket dabei – und spart dir Stunden Handarbeit an einem der kritischsten Punkte im Umzug.
Muster-Abwesenheitsmeldung während der Migration
In der kritischen Phase der E-Mail-Umstellung lohnt sich eine klare Ansage an deine Kontakte:
Wir stellen aktuell unsere E-Mail-Umgebung um. Sollte Ihre Anfrage nicht innert 48 Stunden beantwortet werden, bitten wir Sie, diese erneut zu senden. In dringenden Fällen erreichen Sie uns unter …
Häufige Fehler – und wie du sie vermeidest
- Website und Mail gleichzeitig umstellen. Zwei Baustellen, zwei Fehlerquellen.
- Fehlende SPF-/DKIM-Records. Deine Mails landen sonst im Spam-Ordner oder werden abgewiesen.
- Keine Redirects. Alte URLs laufen ins 404 – Google und Besucherinnen gleichermassen verloren.
- SSL nicht vorbereitet. Am Go-Live-Tag mit «Unsicher»-Warnung live zu gehen, kostet Vertrauen.
- DNS nicht sauber gespiegelt. Wenn beim neuen Anbieter MX, SPF oder DKIM fehlen, geht der Mail-Switch schief.
Best Practice in vier Sätzen
- Mail immer zuerst migrieren.
- Website erst am Schluss umstellen.
- DNS zentral kontrollieren.
- Migration in zwei Phasen durchführen – nie beide Systeme gleichzeitig.
Fazit
Ein Website-Umzug ist kein einzelner Schritt, sondern ein kontrollierter Prozess. Wer sauber trennt – Mail stabilisieren, Website getrennt migrieren, DNS bewusst steuern – reduziert das Risiko praktisch auf null.
Drei kostenlose Hilfsmittel, die dir beim Umzug Arbeit abnehmen — alles im Browser, keine Speicherung.
Umzugs-Checkliste
Wenige Fragen → strukturierter Fahrplan mit Reihenfolge, Zugängen und Warnhinweisen.
Konfigurieren →DNS-Analyser
Domain eintippen → wer hostet, wer mailt, welches CMS. Live aus deinem Browser.
Analysieren →Infrastruktur Umzugs-Lotse
Dein Umzugsdampfer seetauglich machen: Kombiniert DNS-Analyse + Konfigurator-Fragen zu einem persönlichen Kurs mit Hürden, Reihenfolge und PDF.
Kurs setzen
Migration in Planung oder bereits mitten drin?
Ob Relaunch mit neuer Plattform, Anbieterwechsel oder ein Umzug mitsamt Mail-Infrastruktur – wir begleiten Migrationen von der Analyse über die DNS- und Mail-Stabilisierung bis zum Go-Live und dem Monitoring danach. Besonders bei produktiven Systemen lohnt sich eine saubere technische Begleitung.