Das Wichtigste in Kürze
- Warum wechseln? STRATO ist ein solider Einstieg, aber wachsende Anforderungen wie mobiles Arbeiten, Sicherheit und Microsoft 365 Integration machen Exchange Online langfristig attraktiver.
- Cutover-Migration = alles auf einmal: Alle Postfächer werden zu einem festen Zeitpunkt umgestellt – ohne Parallelbetrieb. Microsoft empfiehlt das Verfahren für bis zu 150 Postfächer.
- STRATO = IMAP, kein Exchange: Technisch läuft die Migration über IMAP (imap.strato.de), nicht über klassische Exchange-Cutover-Prozesse – das Prinzip bleibt aber gleich.
- Komplexität wird oft unterschätzt: Unterschiedliche Postfachkonfigurationen, fehlende Passwörter und veraltete DNS-Einträge erfordern eine gründliche Vorbereitung.
- Vier Erfolgsfaktoren: Gutes Timing, saubere DNS-Umstellung, vorbereitete Endgeräte und eine solide Sicherheitsbasis (z. B. MFA, Spamfilter) sind entscheidend.
- CodeKlar als Partner: Wir begleiten die Migration ganzheitlich – von der Analyse bis zur Nachbetreuung – für einen sicheren und stabilen Betrieb.
Was ist eine Cutover-Migration?
Cutover-Migration (auf Deutsch auch „Übernahmemigration“) bezeichnet eine E-Mail-Migrationsmethode, bei der alle Postfächer in einem einzigen, eng gefassten Zeitfenster von der Quellplattform zu Exchange Online übertragen werden. Es gibt keinen verlängerten Parallelbetrieb beider Systeme, sondern einen klar definierten Umschaltzeitpunkt:
- Alte Postfächer (z. B. bei STRATO): werden am Stichtag abgeschaltet – neue eingehende E-Mails landen dort nicht mehr.
- Neue Exchange-Online-Postfächer: treten sofort an deren Stelle und sind für ein- und ausgehende E-Mails aktiv.
- DNS-Einträge: MX-Record, Autodiscover und weitere Einträge werden auf Exchange Online umgestellt, sodass der gesamte Mailfluss über das neue System läuft.
Microsoft beschreibt den typischen Ablauf einer Übernahmemigration in neun Hauptschritten: von der Benachrichtigung der Benutzer über die Domänenverifizierung, das Erstellen des Migrationsendpunkts und das Migrieren der Postfächer bis hin zur DNS-Umstellung, Lizenzvergabe und dem abschließenden Begrüßungsschreiben an die Nutzer.
Dieses Verfahren wirkt auf den ersten Blick attraktiv, weil es schnell und übersichtlich ist. Besonders kleine und eher standardmäßige Umgebungen profitieren davon, dass kein wochenlanges Nebeneinander zweier Systeme verwaltet werden muss. Microsoft empfiehlt die Cutover-Methode offiziell für Organisationen mit weniger als 2.000 Postfächern, rät aber aus Praxisgründen dazu, nur 150 Postfächer oder weniger auf einmal zu migrieren.
Der Haken: Ohne Parallelbetrieb gibt es kein Sicherheitsnetz. Fehler betreffen sofort alle Benutzer gleichzeitig. Es gibt kein sanftes Zurück – ist der Schalter umgelegt, muss das neue System funktionieren. E-Mails, die an lokale Benutzer gesendet werden, deren Postfächer bereits migriert sind, werden weiterhin an das alte System geleitet, bis der MX-Eintrag geändert wird. Das bedeutet: Zwischen Migration und DNS-Umstellung besteht ein kritisches Zeitfenster, in dem E-Mails am falschen Ort landen können.
Cutover-Migration vs. IMAP-Migration: Was gilt bei STRATO?
Ein häufiges Missverständnis betrifft die technische Abgrenzung: Die offizielle Microsoft-Dokumentation zur „Exchange-Übernahmemigration“ setzt voraus, dass die Quellumgebung ein lokaler Exchange Server 2003 oder höher ist. STRATO stellt jedoch keinen On-Premises-Exchange-Server bereit, sondern ein gehostetes IMAP/POP3-Mailsystem.
Für die Migration von STRATO zu Exchange Online kommt daher eine IMAP-Migration zum Einsatz. Das zeigt auch die offizielle STRATO-FAQ zur Migration: Dort wird als Migrationstyp explizit „IMAP-Migration“ gewählt und als IMAP-Server imap.strato.de eingetragen.
Was bedeutet das in der Praxis?
- Das Cutover-Prinzip (alle Postfächer auf einmal umstellen, kein dauerhafter Parallelbetrieb) bleibt konzeptionell bestehen.
- Die technische Umsetzung unterscheidet sich: Statt einer EWS-basierten Verbindung zum lokalen Exchange wird ein IMAP-Migrationsendpunkt im Exchange Admin Center angelegt und ein Migrationsbatch erstellt.
- Für den Migrationsbatch wird eine CSV-Datei benötigt, die pro Postfach drei Angaben enthält: die Ziel-E-Mail-Adresse (Exchange Online), den STRATO-Benutzernamen und das zugehörige Passwort.
- IMAP-Migrationen übertragen nur E-Mail-Nachrichten – keine Kalender, Kontakte oder Aufgaben. Diese müssen separat migriert werden (z. B. über PST-Export/-Import oder manuelle Übernahme).
Tipp: Wer bei STRATO E-Mails per POP3 abruft, hat die Nachrichten möglicherweise nur lokal auf dem PC – nicht auf dem Server. In diesem Fall muss die Migration über einen PST-Import oder manuelles Verschieben innerhalb von Outlook erfolgen. Eine serverseitige IMAP-Migration greift hier ins Leere, weil das Quellpostfach auf dem Server leer sein kann.
Warum STRATO Migrationen oft unterschätzt werden
Viele Unternehmen gehen davon aus, dass der Umzug von STRATO zu Microsoft 365 ein einfacher technischer Datenumzug ist. In der Praxis zeigt sich jedoch immer wieder, dass STRATO-Umgebungen heterogener sind als erwartet. Typische Herausforderungen:
- Uneinheitliche Postfach-Konfiguration: Manche Postfächer werden per IMAP abgerufen, andere noch per POP3. Jedes Postfach kann individuelle Einstellungen haben, die bei der Migration berücksichtigt werden müssen.
- Weiterleitungen und Alias-Chaos: Häufig existieren Weiterleitungen, Sammelpostfächer oder Alias-Adressen ohne aktuelle Dokumentation. Wird eine Weiterleitung vergessen, erhalten bestimmte Empfänger nach dem Cutover keine E-Mails mehr.
- Vergessene Passwörter: Für die IMAP-Migration wird das Passwort jedes STRATO-Postfachs benötigt. In gewachsenen Umgebungen sind diese oft unbekannt. Das Zurücksetzen kostet Zeit und erfordert Zugriff auf das STRATO-Kundencenter.
- Historisch gewachsene DNS-Einträge: Im Laufe der Jahre sammeln sich DNS-Einstellungen (MX, SPF, TXT) an, die niemand mehr hinterfragt. Ungenutzte oder widersprüchliche Einträge erschweren die Umstellung erheblich.
- Lokale Mail-Client-Sonderfälle: Benutzer haben Outlook-Profile oft individuell eingerichtet – mit lokalen PST-Archiven, manuellen Servereinträgen und Sonderkonfigurationen auf mobilen Geräten. Nach der DNS-Umstellung versuchen diese Clients sich womöglich mit den alten STRATO-Zugangsdaten am neuen Server anzumelden und werfen Fehlermeldungen.
Fazit: Ohne gründliche Bestandsaufnahme und Bereinigung im Vorfeld riskiert man am Cutover-Tag Überraschungen, die den gesamten Mailbetrieb lahmlegen können. Analyse vor Aktion ist die wichtigste Regel.
Kritische Punkte bei einer Cutover-Migration
Eine erfolgreiche Migration entscheidet sich nicht am Migrationstag, sondern in der Vorbereitung. Vier Bereiche sind besonders kritisch:
Timing & Kommunikation
Ein schlecht gewählter Cutover-Termin oder fehlende Nutzer-Information führt schnell zu:
- vermeintlichen Mailverlusten (Nutzer können kurzfristig nicht auf Postfächer zugreifen)
- Support-Überlastung (alle Benutzer sind gleichzeitig betroffen)
- unnötiger Unruhe im Unternehmen
Laut Microsoft-Dokumentation sollte die erste Maßnahme einer Übernahmemigration darin bestehen, die Benutzer über anstehende Änderungen zu benachrichtigen. Empfehlung: Ein Wartungsfenster einrichten (z. B. Freitagabend oder Wochenende), den lokalen Server für Benutzer sperren und dann den Migrationsbatch abschließen – so sind die Postfächer auf dem aktuellsten Stand.
DNS Umstellung
Die E-Mail-Zustellung hängt nach dem Cutover komplett von korrekt gesetzten DNS-Einträgen ab. Folgende Einträge müssen exakt zusammenspielen:
| DNS-Eintrag | Funktion | Risiko bei Fehler |
| MX-Record | Leitet eingehende E-Mails an Exchange Online | E-Mails kommen beim falschen Server an |
| Autodiscover | Steuert Outlook-Client-Konfiguration automatisch | Outlook findet den richtigen Server nicht, Profile brechen |
| SPF | Autorisiert Sender-Server | Ausgehende E-Mails landen im Spam beim Empfänger |
| DKIM | Signiert E-Mails kryptographisch | Empfangende Server stufen E-Mails als unsicher ein |
| DMARC | Regelt Umgang mit fehlgeschlagener SPF/DKIM-Prüfung | Spoofing wird nicht erkannt, Zustellprobleme |
DNS-Hoheit bedeutet nicht nur, dass irgendwo Zugangsdaten existieren, sondern dass Änderungen an den autoritativen Zonen kurzfristig, reproduzierbar und auditierbar möglich sind. Wenn ein externer Provider Änderungen nur mit Ticket-Laufzeiten umsetzt, steigt das Risiko erheblich. Bereits ein kleiner Konfigurationsfehler oder eine falsche TTL kann bewirken, dass E-Mails verzögert oder gar nicht ankommen.
Praxis-Tipp: Sobald der Migrationsbatch abgeschlossen ist, muss der MX-Eintrag im DNS umgestellt werden – ab diesem Zeitpunkt werden die E-Mails von Exchange Online verwaltet.
Benutzer & Endgeräte
Eine technische Migration allein genügt nicht – die Clients der Benutzer müssen mitziehen. Relevante Aufgaben:
- Outlook-Profile: müssen ggf. neu eingerichtet oder über Autodiscover automatisch aktualisiert werden. Auch der Autodiscover-DNS-Eintrag (lokal und extern) muss korrekt angepasst werden.
- Mobilgeräte: benötigen den neuen Exchange-Account (ActiveSync/Modern Auth).
- Gespeicherte Anmeldedaten: Alte STRATO-Zugangsdaten in Outlook oder im Windows-Anmeldeinformationsspeicher sorgen für Fehlermeldungen.
- Lokale PST-Dateien: Müssen ggf. ins neue Postfach importiert werden.
Microsoft weist explizit darauf hin, dass Administratoren oder Benutzer die Desktopcomputer nach der Migration aktualisieren und für Microsoft 365 einrichten müssen, damit die Anmeldung über lokale Benutzeranmeldeinformationen funktioniert.
Sicherheit & Compliance
Mit dem Wechsel zu Exchange Online kommen neue Möglichkeiten, aber auch neue Verantwortung. Ohne sinnvolle Baseline (MFA, Zugriffsschutz, Spamfilter, Policies) wird das neue System schnell zur Baustelle. Mehr dazu im nächsten Abschnitt.
Sicherheits-Baseline nach dem Go-Live
Nach dem Go-Live verschiebt sich das Risikoprofil grundlegend: Identitäten, Tokens und Richtlinien bestimmen nun den Großteil der Angriffsfläche. Sicherheitslücken nach einer Migration entstehen häufig nicht durch fehlende Features, sondern durch falsche Prioritäten und inkonsistente Übergangslösungen aus der Migrationsphase.
Sofortmaßnahmen (direkt am ersten Tag)
Laut Fachexperten sollten folgende Maßnahmen unmittelbar umgesetzt werden, weil sie die größten Angriffsvektoren schließen, ohne den Betrieb zu destabilisieren:
- Privilegierte Konten sofort härten: MFA für alle Konten mit administrativen Rollen aktivieren – bevorzugt mit separater Admin-Identität. Unsichere Authentifizierungsmethoden deaktivieren.
- Legacy-Authentifizierung blockieren: Basic Auth für Exchange Online bei IMAP, POP3 und SMTP AUTH sperren. Diese Protokolle können MFA nicht unterstützen und sind bevorzugte Ziele für Kennwort-Spray-Angriffe.
- Protokollierung aktivieren: Audit- und Sign-in-Logs in Microsoft Entra ID sowie das Unified Audit Log in Microsoft Purview einrichten.
- Break-Glass-Konten anlegen: Mindestens zwei Notfallzugangskonten erstellen, testen und aus allen MFA-/Conditional-Access-Policies explizit ausschließen – bevor breitere Zugriffsrichtlinien aktiv werden.
Bewusst verzögerte Maßnahmen
Nicht alle Sicherheitsmaßnahmen sollten am Tag 1 aktiviert werden. Zu aggressive Härtung ohne Vorbereitung führt zu Self-Lockouts und pauschalen Ausnahmen, die die Baseline langfristig aushöhlen.
| Maßnahme | Empfohlener Zeitpunkt |
| Break-Glass-Konten, Admin-MFA, Basis-Logging | Sofort – vor jeder weiteren CA-Änderung |
| Blockieren von Legacy-Protokollen (Basic Auth) | Sofort oder sehr kurzfristig – vorher Abhängigkeiten (Scanner, Altclients) prüfen |
| Gerätebasierte Conditional Access (Compliance/Hybrid Join) | Verzögern – erst nach stabiler Geräte-Inventur und definiertem Ausnahmeprozess |
| Breitflächige MFA-Erzwingung für alle Nutzer | Stufenweise – zuerst Admins und Pilotgruppe, dann nach Messwerten erweitern |
Migrationsmethoden im Vergleich: Cutover, Staged und Hybrid
Wer vor einer Exchange-Online-Migration steht, begegnet drei Hauptmethoden. Die Wahl ist keine Geschmacksfrage, sondern ergibt sich aus den konkreten Rahmenbedingungen: Postfachanzahl, DNS-Hoheit, Koexistenzbedarf und Autodiscover-Zustand.
| Kriterium | Cutover | Staged | Hybrid |
| Migrationsmechanismus | EWS-Postfachkopie in einem engen Fenster (bzw. IMAP bei Drittanbietern wie STRATO) | EWS-Postfachkopie in Batches | Remote Move plus echte Koexistenz |
| Koexistenzfunktionen (z. B. Free/Busy) | Nicht dauerhaft vorgesehen | Meist nur eingeschränkt überbrückt | Explizit vorgesehen und technisch integriert |
| Autodiscover-/DNS-Komplexität | Hoch beim Umschaltzeitpunkt | Hoch über die gesamte Staging-Phase | Hoch in der Einrichtung, danach kontrollierbarer Betrieb |
| Identitätskonsistenz | Cloud-Benutzer müssen eindeutig zuordenbar sein | Zusätzlich klare Segmentierung je Batch | Zwingend: Entra ID Connect als Basis |
| OAuth-Relevanz | Indirekt (Client-Login, Modern Auth im Tenant) | Indirekt, erhöht Stabilität in gemischten Szenarien | Direkt erforderlich für robuste Cross-Premises-Flows |
Faustregel für die Entscheidung:
- Cutover/IMAP-Migration: Geeignet für Unternehmen, die keine langfristige Koexistenz benötigen, die DNS-Hoheit sauber kontrollieren und eine überschaubare Anzahl Postfächer (idealerweise ≤ 150) migrieren.
- Staged Migration: Wenn Benutzergruppen zeitversetzt migriert werden müssen, ohne vollständige Koexistenz – etwa bei gestaffelten Abteilungswechseln.
- Hybrid Migration: Wenn echte Koexistenzfunktionen (Free/Busy, Kalenderdelegationen, integrierter Transportfluss) über einen längeren Zeitraum benötigt werden.
Für die meisten kleinen und mittleren Unternehmen, die von STRATO zu Exchange Online wechseln, ist die Cutover-/IMAP-Variante der pragmatischste Ansatz – vorausgesetzt, die Vorbereitung stimmt.
Warum „mal eben selbst machen“ selten eine gute Idee ist
Online findet man zahlreiche Anleitungen nach dem Motto: „In 10 Schritten von STRATO zu Microsoft 365″. Die STRATO-FAQ selbst beschreibt den technischen Weg über IMAP-Migration in 18 Schritten, und auch Microsoft stellt umfangreiche Dokumentation bereit. Theoretisch könnte ein versierter Admin die Migration selbst durchführen.
Was in DIY-Anleitungen jedoch oft fehlt:
- Praxis-Erfahrung mit realen Umgebungen: Jede STRATO-Umgebung hat Eigenheiten. Ohne Erfahrung mit echten Migrationsprojekten ist man auf Überraschungen schlecht vorbereitet. Wie Daniel Gutermuth treffend formuliert: „Jede Exchange-Umgebung ist anders aufgebaut und somit können noch weitere Schritte anfallen“.
- Troubleshooting-Wissen: Was tun, wenn der Migrationsbatch hängt? Wenn E-Mails nach der Umstellung nicht ankommen? Wenn Autodiscover nicht greift? Anleitungen behandeln den Normalfall – nicht den Fehlerfall.
- Verantwortung für den laufenden Betrieb: Eine Anleitung übernimmt keine Verantwortung dafür, dass der Mailbetrieb am nächsten Morgen wirklich stabil läuft. Die Phase nach der Migration (Feintuning, Client-Support, Sicherheits-Baseline) ist mindestens ebenso aufwendig.
- Plan B bei Problemen: Bei einer Cutover-Migration gibt es keinen sanften Weg zurück. Das Starten eines Migrationsbatches allein bedeutet zwar noch keinen endgültigen Cutover – der Batch kopiert zunächst nur und synchronisiert dann alle 24 Stunden das Delta. Aber sobald der Batch explizit abgeschlossen und die DNS-Einträge umgestellt sind, ist der Punkt überschritten. Ohne klare Fallback-Strategie riskiert man unkontrollierte Ausfallzeiten.
Die entscheidende Frage ist daher nicht: „Kann man das selbst machen?“ – Sondern: „Was kostet es, wenn es am falschen Punkt schiefgeht?“ Für die meisten Unternehmen wiegen die potenziellen Kosten eines gescheiterten E-Mail-Wechsels deutlich schwerer als die Investition in erfahrene Migrations-Experten.
Wichtig: Lokale Postfächer sollten nach der Migration nicht gelöscht, sondern nur deaktiviert werden – ein versehentliches Löschen kann fatale Folgen haben, etwa den Verlust verknüpfter AD-Benutzer.
Unser Ansatz bei CodeKlar
Wir bei CodeKlar betrachten eine STRATO-zu-Exchange-Online-Migration nicht als reinen Technik-Job, sondern als geschäftskritisches Projekt. Unser Vorgehen im Überblick:
1. Strukturierte Voranalyse der STRATO-Umgebung Wir nehmen Ihre bestehende Mailumgebung detailliert unter die Lupe: Welche Postfächer gibt es? Welche Protokolle (IMAP/POP3) werden genutzt? Existieren Weiterleitungen, Aliase oder Sammelpostfächer? Wie sehen die aktuellen DNS-Einträge aus? Ziel ist ein vollständiges Bild, das Überraschungen am Cutover-Tag ausschließt.
2. Klare Migrationsstrategie und Zeitplanung Gemeinsam definieren wir den optimalen Cutover-Termin, die Reihenfolge der Postfächer, den Kommunikationsplan an die Nutzer und klare Verantwortlichkeiten. Für zeitkritische Umgebungen empfiehlt sich ein Wartungsfenster mit gesperrtem Quellsystem.
3. Saubere Vorbereitung von Microsoft 365 & Exchange Online Wir richten Ihren Microsoft-365-Tenant vollständig ein, bevor der Cutover beginnt: Domänenverifizierung, Benutzeranlage, Lizenzzuweisung, Sicherheits-Baseline (MFA, Conditional Access, Spamfilter) und Migrationsbatch-Vorbereitung.
4. Kontrollierte Umstellung mit minimierter Downtime Am Tag X starten wir den Migrationsbatch koordiniert, überwachen den Fortschritt, führen die DNS-Umstellung im richtigen Moment durch und validieren den E-Mail-Fluss. Der Batch synchronisiert zunächst die Inhalte und wird erst dann abgeschlossen, wenn alle Daten aktuell sind.
5. Begleitung nach dem Cutover In der kritischen Phase direkt nach dem Wechsel stehen wir für Support bereit: Client-Konfigurationen, mobile Geräte, Outlook-Profile, eventuelle Nachmigrationen (Kalender, Kontakte aus PST-Dateien) und Feintuning der Sicherheitseinstellungen. Ziel: ein stabiler, sicherer und zukunftsfähiger Betrieb.
Jetzt Migration geplant angehen
Steht bei euch der Wechsel von STRATO zu Exchange Online an – oder seid ihr unsicher, ob eine Cutover-Migration für euch die richtige Variante ist? Sprecht mit uns.
Unser Angebot: Wir planen und begleiten die komplette Cutover-Migration von STRATO zu Exchange Online – inklusive Bestandsaufnahme, Vorbereitung, Umschaltung und Nachbetreuung. Ihr erhaltet einen dedizierten Ansprechpartner und ein erprobtes Team, das genau diese Art von Migrationen regelmäßig umsetzt.
Jetzt unverbindliches Migrationsgespräch buchen und den Wechsel sicher angehen.
Kontaktieren Sie uns!
