Du willst dein On-Premises-Exchange oder einen bestehenden IMAP-Mailserver zu Exchange Online in Microsoft 365 migrieren – aber welche Methode passt zu deiner Umgebung, und worauf kommt es dabei wirklich an? Dieser Leitfaden zeigt dir den gesamten Migrationsprozess für KMU mit unter 150 Postfächern: von der Methodenwahl über die genaue Reihenfolge beim MX-Cutover bis zum Monitoring und den typischen Fallen, die auch erfahrene Admins überraschen.

Voraussetzungen

Microsoft 365-Lizenzen für alle zu migrierenden Benutzer (mindestens Exchange Online Plan 1, z. B. in Microsoft 365 Business Basic enthalten)
On-Premises Exchange Server 2003 oder neuer mit konfiguriertem Outlook Anywhere (RPC over HTTP)
SSL-Zertifikat von einer öffentlich vertrauenswürdigen CA (kein Self-Signed-Zertifikat) für den Exchange-Server
Veröffentlichter Autodiscover-Endpunkt mit FQDN (z. B. mail.contoso.com), erreichbar aus dem Internet
Globales Administrator- oder Exchange-Administrator-Konto im Microsoft 365-Tenant
On-Premises-Migrationskonto mit FullAccess auf alle zu migrierenden Postfächer oder Receive As-Berechtigung auf die Postfachdatenbank
Verifizierte Domain im Microsoft 365-Tenant (TXT- oder MX-Record-Verifikation beim Registrar)
Zugang zum DNS-Provider für MX-, Autodiscover-CNAME- und SPF-Record-Änderungen
PowerShell mit installiertem ExchangeOnlineManagement-Modul
Für IMAP: CSV-Datei mit Spalten EmailAddress, UserName, Password; Ziel-Postfächer in Exchange Online müssen bereits existieren und lizenziert sein
MRM- und Archivierungsrichtlinien deaktiviert, Unified Messaging (UM) deaktiviert, bei Cutover: Verzeichnissynchronisierung (DirSync/Entra Connect) deaktiviert

Schritt 1: Migrationsmethode wählen – Entscheidungsbaum

Bevor du auch nur einen PowerShell-Befehl eingibst, musst du die richtige Methode wählen. Der folgende Entscheidungsbaum orientiert sich an der Exchange-Version deiner Quelle und der Postfachanzahl.

Quelle	Postfächer	Empfohlene Methode	Besonderheit
Exchange 2010, 2013, 2016, 2019	< 150	Cutover-Migration	Alle Postfächer auf einmal; DirSync muss deaktiviert sein
Exchange 2010, 2013, 2016, 2019	< 150, Koexistenz gewünscht	Express-Hybrid (Minimal Hybrid)	Schrittweise Migration, erfordert Azure AD Connect
Exchange 2003, 2007	beliebig	Cutover oder Staged	Staged nur für 2003/2007; erfordert DirSync
Exchange 2010+ mit > 150 Postfächern	> 150	Exchange Hybrid	Vollständige Hybrid-Konfiguration, kein Cutover
Beliebiger IMAP-Server (inkl. Gmail, Dovecot, Lotus Notes)	beliebig	IMAP-Migration	Nur E-Mails; Kalender/Kontakte separat übertragen

Wichtig: Staged-Migration funktioniert ausschließlich mit Exchange 2003 und Exchange 2007. Ein Versuch, Exchange 2010-Postfächer per Staged-Migration zu migrieren, wird vom System abgelehnt.

Schritt 2: Exchange Online PowerShell einrichten und Konnektivität testen

Installiere das Exchange Online Management-Modul und teste die Verbindung zum On-Premises-Server, bevor du irgendeinen Migrationsbatch erstellst.

# Exchange Online PowerShell-Modul installieren und verbinden
Install-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# Konnektivitaet zum On-Premises-Exchange testen (Autodiscover)
$Credentials = Get-Credential
$TSMA = Test-MigrationServerAvailability `
    -ExchangeOutlookAnywhere `
    -Autodiscover `
    -EmailAddress administrator@contoso.com `
    -Credentials $Credentials

# Ergebnis pruefen – muss "Success" anzeigen
$TSMA.Result

Schlägt Test-MigrationServerAvailability fehl, prüfe zuerst das SSL-Zertifikat und die Erreichbarkeit von Outlook Anywhere aus dem Internet (Tipp: Microsoft Remote Connectivity Analyzer). Ein Self-Signed-Zertifikat führt zwingend zum Fehler „The remote certificate is invalid according to the validation procedure".

Schritt 3: Migration Endpoint erstellen

# Cutover-Endpoint aus den getesteten Verbindungseinstellungen erstellen
New-MigrationEndpoint `
    -ExchangeOutlookAnywhere `
    -Name CutoverEndpoint `
    -ConnectionSettings $TSMA.ConnectionSettings

# Endpoint-Details pruefen
Get-MigrationEndpoint CutoverEndpoint | `
    Format-List EndpointType,ExchangeServer,UseAutoDiscover,Max*

Für eine IMAP-Migration sieht der Endpoint anders aus:

# IMAP-Endpoint erstellen (Port 993, SSL)
New-MigrationEndpoint `
    -IMAP `
    -Name IMAPEndpoint `
    -RemoteServer mail.contoso.com `
    -Port 993 `
    -Security Ssl

Schritt 4: MX-TTL rechtzeitig absenken

Senke den TTL-Wert deines MX-Records mindestens 24–48 Stunden vor dem geplanten Cutover auf 300–3600 Sekunden ab. Dadurch propagiert die spätere MX-Änderung in wenigen Minuten statt in 24–48 Stunden. Beispiel für Azure DNS:

# MX-TTL in Azure DNS auf 300 Sekunden absenken
Set-AzDnsRecordSet `
    -ResourceGroupName myRG `
    -ZoneName contoso.com `
    -Name '@' `
    -RecordType MX `
    -Ttl 300

Beim Registrar deiner Wahl machst du das entsprechend im DNS-Verwaltungsportal. Vergiss nicht, auch den SPF-Record und den Autodiscover-CNAME vorzubereiten.

Schritt 5: Migrationsbatch erstellen und starten

Cutover-Migration

# Batch erstellen und direkt automatisch starten
New-MigrationBatch -Name CutoverBatch -SourceEndpoint CutoverEndpoint -AutoStart

# ODER: Batch manuell starten
New-MigrationBatch -Name CutoverBatch -SourceEndpoint CutoverEndpoint
Start-MigrationBatch -Identity CutoverBatch

IMAP-Migration

Erstelle zunächst die CSV-Datei mit den Zugangsdaten aller Postfächer. Beachte: Die Ziel-Postfächer in Exchange Online müssen bereits existieren und lizenziert sein – IMAP erstellt keine neuen Postfächer.

# imap_migration.csv – Beispiel
EmailAddress,UserName,Password
usera@contoso.com,contoso/usera,P@ssw0rd1
userb@contoso.com,contoso/mailadmin/userb,P@ssw0rd2

# IMAP-Batch erstellen und starten
New-MigrationBatch `
    -Name IMAPBatch `
    -SourceEndpoint IMAPEndpoint `
    -CSVData ([System.IO.File]::ReadAllBytes('C:\imap_migration.csv')) `
    -AutoStart

Schritt 6: Migrationsbatch überwachen

Die Batch-Status-Reihenfolge bei Cutover lautet: Created → Starting → Syncing → Synced → Completing → Completed. Batches im Status „Synced with Errors" werden alle 24 Stunden inkrementell synchronisiert.

# Gesamtstatus aller Batches
Get-MigrationBatch | `
    Format-List Name,Status,TotalCount,SyncedCount,FailedCount,PercentageComplete,LastSyncedTime

# Status eines einzelnen Batches
Get-MigrationBatch -Identity CutoverBatch | `
    Format-List Status,TotalCount,SyncedCount,FailedCount,LastSyncedTime

# Status aller einzelnen Postfaecher im Batch
Get-MigrationUser -BatchId CutoverBatch | `
    Format-List EmailAddress,Status,Error

# Nur fehlerhafte Postfaecher anzeigen
Get-MigrationUser -BatchId CutoverBatch -Status Failed | `
    Format-List EmailAddress,Error

Als Orientierung für die Migrationsdauer: Postfächer bis 10 GB benötigen im Median 1 Tag (P90: 3 Tage). Postfächer zwischen 10 und 50 GB liegen bei 2 Tagen Median (P90: 6 Tage). Postfächer über 200 GB werden von Exchange Online nicht unterstützt. Standardmäßig werden maximal 20 Postfächer gleichzeitig synchronisiert – dieser Wert lässt sich im EAC oder per PowerShell erhöhen.

Schritt 7: MX-Record und Autodiscover umstellen

Sobald der Migrationsbatch den Status Synced erreicht hat und alle Postfächer erfolgreich synchronisiert wurden, kannst du den MX-Record umstellen. Tu das nicht früher – sonst landen eingehende E-Mails bereits in Exchange Online, während die Migration noch läuft.

# MX-Record nach Migration (beim DNS-Provider setzen):
Typ:       MX
Hostname:  @
Ziel:      contoso-com.mail.protection.outlook.com
Priorität: 0
TTL:       3600

# Autodiscover-CNAME (beim DNS-Provider setzen):
Typ:    CNAME
Alias:  autodiscover
Ziel:   autodiscover.outlook.com

# Auf dem On-Premises-Exchange-Server (Exchange Management Shell):
# Internen Autodiscover-URI deaktivieren, damit Outlook-Clients
# sich ab sofort mit Exchange Online verbinden
Set-ClientAccessServer -Identity <ServerName> -AutoDiscoverServiceInternalUri $null

Schritt 8: Lizenzen zuweisen und Batch abschließen

Weise den migrierten Benutzern unmittelbar nach Erstellung der Cloud-Konten eine Microsoft 365-Lizenz zu. Ohne Lizenz wird das Postfach nach 30 Tagen Nachfrist automatisch deaktiviert.

# Lizenzzuweisung per Microsoft Graph PowerShell
Connect-MgGraph -Scopes "User.ReadWrite.All","Organization.Read.All"
Set-MgUserLicense `
    -UserId usera@contoso.com `
    -AddLicenses @{SkuId = '<SKU-ID>'} `
    -RemoveLicenses @()

Warte nach der MX-Umstellung mindestens 72 Stunden, bevor du den Migrationsbatch abschließt und löschst. Externe Mailsysteme können bis zu 72 Stunden benötigen, um den neuen MX-Eintrag zu übernehmen. Während dieser Zeit sorgt der Batch dafür, dass noch eingehende E-Mails ins Exchange-Online-Postfach synchronisiert werden.

# Batch abschliessen (erst nach 72h MX-Nachlauf!)
Complete-MigrationBatch -Identity CutoverBatch

# Batch loeschen
Remove-MigrationBatch -Identity CutoverBatch

Kalender und Kontakte bei IMAP-Migration nachziehen

IMAP migriert ausschließlich E-Mails aus Posteingang und E-Mail-Ordnern. Kalender, Kontakte und Aufgaben bleiben komplett auf der Strecke. Für KMU gibt es drei Wege, diese Daten zu retten:

Selbst-Export durch Benutzer: Outlook → Datei → Öffnen und Exportieren → Importieren/Exportieren → In Datei exportieren → Outlook-Datendatei (.pst). Nach Migration die PST-Datei im neuen Outlook-Profil importieren.
Zentraler PST-Import per Microsoft Purview: Admin erstellt PST-Exportaufträge per Exchange Management Shell (New-MailboxExportRequest), lädt die PST-Dateien per AzCopy hoch und importiert sie über das Microsoft Purview Compliance Portal (Datenimport). Passwortgeschützte oder verschlüsselte PST-Dateien werden abgelehnt.
Drittanbieter-Tools: BitTitan MigrationWiz oder CodeTwo Office 365 Migration migrieren auch Kalender, Kontakte und öffentliche Ordner und sind für komplexere Szenarien empfehlenswert.

Eine solide Übersicht über DNS-Records (MX, CNAME, TXT/SPF) findest du in der Anleitung DNS-Records erklärt: A, AAAA, CNAME, MX, TXT – hilfreich, wenn du die Record-Typen noch einmal nachschlagen möchtest.

Troubleshooting / Typische Fehler

„The remote certificate is invalid according to the validation procedure" – Ursache: Outlook Anywhere ist mit einem Self-Signed-Zertifikat konfiguriert. Fix: Zertifikat von einer öffentlich vertrauenswürdigen CA (z. B. DigiCert, Let's Encrypt) installieren und in IIS/Exchange binden.
Batch vorzeitig gelöscht – E-Mails gehen verloren – Ursache: Cutover-Batch gelöscht, bevor die 72-stündige MX-Propagation abgelaufen ist. Fix: Batch nur löschen, wenn „Last Synced Time" einen neueren Zeitstempel als den MX-Umstellungszeitpunkt zeigt und 72 Stunden vergangen sind.
„A recipient wasn't found for user@contoso.com on the target" – Ursache: Bei IMAP-Migration existiert das Ziel-Postfach in Exchange Online nicht, oder die E-Mail-Adresse in der CSV stimmt nicht mit einer Proxy-Adresse des Cloud-Postfachs überein. Fix: Postfach anlegen, lizenzieren und E-Mail-Adresse in der CSV prüfen.
Winmail.dat-Anhänge nach IMAP-Migration – Ursache: IMAP kennt kein TNEF (Transport Neutral Encapsulation Format). Fix: Im On-Premises-Exchange per Set-RemoteDomain -TNEFEnabled $false deaktivieren oder empfängerbasiert lösen.
Doppelte E-Mails / Postfach-Kontingent erschöpft (Gmail-Quelle) – Ursache: Gmail-Labels erzeugen mehrfache Kopien derselben E-Mail, wenn der Ordner [Gmail] nicht ausgeschlossen wird. Fix: Ordner [Gmail] beim Erstellen des IMAP-Batches explizit ausschließen.
Throttling-Fehler / Migration stagniert – Ursache: Standard-Limit von 20 gleichzeitigen Postfach-Migrationen erreicht, oder zu viele Verbindungen zum IMAP-Quellserver. Fix: Throttling-Policy auf On-Premises prüfen mit Get-ThrottlingPolicy | Format-List Name,RCAMaxConcurrency,EWSMaxConcurrency, Wert erhöhen oder Batch-Größe reduzieren.
Fehlende Lizenzzuweisung / Postfach deaktiviert – Ursache: Lizenz erst nach der Migration zugewiesen, Nachfrist von 30 Tagen überschritten. Fix: Lizenz sofort nach Erstellung des Cloud-Kontos zuweisen, nicht erst nach Abschluss der Migration.
DirSync läuft gleichzeitig mit Cutover-Batch – Ursache: Azure AD Connect / Entra Connect war bei Start der Cutover-Migration noch aktiv. Fix: DirSync vor der Cutover-Migration deaktivieren. Hinweis: Bei Staged- und Hybrid-Migrationen ist DirSync dagegen Voraussetzung.
MRM-Richtlinien erzeugen Datenverlust-Warnungen – Ursache: Aktive MRM-Richtlinien verschieben oder löschen Items während der Migration. Fix: Alle MRM- und Archivierungsrichtlinien vor der Migration deaktivieren.

Häufige Fragen

Welche Migrationsmethode ist für 80 Postfächer auf Exchange 2016 empfehlenswert?

Bei Exchange 2010 oder neuer und weniger als 150 Postfächern empfiehlt Microsoft die Cutover-Migration oder Express-Hybrid (Minimal Hybrid). Cutover migriert alle Postfächer auf einmal – ideal über ein Wochenende – und ist einfacher zu administrieren, da keine Azure AD Connect-Einrichtung erforderlich ist. Express-Hybrid bietet mehr Flexibilität (schrittweise Migration, Koexistenz von On-Premises und Cloud), erfordert aber Azure AD Connect und mehr Vorbereitungsaufwand.

Was passiert mit Kalender und Kontakten bei der IMAP-Migration?

Diese werden von der IMAP-Migration komplett ausgelassen. Workarounds: (1) Benutzer exportieren selbst per Outlook-Datei (.pst) ihre Kalender und Kontakte und importieren diese nach der Migration ins neue Profil. (2) Der Admin erstellt PST-Exportaufträge per Exchange Management Shell und importiert diese über das Microsoft Purview Compliance Portal. (3) Drittanbieter-Tools wie BitTitan MigrationWiz migrieren auch Kalender und Kontakte vollständig.

Wann genau soll der MX-Record umgestellt werden?

Der MX-Record wird erst umgestellt, nachdem alle Postfächer erfolgreich synchronisiert wurden (Status „Synced" im Migrationsbatch). 24–48 Stunden vorher den TTL-Wert des MX-Records auf 300–3600 Sekunden absenken. Nach der MX-Umstellung mindestens 72 Stunden warten, bevor der Migrationsbatch gelöscht wird – externe Mailsysteme benötigen diese Zeit, um den neuen MX-Eintrag zu übernehmen.

Wie überwache ich den Fortschritt und greife bei Fehlern ein?

Im Exchange Admin Center (admin.exchange.microsoft.com) unter Migration → Migrationsbatches werden Status, Prozentsatz, Fehleranzahl und „Last Synced Time" angezeigt. Per PowerShell liefern Get-MigrationBatch und Get-MigrationUser detaillierte Informationen. Bei Fehlern sendet Exchange Online eine E-Mail mit dem Betreff „E-mail migration batch has finished - with errors" inklusive herunterladbarem Fehlerbericht. Fehlgeschlagene Postfächer können im EAC per „Resume migration" neu gestartet werden.

Muss der On-Premises-Exchange-Server nach der Migration weiterlaufen?

Nach abgeschlossener Cutover-Migration kann der On-Premises-Exchange-Server dekommissioniert werden. Vorher sicherstellen: alle E-Mails werden direkt an Exchange Online geroutet, der Autodiscover-DNS-CNAME zeigt auf autodiscover.outlook.com, und Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null wurde ausgeführt. Microsoft empfiehlt, vor der Dekommissionierung den Microsoft-Support zu kontaktieren, um unbeabsichtigte Folgen zu vermeiden.

Kann ich Exchange 2010 per Staged-Migration migrieren?

Nein. Staged-Migration funktioniert ausschließlich mit Exchange 2003 und Exchange 2007. Für Exchange 2010, 2013 und 2016 sind Cutover-Migration (unter 150 Postfächer), Express-Hybrid oder vollständige Exchange Hybrid-Migration vorgesehen. Eine versuchte Staged-Migration von Exchange 2010 wird vom System abgelehnt.

Fazit

Für die meisten KMU unter 150 Postfächern ist die Cutover-Migration der pragmatischste Weg zu Exchange Online: überschaubare Vorbereitung, klare Reihenfolge, kein dauerhafter Parallelbetrieb. IMAP eignet sich für Nicht-Exchange-Quellen, verlangt aber eine separate Strategie für Kalender und Kontakte. Die kritischsten Punkte in beiden Szenarien sind die TTL-Vorbereitung vor dem MX-Cutover, die 72-stündige Wartezeit vor dem Batch-Löschen und die sofortige Lizenzzuweisung nach Postfach-Erstellung. Wer diese drei Regeln befolgt, vermeidet die häufigsten und schmerzhaftesten Migrationsfehler.

Für die Benutzerverwaltung nach der Migration lohnt sich ein Blick auf Entra ID: Benutzer, Gruppen und Lizenzen verwalten. Wer zusätzlich MFA und bedingten Zugriff für die migrierten Konten einrichten möchte, findet alles Nötige in Microsoft 365 MFA und Conditional Access mit Entra ID.

Weiterführende Anleitungen und Quellen

Quellen: Decide on a migration path – Microsoft Learn | Cutover email migration – Microsoft Learn | IMAP mailbox migration – Microsoft Learn | Manage migration batches – Microsoft Learn | Troubleshoot IMAP migration – Microsoft Learn