Microsoft 365 Migration planen: Was vor dem Umzug von E-Mails und Dateien geklärt sein muss

Eine Microsoft-365-Migration beginnt nicht mit dem Kopieren von Postfächern oder Dateien. Zuerst muss feststehen, welche Daten tatsächlich umziehen, wohin sie gehören, welche Benutzer und Berechtigungen weiter benötigt werden und wann E-Mail sowie Dateizugriffe auf die neue Umgebung umgeschaltet werden. Wer diese Punkte erst während der Migration klärt, riskiert doppelte Ablagen, fehlende Rechte, unterbrochenen Mailfluss und unnötige Nacharbeiten.

Erst klären, was überhaupt migriert werden soll

Eine Migration ist gleichzeitig eine technische und organisatorische Bestandsaufnahme. Vor dem ersten Kopiervorgang sollte deshalb feststehen, welche Postfächer, Verteiler, gemeinsamen Mailboxen, Dateien, Freigaben und Benutzer tatsächlich noch gebraucht werden.

Gerade bei älteren Umgebungen haben sich oft Strukturen angesammelt, die niemand bewusst geplant hat: ehemalige Mitarbeiter mit noch vorhandenen Postfächern, gemeinsam genutzte Konten, Dateien ohne klaren Eigentümer oder Freigaben, deren Zweck nicht mehr bekannt ist. Solche Altlasten ungeprüft in die neue Umgebung zu übernehmen spart kurzfristig Arbeit, verschiebt die Probleme aber nur.

Für den Start reicht eine einfache Migrationsliste:

Diese Übersicht muss noch keine vollständige technische Dokumentation sein. Sie soll zuerst sichtbar machen, welche Abhängigkeiten beim Umschalten betroffen sind.

E-Mail-Migration ist mehr als das Kopieren alter Nachrichten

Wie Postfächer migriert werden, hängt stark vom Ausgangssystem ab. Microsoft unterscheidet unter anderem Migrationen aus Exchange Server, anderen IMAP-fähigen Maildiensten und Google Workspace. Die verschiedenen von Microsoft unterstützten Wege werden in der Exchange-Online-Dokumentation beschrieben.

Bei einer IMAP-Migration ist eine Einschränkung besonders wichtig: Microsoft migriert darüber E-Mail-Nachrichten aus den Mailordnern, aber keine Kontakte, Kalender oder Aufgaben. Diese Daten benötigen gegebenenfalls einen anderen Migrationsweg. Wer nur prüft, ob die alten E-Mails angekommen sind, kann deshalb trotzdem wichtige Informationen übersehen.

Vor dem Umzug sollten außerdem Sonderfälle erfasst werden: Weiterleitungen, Aliase, gemeinsame Postfächer, Verteilergruppen, Regeln, Funktionsadressen und Konten, die von Anwendungen oder Geräten benutzt werden. Ein Scanner, der Rechnungen per SMTP verschickt, fällt im normalen Benutzervergleich schnell durchs Raster und macht sich dann erst nach der Umschaltung bemerkbar.

Domain und DNS bestimmen den eigentlichen Umschaltpunkt

Die Unternehmensdomain sollte vor der produktiven Umschaltung im Microsoft-365-Mandanten verifiziert sein. Microsoft empfiehlt außerdem, die benötigten Benutzer und Postfächer einzurichten, bevor der MX-Eintrag auf Microsoft 365 geändert wird. Microsoft beschreibt diesen Ablauf beim Hinzufügen einer eigenen Domain.

Der MX-Eintrag bestimmt, wohin neue E-Mails zugestellt werden. Eine Änderung daran ist deshalb kein nebensächlicher DNS-Schritt, sondern ein zentraler Cutover-Punkt der Migration.

Neben dem MX-Eintrag müssen weitere DNS-Einstellungen berücksichtigt werden. Dazu gehören je nach Umgebung beispielsweise Autodiscover und SPF sowie später DKIM und DMARC. Microsoft weist außerdem darauf hin, dass für eine Domain nur ein SPF-TXT-Eintrag verwendet werden sollte. Bestehende Absenderdienste müssen deshalb in das neue SPF-Konzept einbezogen werden, statt einfach einen zweiten SPF-Eintrag anzulegen. Die Microsoft-Dokumentation zu DNS-Einträgen nennt die benötigten Werte und Hinweise.

Entscheidend ist damit schon vor dem Termin: Wer kann die DNS-Einträge tatsächlich ändern? Ein sauber vorbereiteter Tenant hilft wenig, wenn am Umschalttag niemand Zugriff auf den Registrar oder DNS-Provider hat.

Dateien brauchen vor dem Kopieren ein sinnvolles Ziel

Beim Dateiumzug ist die wichtigste Frage nicht nur, wie viele Gigabyte kopiert werden müssen. Zuerst muss feststehen, welche Daten künftig persönlich und welche gemeinsam genutzt werden.

Persönliche Arbeitsdateien gehören typischerweise in OneDrive. Gemeinsame Abteilungs-, Projekt- oder Unternehmensdaten sind dagegen meist besser in SharePoint oder in den Dateien eines Teams aufgehoben. Eine alte Netzlaufwerksstruktur sollte nicht automatisch eins zu eins in persönliche OneDrives kopiert werden.

Microsoft beschreibt für Dateifreigaben einen Migrationsprozess aus Planung, Bewertung, Vorbereitung der Zielumgebung, eigentlicher Migration und anschließendem Benutzer-Onboarding. Der aktuelle Leitfaden für die Migration von File Shares zu OneDrive, Teams und SharePoint folgt genau diesen Phasen.

Für lokale Dateifreigaben kann Microsoft Migration Manager beziehungsweise das SharePoint Migration Tool die Quelle vorab scannen. Die Scan-Berichte zeigen unter anderem Datenmenge und mögliche Probleme, bevor die produktive Migration beginnt. Microsoft empfiehlt diese Bewertung ausdrücklich vor der Migration.

Berechtigungen nicht blind aus der alten Struktur übernehmen

Eine Dateimigration bietet die Gelegenheit, Berechtigungen nachvollziehbar neu zu ordnen. Das bedeutet nicht, jede Freigabe neu zu erfinden. Es bedeutet aber, vor dem Umzug zu prüfen, ob die vorhandenen Rechte weiterhin zum tatsächlichen Bedarf passen.

Besonders problematisch sind historische Einzelberechtigungen. Wenn über Jahre immer wieder einzelne Personen zu Ordnern hinzugefügt wurden, ist später kaum noch erkennbar, warum jemand Zugriff besitzt. Eine neue SharePoint-Struktur sollte möglichst mit klaren Gruppen und Verantwortlichkeiten arbeiten.

Microsoft Migration Manager kann bei Dateifreigaben vorhandene Berechtigungen übernehmen und Benutzerzuordnungen über Microsoft Entra ID oder eigene Mapping-Dateien herstellen. Die verfügbaren Einstellungen beschreibt Microsoft in der Dokumentation zu Migration Manager. Trotzdem sollte vorher entschieden werden, welche Rechte tatsächlich erhalten werden sollen. Eine technisch erfolgreiche Übernahme falscher Berechtigungen ist kein gutes Migrationsergebnis.

Datenmenge ist nicht die einzige relevante Größe

Die reine Datenmenge beeinflusst die Dauer einer Migration, sagt aber wenig über ihre Komplexität aus. Zehn Gigabyte sauber strukturierte Dokumente können einfacher umzuziehen sein als eine kleinere Ablage mit vielen tief verschachtelten Ordnern, Sonderberechtigungen und problematischen Dateinamen.

Deshalb sollte vorab nicht nur die Größe dokumentiert werden. Wichtiger sind zusätzlich die Anzahl der Benutzer, die Struktur der Ablage, Eigentümer, Berechtigungen und bekannte Sonderfälle.

Bei größeren Datenbeständen bietet sich häufig ein gestufter Ansatz an: Ein erster Lauf kopiert den Großteil der Daten, anschließend werden kurz vor dem Cutover nur noch Änderungen nachgezogen. Microsoft Migration Manager unterstützt bei Dateifreigaben inkrementelle Migrationen. Der Ablauf wird in der Dokumentation für File-Share-Migrationen beschrieben.

So lässt sich das eigentliche Umschaltfenster verkürzen. Voraussetzung ist allerdings, dass klar geregelt wird, wann Benutzer noch in der alten Ablage arbeiten dürfen und ab wann ausschließlich die neue Umgebung maßgeblich ist.

Eine Pilotgruppe findet Probleme, bevor alle betroffen sind

Eine Migration sollte nach Möglichkeit nicht mit allen Benutzern gleichzeitig getestet werden. Eine kleine Pilotgruppe kann zeigen, ob Postfächer vollständig ankommen, Outlook funktioniert, Berechtigungen stimmen, OneDrive synchronisiert und die neue Dateiablage verständlich ist.

Microsoft empfiehlt bei der Einführung von SharePoint und OneDrive ausdrücklich eine Pilotgruppe, bevor die gesamte Organisation umgestellt wird. Die Rollout-Dokumentation nennt den Pilotbetrieb als empfohlenen Schritt.

Für die Pilotgruppe sollten nicht nur besonders einfache Benutzer gewählt werden. Sinnvoll ist eine Mischung aus typischen Arbeitsplätzen und einigen Sonderfällen, etwa einer Person mit gemeinsamem Postfach, einem mobilen Notebook oder Zugriff auf mehrere gemeinsame Ablagen.

Das Ziel ist nicht, jede denkbare Situation vorwegzunehmen. Es geht darum, den geplanten Ablauf einmal vollständig vom alten System bis zum normalen Arbeitsalltag im neuen System zu testen.

Der Cutover braucht einen klaren Ablauf

Der eigentliche Umschalttag sollte kein offener Arbeitsblock sein, sondern eine feste Reihenfolge haben. Vorher muss klar sein, wer welche Änderung durchführt, wer Ergebnisse prüft und was passiert, wenn ein kritischer Schritt nicht funktioniert.

Ein einfacher Ablauf kann beispielsweise so aussehen:

1. Letzten Synchronisationslauf beziehungsweise letzten Migrationsbatch durchführen.
2. Ergebnisberichte auf Fehler prüfen.
3. Neue Postfächer und Zielablagen stichprobenartig kontrollieren.
4. DNS beziehungsweise Mailrouting auf Microsoft 365 umstellen.
5. Outlook, Webmail und mobile Geräte testen.
6. OneDrive- und SharePoint-Zugriffe prüfen.
7. Fachanwendungen, Scanner und andere technische Absender testen.
8. Benutzer über den neuen Arbeitsweg informieren.
9. Alte Umgebung zunächst kontrolliert verfügbar halten, bis die Prüfung abgeschlossen ist.

Bei E-Mail-Migrationen beschreibt Microsoft ebenfalls einen Ablauf aus vorbereiteter Zielumgebung, eigentlicher Migration, Prüfung und anschließendem Wechsel des Mailroutings. Das lässt sich beispielsweise an der dokumentierten Exchange-Cutover-Migration nachvollziehen.

Die konkrete Methode kann je nach Ausgangssystem anders aussehen. Das Prinzip bleibt aber gleich: Erst Daten und Ziel prüfen, dann den produktiven Verkehr umschalten.

Nach dem Kopieren beginnt die eigentliche Abnahme

Eine erfolgreiche Meldung des Migrationstools bedeutet nur, dass der technische Kopiervorgang abgeschlossen wurde. Danach muss geprüft werden, ob die Umgebung auch fachlich nutzbar ist.

Bei E-Mail gehören dazu beispielsweise aktuelle und ältere Nachrichten, Kalender, Kontakte, gemeinsame Postfächer, Aliase und Mailflow. Bei Dateien sollten mehrere typische Ordner, Berechtigungen, Suchbarkeit und Synchronisation geprüft werden.

Für den Abschluss hilft eine kompakte Abnahmetabelle:

Der letzte Punkt sollte erst dann abgehakt werden, wenn die neue Umgebung tatsächlich geprüft ist. Die alte Quelle unmittelbar nach dem ersten erfolgreichen Kopiervorgang abzuschalten nimmt unnötig Rückfallmöglichkeiten aus dem Projekt.

Backup und Migration sind zwei verschiedene Aufgaben

Eine Migration transportiert Daten von einer Umgebung in eine andere. Sie ersetzt deshalb kein Backup-Konzept. Fehlerhaft gelöschte oder bereits beschädigte Daten können genauso mit migriert werden wie korrekte Daten.

Vor größeren Änderungen sollte daher geklärt sein, welche Sicherungs- und Wiederherstellungsmöglichkeiten für die Ausgangsdaten existieren und wie lange die alte Umgebung als zusätzliche Rückfallebene erhalten bleibt.

Nach der Migration muss anschließend entschieden werden, wie Microsoft 365 selbst gesichert werden soll. Papierkorb- und Aufbewahrungsfunktionen decken nicht automatisch jedes gewünschte Wiederherstellungsszenario ab. Dieses Thema sollte getrennt von der eigentlichen Migration geplant werden.

Eine gute Migration endet nicht am Wochenende des Umzugs

Nach dem Cutover entstehen fast immer kleinere Nacharbeiten: ein altes Outlook-Profil, eine fehlende Freigabe, ein Scanner mit alten SMTP-Daten oder Benutzer, die Dateien weiterhin am bisherigen Ort suchen.

Deshalb sollte bereits vor der Migration ein Nachlauf eingeplant werden. Verantwortlichkeiten für Support, offene Fehler und Berechtigungskorrekturen müssen klar sein. Erst wenn diese Punkte abgearbeitet sind, kann die alte Umgebung geordnet stillgelegt werden.

Für Microsoft-365-Migrationen ist deshalb die Reihenfolge wichtiger als möglichst schnelles Kopieren: Bestand aufnehmen, Zielstruktur festlegen, Benutzer und Berechtigungen vorbereiten, Migration testen, kontrolliert umschalten und anschließend fachlich abnehmen.

Wenn E-Mail, OneDrive, SharePoint und die dazugehörigen Benutzerkonten gemeinsam migriert werden sollen, passt das direkt zu unserer Microsoft 365 Betreuung. Geht es insbesondere um Mailrouting, Domains, DNS und den Wechsel eines bestehenden Maildienstes, sind ergänzend unsere E-Mail-Lösungen relevant.