Diese Anleitung führt Sie durch die Migration von On-Premises-Exchange oder einem IMAP-Mailserver zu Exchange Online in Microsoft 365, ausgelegt für KMU mit weniger als 150 Postfächern: Methodenwahl, Reihenfolge beim MX-Cutover, Überwachung der Migrationsbatches und typische Fehler.

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

Wählen Sie die Methode vor dem ersten PowerShell-Befehl. Maßgeblich sind die Exchange-Version der Quelle und die Zahl der Postfächer.

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 Microsoft Entra 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 nur mit Exchange 2003 und 2007.

Verifizieren: Sie haben eine Zeile der Tabelle eindeutig zugeordnet (Quellversion per Get-ExchangeServer | Format-List Name,AdminDisplayVersion, Postfachzahl per (Get-Mailbox -ResultSize Unlimited).Count in der Exchange Management Shell) und die Methode schriftlich festgelegt.

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

Installieren Sie das Modul ExchangeOnlineManagement und testen Sie die Verbindung zum On-Premises-Server, bevor Sie einen Migrationsbatch erstellen.

# 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üfen Sie zuerst das SSL-Zertifikat und die Erreichbarkeit von Outlook Anywhere aus dem Internet (Hilfsmittel: Microsoft Remote Connectivity Analyzer). Ein Self-Signed-Zertifikat führt zwingend zum Fehler „The remote certificate is invalid according to the validation procedure“.

Verifizieren: $TSMA.Result gibt Success aus.

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

Verifizieren: Get-MigrationEndpoint listet CutoverEndpoint (EndpointType ExchangeOutlookAnywhere) bzw. IMAPEndpoint (EndpointType IMAP).

Schritt 4: MX-TTL rechtzeitig absenken

Senken Sie den TTL-Wert Ihres 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

Bei anderen DNS-Anbietern ändern Sie den Wert im jeweiligen DNS-Verwaltungsportal. Bereiten Sie dabei auch den SPF-Record und den Autodiscover-CNAME vor.

Verifizieren: nslookup -type=MX contoso.com gegen den autoritativen Nameserver zeigt die neue TTL (z. B. 300).

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

Erstellen Sie zunächst die CSV-Datei mit den Zugangsdaten aller Postfächer. Die Ziel-Postfächer in Exchange Online müssen bereits existieren und lizenziert sein, denn IMAP-Migration legt keine Postfächer an.

# 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

Verifizieren: Get-MigrationBatch zeigt den Batch im Status Syncing.

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.

Verifizieren: Der Batch steht auf Synced, FailedCount ist 0 und Get-MigrationUser -Status Failed liefert keine Einträge.

Schritt 7: MX-Record und Autodiscover umstellen

Sobald der Migrationsbatch den Status Synced erreicht hat und alle Postfächer erfolgreich synchronisiert wurden, können Sie den MX-Record umstellen. Stellen Sie ihn nicht früher um, 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

Führen Sie den Befehl auf jedem Client-Access-Server aus.

Verifizieren: nslookup -type=MX contoso.com liefert contoso-com.mail.protection.outlook.com, nslookup autodiscover.contoso.com zeigt auf autodiscover.outlook.com, der Remote Connectivity Analyzer meldet für den Autodiscover-Test Erfolg.

Schritt 8: Lizenzen zuweisen und Batch abschließen

Weisen Sie 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 @()

Warten Sie nach der MX-Umstellung mindestens 72 Stunden, bevor Sie 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

Verifizieren: Im Microsoft 365 Admin Center zeigt jeder migrierte Benutzer eine zugewiesene Lizenz, Get-MigrationBatch meldet vor dem Löschen Completed.

Kalender und Kontakte bei IMAP-Migration nachziehen

IMAP migriert ausschließlich E-Mails aus Posteingang und E-Mail-Ordnern. Kalender, Kontakte und Aufgaben werden nicht übertragen. Dafür gibt es drei Wege:

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 eignen sich für komplexere Szenarien.

Die Record-Typen MX, CNAME und TXT/SPF erklärt die Anleitung DNS-Records erklärt: A, AAAA, CNAME, MX, TXT.

Troubleshooting / Typische Fehler

„The remote certificate is invalid according to the validation procedure“ – Ursache: selbstsigniertes Zertifikat für Outlook Anywhere. Fix: Zertifikat einer öffentlich vertrauenswürdigen CA 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 erst löschen, wenn „Last Synced Time“ nach der MX-Umstellung liegt und 72 Stunden vergangen sind.
„A recipient wasn't found for user@contoso.com on the target“ – Ursache: Das Ziel-Postfach existiert nicht, oder die Adresse in der CSV passt zu keiner Proxy-Adresse des Cloud-Postfachs. 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: Limit von 20 gleichzeitigen Migrationen erreicht oder zu viele Verbindungen zum IMAP-Quellserver. Fix: Throttling-Policy 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: 30 Tage Nachfrist ohne Lizenz überschritten. Fix: Lizenz sofort nach Erstellung des Cloud-Kontos zuweisen.
DirSync läuft gleichzeitig mit Cutover-Batch – Ursache: Microsoft Entra Connect (früher Azure AD Connect) war beim Start noch aktiv. Fix: Verzeichnissynchronisierung vorher deaktivieren. Bei Staged- und Hybrid-Migrationen ist sie dagegen Voraussetzung.
MRM-Richtlinien erzeugen Datenverlust-Warnungen – Ursache: aktive MRM-Richtlinien verschieben oder löschen Elemente während der Migration. Fix: MRM- und Archivierungsrichtlinien vorher 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, etwa über ein Wochenende, und ist einfacher zu administrieren, da keine Einrichtung von Microsoft Entra Connect erforderlich ist. Express-Hybrid bietet mehr Flexibilität (schrittweise Migration, Koexistenz von On-Premises und Cloud), erfordert aber Microsoft Entra Connect und mehr Vorbereitungsaufwand.

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

Die IMAP-Migration lässt sie aus. Übertragen Sie sie per PST-Export und -Import oder mit einem Migrationswerkzeug, siehe Abschnitt „Kalender und Kontakte bei IMAP-Migration nachziehen“.

Wann genau soll der MX-Record umgestellt werden?

Erst wenn alle Postfächer den Status „Synced“ haben. Die TTL senken Sie 24 bis 48 Stunden vorher, den Batch löschen Sie frühestens 72 Stunden nach der Umstellung (Schritte 4, 7 und 8).

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

Im Exchange Admin Center (admin.exchange.microsoft.com) unter Migration → Migrationsbatches, per PowerShell mit Get-MigrationBatch und Get-MigrationUser (Schritt 6). Bei Fehlern sendet Exchange Online eine E-Mail mit Fehlerbericht; fehlgeschlagene Postfächer starten Sie im EAC per „Resume migration“ neu.

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

Nach abgeschlossener Cutover-Migration können Sie ihn außer Betrieb nehmen, sobald MX und Autodiscover auf Exchange Online zeigen (Schritt 7). 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 nur mit Exchange 2003 und 2007. Für Exchange 2010 und neuer sind Cutover, Express-Hybrid oder Exchange Hybrid vorgesehen.

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. Entscheidend sind in beiden Fällen die rechtzeitig gesenkte TTL, 72 Stunden Wartezeit vor dem Löschen des Batches und die sofortige Lizenzzuweisung.

Die Benutzerverwaltung nach der Migration beschreibt Entra ID: Benutzer, Gruppen und Lizenzen verwalten. MFA und bedingten Zugriff für die migrierten Konten richten Sie mit Microsoft 365 MFA und Conditional Access mit Entra ID ein.

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