Microsoft 365 Migrationsdienste, die funktionieren
· von IDE Solutions
Die meisten Microsoft-365-Migrationen scheitern in der Planungsphase. Nicht technisch – die Daten bewegen sich in der Regel. Aber das Unternehmen erfährt zu spät, dass freigegebene Postfächer nicht korrekt zugeordnet wurden, dass Berechtigungen bei der SharePoint-Migration verloren gingen oder dass in Teams-Kanälen die Dateien fehlen, die vorher darin lagen. Das sind keine Ausnahmefälle. Es ist das übliche Ergebnis von Migrationen, die die Datenbewegung als Ziel behandelt haben und nicht die Kontinuität des Geschäftsbetriebs.
Eine Migration, die funktioniert, ist eine, bei der Anwender auf der anderen Seite ankommen und ihre Arbeit ohne zweitägige Eingewöhnung erledigen können. Das erfordert mehr Vorbereitung, als die meisten Unternehmen erwarten, einen klaren Rollback-Plan und jemanden, der dies oft genug gemacht hat, um zu wissen, wo die Probleme lauern.
Ist eine Office-365-Migration dasselbe wie eine Microsoft-365-Migration?
Ja. Microsoft hat die Office-365-Abonnements für Unternehmen im Jahr 2020 in Microsoft 365 umbenannt. Der Dienst ist derselbe, und die Migrationsarbeit ebenfalls. Wenn Sie nach Office-365-Migrationsdiensten suchen und Ergebnisse zu Microsoft 365 finden, sind Sie richtig – geändert hat sich nur der Name.
Entscheidend ist nicht, wie das Ziel heißt, sondern wovon Sie migrieren. Der Umzug von einem lokalen Exchange-Server ist ein anderes Projekt als der Wechsel zwischen zwei Microsoft-365-Tenants, und beides unterscheidet sich vom Umstieg von Google Workspace oder einem gehosteten IMAP-Anbieter. Das Ziel lässt sich leicht beschreiben. Das Risiko bestimmt die Quelle.
Was eine Microsoft 365-Migration tatsächlich umfasst
Die meisten Unternehmen verstehen unter einer Microsoft-365-Migration das Verschieben von E-Mails. Tatsächlich umfasst eine vollständige Migration typischerweise Exchange-Online-Postfächer, freigegebene Postfächer, Verteilerlisten, Kalenderdaten, OneDrive-for-Business-Dateispeicher, SharePoint-Websitesammlungen und -Berechtigungen, Teams-Kanäle samt zugehöriger Dateien sowie sämtliche Drittanbieter-Integrationen, die mit der alten Umgebung verbunden sind.
Jede Workload hat ihren eigenen Migrationsansatz, ihre eigenen zeitlichen Randbedingungen und ihre eigenen Fehlerbilder. E-Mail-Migrationen können wochenlang in einem Hybridzustand laufen, während die Anwender wechseln. SharePoint-Migrationen erfordern oft erhebliche Bereinigung vor dem Umzug, weil Berechtigungsstrukturen aus der lokalen Umgebung sich nicht sauber auf SharePoint Online übertragen lassen. Teams-Migrationen erfordern sorgfältiges Vorgehen, weil die Daten gleichzeitig in SharePoint und Exchange liegen.
Die Bereinigung vor der Migration zu überspringen bedeutet, die technischen Altlasten in die neue Umgebung mitzunehmen. Das ist der häufigste Grund, weshalb scheinbar erfolgreiche Migrationen Wochen später Probleme verursachen.
Hinzu kommt eine Kategorie von Dingen, die keine Daten sind und leicht vergessen werden: Mailflussregeln, Konnektoren zu Branchenanwendungen, der Scanner in der Ecke, der PDFs per SMTP verschickt, das CRM, das sich am alten Verzeichnis authentifiziert, und jede automatische Benachrichtigung, die still und leise aus einer Adresse versendet, an deren Einrichtung sich niemand erinnert. Diese Dinge migrieren sich nicht von selbst – man bemerkt sie meist erst durch ihr Fehlen.
Welche Migrationsmethode zu Ihrer Situation passt
Es gibt keinen einzig richtigen Ansatz. Die Methode hängt davon ab, wie viele Postfächer Sie haben, wie viel Ausfallzeit das Unternehmen verkraften kann und ob Quelle und Ziel nebeneinander bestehen müssen, während weitergearbeitet wird.
| Ansatz | Geeignet für | Beeinträchtigung | Hauptrisiko |
|---|---|---|---|
| Einmaliger Cutover | Kleinere Organisationen mit einem Mailsystem und einem freien Wochenende | Ein definiertes Wartungsfenster | Kein schrittweiser Rückweg nach der Umstellung |
| Gestaffelt / in Wellen | Mittelgroße Organisationen, die abteilungsweise umziehen können | Gering pro Anwender, verteilt über Wochen | Längere Phase geteilter Kalender und Adressauflösung |
| Hybride Koexistenz | Organisationen, die während des Übergangs lokales Exchange behalten | Minimal, aber das längste Gesamtprojekt | Größte Konfigurationsfläche; auf Dauer teuer im Betrieb |
| Tenant zu Tenant | Fusionen, Übernahmen, Abspaltungen | Hängt vollständig vom Koexistenzkonzept ab | Zwei aktive Umgebungen, Identitäts- und Adresskonflikte |
Ehrlich zusammengefasst: Hybrid erkauft Sicherheit mit Komplexität. Ein Cutover erkauft Einfachheit mit einem einzigen Abend, an dem viel auf dem Spiel steht. Den meisten kleinen Unternehmen ist mit einem gut geprobten Cutover besser gedient als mit einer Hybridkonfiguration, die anschließend niemand im Team pflegen kann.
Häufige Migrationsszenarien und was sie erfordern
Die Einrichtung eines neuen Tenants ist das einfachste Szenario: ein Unternehmen, das von einem veralteten E-Mail-System oder aus einer unstrukturierten Cloud-Umgebung kommt. Die Hauptschwierigkeit ist die Datenqualität – alte E-Mail-Archive, uneinheitliche Ordnerstrukturen und freigegebene Laufwerke, die nie gepflegt wurden. Eine gute Migration nutzt dies als Gelegenheit zum Aufräumen, statt das Chaos zu replizieren.
Tenant-zu-Tenant-Migrationen entstehen bei Übernahmen, Fusionen und Umstrukturierungen. Sie sind deutlich komplexer, weil beide Umgebungen aktiv sind, Anwender auf beiden Seiten während des Übergangs kommunizieren müssen und Koexistenzphasen Konfigurationsprobleme mit sich bringen, die es bei einem sauberen Cutover nicht gibt. Microsoft 365 Managed Services mit Migrationsunterstützung sind darauf ausgelegt, während solcher Übergänge die Kontinuität zu wahren.
Die eigentliche Schwierigkeit eines Tenant-zu-Tenant-Umzugs ist die Identität, nicht die Daten. Zwei gleichnamige Personen brauchen nun unterschiedliche Adressen. Zwei Gruppen namens „Finanzen“ müssen nebeneinander existieren. Frei/Gebucht-Kalenderabfragen müssen während der Überlappung über beide Tenants hinweg funktionieren – sonst produziert die erste Woche eine Welle doppelt gebuchter Termine und untergräbt das Vertrauen in das gesamte Projekt.
Domänenwechsel fügen eine weitere Ebene an Komplexität hinzu. Wenn das Unternehmen umfirmiert oder eine Tochtergesellschaft aufnimmt, ändern sich E-Mail-Adressen, was jede Integration, jeden externen Kontakt und jede automatische Benachrichtigung betrifft. Das muss vor der Umstellung erfasst und getestet werden, nicht danach entdeckt. Ein Domänenwechsel berührt außerdem DNS-Einträge, die Zustellung und Spoofing-Schutz steuern; Fehler dort entscheiden zwischen einem ruhigen Wochenende und einem Montag, an dem ausgehende Mails bei Ihren Kunden im Spam landen.
Migrationen weg von Google Workspace verdienen eine eigene Erwähnung. Die Daten wechseln ohne große Dramatik; die Gewohnheiten nicht. Geteilte Ablagen lassen sich nicht sauber auf SharePoint-Bibliotheken abbilden, Google-Gruppen verhalten sich anders als Microsoft-365-Gruppen, und Anwender, die in Google Docs zu Hause waren, empfinden die gemeinsame Bearbeitung in den Office-Desktop-Apps zunächst als fremd. Planen Sie das Änderungsmanagement ein, nicht nur den Kopiervorgang.
Die Checkliste vor der Migration
In der Vorbereitungsphase entscheidet sich, ob eine Migration gelingt. Bevor Daten bewegt werden, sollten diese Punkte abgeschlossen und schriftlich festgehalten sein:
- Eine vollständige Inventur: jedes Benutzerpostfach, freigegebene Postfach, Ressourcenpostfach, jede Verteilergruppe und SharePoint-Website – mit einem namentlich benannten Verantwortlichen.
- Eine Berechtigungsprüfung: wer aktuell worauf Zugriff hat und welche dieser Berechtigungen beabsichtigt sind. Eine Migration ist die einzige realistische Gelegenheit, jahrelang angesammelte Zugriffe zu entfernen, die sonst niemand entzieht.
- Eine Integrationsübersicht: jede Anwendung, jeder Scanner und jedes Skript, das sich an der aktuellen Umgebung authentifiziert oder darüber Mails versendet.
- Ein DNS-Plan: aktuelle MX-, SPF-, DKIM- und DMARC-Einträge, ihr künftiger Stand und vorab abgesenkte TTL-Werte, damit die Umstellung nicht auf die Propagierung wartet.
- Eine Lizenzprüfung: der Ziel-Tenant braucht die richtigen Lizenzen, bevor die Postfächer ankommen, nicht danach.
- Ein Rollback-Plan: schriftlich, mit einer benannten entscheidungsbefugten Person und einem konkreten Point of no Return.
- Ein Kommunikationsplan: Anwender wissen, was sich wann ändert und was zu tun ist, wenn etwas seltsam aussieht.
Enthält das Ihnen vorliegende Migrationsangebot diese Punkte nicht, handelt es sich um eine Datenkopie und nicht um eine Migration – und sollte entsprechend bepreist werden.
Sicherheit während einer Migration
Migrationen erzeugen Sicherheitsrisiken, wenn sie nicht sorgfältig durchgeführt werden. Konten mit erhöhten Rechten werden für Migrationswerkzeuge angelegt und danach nicht entfernt. Daten liegen vorübergehend in beiden Umgebungen, was das Zeitfenster für Angriffe vergrößert. Einstellungen zur externen Freigabe, die in der Quellumgebung streng kontrolliert waren, werden im Ziel möglicherweise nicht korrekt nachgebildet.
Eine sichere Migration umfasst Berechtigungsprüfungen vor und nach dem Umzug, das sofortige Entfernen migrationsspezifischer Konten nach Abschluss, die Überprüfung der Richtlinien für externe Freigaben im Ziel-Tenant und die Durchsetzung von MFA ab dem ersten Tag in der neuen Umgebung. Unsere Arbeit im Bereich Cloud-Sicherheit läuft aus genau diesem Grund häufig parallel zu Migrationen.
Die Durchsetzung von Multi-Faktor-Authentifizierung ab dem ersten Tag ist wichtiger, als es klingt. Eine Migration ist genau der Moment, in dem Anwender ungewohnte Anmeldeaufforderungen erwarten und sie am wenigsten hinterfragen. Es ist zugleich der Moment, in dem eine Reihe frisch angelegter Konten – manche mit erhöhten Rechten – in einem Tenant existiert, dessen grundlegende Sicherheitsrichtlinien noch nicht angewendet wurden.
Dasselbe gilt für Backup und Wiederherstellung. Während des Migrationsfensters muss Ihre Sicherung beide Umgebungen abdecken. Nach der Migration sind die Backup-Richtlinien im neuen Tenant zu überprüfen, bevor die alte Umgebung außer Betrieb genommen wird. Microsoft repliziert Ihre Daten; es verwahrt nicht stellvertretend eine Kopie dessen, was Sie letzten Monat gelöscht haben – und eine Migration ist eine Phase ungewöhnlich häufiger versehentlicher Löschungen.
Für regulierte Unternehmen ist die Konfiguration von Aufbewahrung und Auditierung im Ziel-Tenant keine Aufgabe für die Zeit nach der Migration. Daten, die eintreffen, bevor Aufbewahrungsrichtlinien greifen, waren kurzzeitig außerhalb Ihrer Compliance-Position. Unsere Arbeit zu Governance und Compliance behandelt die Tenant-Konfiguration daher als Voraussetzung des Umzugs und nicht als Nacharbeit.
Wie eine gut durchgeführte Migration aussieht
Die Vorbereitungsphase dauert länger, als die meisten Unternehmen erwarten, und hier entsteht der größte Teil des Wertes. Dazu gehört die Inventarisierung aller Postfächer, freigegebenen Postfächer, Verteilergruppen und SharePoint-Websites; die Prüfung der Berechtigungen und die Identifikation dessen, was bereinigt oder umstrukturiert werden muss; die Erfassung aller betroffenen Drittanbieter-Integrationen; und die Abstimmung des Umstellungszeitplans mit dem Unternehmen, nicht nur mit der IT.
Die Durchführungsphase verläuft typischerweise schnell – für die meisten Workloads eine Umstellung am Wochenende, wobei E-Mail für einen definierten Zeitraum hybrid weiterläuft. Die Phase nach der Migration umfasst die Überprüfung der Berechtigungen, Anwenderunterstützung in den ersten Tagen und die Außerbetriebnahme der Quellumgebung erst dann, wenn im Ziel alles bestätigt funktioniert.
Eine brauchbare Faustregel für den Zuschnitt des Projekts: Die Vorbereitung verbraucht den größten Teil des Kalenders, die Durchführung den größten Teil der Aufmerksamkeit – und die zwei Wochen danach den größten Teil des Wohlwollens, wenn niemand sie eingeplant hat. Die Quellumgebung sollte lesend verfügbar bleiben, bis der erste Monatsabschluss ohne sie gelungen ist, und danach bewusst abgeschaltet und nicht einfach vergessen werden.
Die laufende Tenant-Administration nach dem Umzug ist eine eigene Disziplin, getrennt von der Migration selbst, und dort entscheidet sich, ob der Wert der neuen Umgebung realisiert oder still verspielt wird. Fehlt Ihrem Team dafür die Kapazität, decken Managed-Cloud-Dienstleistungen den Betrieb ab, sobald das Projektteam abgezogen ist.
Wenn Sie eine Microsoft-365-Migration planen und eine realistische Einschätzung dessen wünschen, was dabei zu tun ist und wo die Risiken liegen, dann ist das ein Gespräch, das vor dem Projektstart geführt werden sollte – und nicht, nachdem das erste Problem aufgetreten ist.