Microsoft 365-Migrationen | Teil 6: Auswahl des Migrationsverfahrens

20.07.2026 20.07.2026

Krähe mit Hut

Lesedauer 11 Minuten

Im vorherigen Beitrag wurden verschiedene Ansätze aufgezeigt, wie eine Migration grundsätzlich geplant werden kann und welche Faktoren hierfür ausschlaggebend sind. In meinen Projekten begegnet mir jedoch immer wieder eine Detailfrage zum eigentlichen Vorgehen:

Wie müssen wir uns das denn nun eigentlich vorstellen? Schieben wir an einem Wochenende alles rüber oder müssen wir hier schrittweise vorgehen?

Das ist eine gute Frage, nicht nur im Kontext einer Microsoft 365-Migration. Wie auch bei anderen Migrationen gibt es darauf keine pauschale Antwort, die für alle Unternehmen passt. Allerdings gibt es viele Faktoren, die zur Entscheidungsfindung beitragen können. Aus diesem Grund ist diesem Thema ein eigener Teil innerhalb der Serie gewidmet. Dieser konzentriert sich auf die Frage:

BIG BANG ODER GESTUFTE MIGRATION?

Begriffsklärung

Bevor wir darauf eingehen, welches Verfahren wann angewendet werden kann (oder vielleicht auch sollte), klären wir zunächst, was die Begriffe bedeuten. Mit diesem Verständnis lassen sich dann individuelle Anforderungen und Besonderheiten des jeweiligen Verfahrens herausarbeiten.

Big Bang

Der Name deutet es schon ein wenig an - bei dem sogenannten "Big Bang"-Verfahren werden Objekte und Ressourcen zu einem definierten Zeitpunkt (beispielsweise ein Wochenende) gewissermaßen alle auf einmal umgestellt. Eine andere gebräuchliche Bezeichnung ist "Cutover"-Verfahren.

Eine Big Bang-Migration muss im Vorfeld sorgfältig geplant und vorbereitet werden, damit sie idealerweise nicht in einem großen Knall endet. Eine solche Migration erzeugt außerdem zum definierten Zeitpunkt sehr viel Aufwand hinsichtlich Koordination, personellen Ressourcen und technischen Maßnahmen sowie typischerweise hohe Aufwände für Entstörungsmaßnahmen nach der Migration.

Das Big Bang-Verfahren hat den Vorteil, dass Aufwände nur einmalig entstehen und Probleme durch eine parallele Bereitstellung von Alt- und Neusystem vermieden werden.

Gestuft

Bei einem gestuften Verfahren werden Objekte und Ressourcen in abgestimmten und eingegrenzten Paketen nach und nach umgestellt. Altes und neues System sind hierbei für eine gewisse Zeit parallel aktiv. Dieses Verfahren ist auch unter anderen Namen bekannt, beispielsweise Wellenmigration, Phasenmigration oder iterative Migration.

Ein gestuftes Vorgehen entzerrt die Aufwände für die Migration, indem diese über einen längeren Zeitraum gestreckt werden. Es entsteht jedoch auch hier ein erheblicher Koordinationsaufwand, da personelle Ressourcen über einen längeren Zeitraum vorgehalten werden müssen. Das gestufte Vorgehen hat jedoch den Vorteil ggü. dem Big Bang-Verfahren, dass die Migration im Bedarfsfall vorübergehend gestoppt werden kann.

Migrationsverfahren im Kontext von Microsoft 365

Welches ist nun das richtige Verfahren für eine Microsoft 365-Migration? Um es mit den typischen Worten eines IT'lers zu sagen: "es kommt drauf an." 😉

Ausschlaggebende Faktoren

Für eine Betrachtung, welches Migrationsverfahren infrage kommt, sind mehrere Faktoren ausschlaggebend. Je nach persönlicher Einschätzung können diese jedoch sowohl für das eine als auch das andere Verfahren sprechen. Dies soll die folgende Tabelle deutlich machen. Die Tabelle erhebt hierbei keinen Anspruch auf Vollständigkeit, sondern soll Anhaltspunkte liefern. Eventuell sind für Eure Migration noch andere Faktoren ausschlaggebend.

Kriterium/Faktor	Einschätzung: [Big Bang]	Einschätzung: [Gestuft]
Auswirkungen auf Benutzer	Eine Migration hat grundsätzlich erhebliche Auswirkungen auf Benutzer. Beim Big Bang-Verfahren konzentrieren sich die Auswirkungen jedoch auf einen stark begrenzten Zeitraum. Dies vermittelt den Benutzern eher das Gefühl, dass es sich um eine zusammenhängende Umstellung und nicht um viele kleine Änderungen handelt.	Bei einem gestuften Verfahren müssen Benutzer immer wieder unterschiedliche Änderungen zu unterschiedlichen Zeitpunkten durchführen. Dies lässt die Akzeptanz für das Vorhaben als solches sinken, da Benutzer immer wieder in ihrer Arbeitsfähigkeit und/oder ihren alltäglichen Abläufen gestört werden.
Größe der zu integrierenden/auszugliedernden Organisation	Die durchzuführenden Schritte sind bei einer Migration grundsätzlich die gleichen, unabhängig von der Menge der Benutzer. Allerdings ist hierbei die Leistungsfähigkeit der Migrationslösung wichtig (also wieviel Zeit für die finale Datensynchronisation benötigt wird. Aus diesem Kontext heraus gilt eine Menge von maximal 2000 Benutzern für Big Bang als leistbar. Dies setzt jedoch auch voraus, dass genügend personelle Ressourcen für die anschließende Hyper Care-Phase zur Verfügung stehen, insbesondere bei mehreren Standorten. Auch ist eine sorgfältige Planung erforderlich, um alle notwendigen Änderungen und Anpassungen zu berücksichtigen.	Ein gestuftes Verfahren ist unabhängig von der Menge der zu migrierenden Ressourcen wesentlich komplexer in der Durchführung, da die bisherige und die neue Umgebung für diesen Zeitraum parallel betrieben werden müssen. Es ergeben sich außerdem zahlreiche zusätzliche Abhängigkeiten zwischen den Umgebungen (beispielsweise Zugriff auf gemeinsam genutzte Postfächer, Verteilergruppen, Wechsel zwischen Teams-Umgebungen, usw.), die ein hohes Potenzial für Störungen und Fehler mitbringen. Auch müssen Benutzer bei diesem Verfahren immer wieder Änderungen mitmachen und durchführen, was erfahrungsgemäß nicht gut aufgenommen wird.
Koordination von Projektbeteiligten	Je größer das zu betrachtende Unternehmen, desto größer ist üblicherweise die Anzahl der Projektbeteiligten. Dies kann irgendwann dazu führen, dass mehr diskutiert als tatsächlich geplant und umgesetzt wird. Es ist daher empfehlenswert, den für die technische Analyse und Planung zuständigen Personenkreis stark zu begrenzen, da diese Planung essenziell für einen technisch erfolgreichen Verlauf des Migrationsprojekts ist. In einem Big Bang-Verfahren entsteht dann ein einmalig erhöhter Aufwand für die Bereitstellung personeller Ressourcen im Rahmen der Hyper Care-Phase und potenzieller Nacharbeiten.	Bei einem gestuften Verfahren entsteht über einen längeren Zeitraum ein erhöhter Migrationsaufwand, da im Grunde immer wieder neue Migrationen stattfinden. Für die Durchführung, Hyper Care und Nacharbeiten müssen jeweils immer wieder personelle Ressourcen bereitgestellt werden, Es ist jedoch nicht unbedingt sichergestellt, dass immer wieder die gleichen Ressourcen verfügbar sind. Dementsprechend kann es dazu kommen, dass neue Kräfte erst eingelernt werden müssen, um adäquat unterstützen zu können.
Technischer Betrieb	Bei einer Big Bang-Migration lässt sich der Betrieb gut gegeneinander abgrenzen. Die für die bisherige Umgebung verantwortlichen Fachkräfte - gehen entweder in das Betriebsteam der neuen Umgebung über (Integration) oder - wechseln in ein neues Betriebsteam (Ausgliederung) und - der Betrieb der Altumgebung erfolgt weiter über das neue Betriebsteam bzw. verbleibt beim bisherigen Team.	Bei einer gestuften Migration müssen Alt- und Neuumgebung für eine gewisse Zeit parallel betrieben werden. Dies sorgt für erhöhte Aufwände, da sich zwischenzeitlich ergebende Anforderungen in beiden Umgebungen geändert werden müssen. Ggf. müssen auch individuelle Abstimmungen zwischen den unterschiedlichen Betriebsteams erfolgen. Auch können sich individuelle Aufwände stark erhöhen, wenn sich beispielsweise die Infrastrukturen der Unternehmen voneinander unterscheiden.
Organisatorische Strukturen	Organisatorische Strukturen haben einen erheblichen Einfluss darauf, wann und wie Daten übertragen werden können. Unternehmen arbeiten üblicherweise abteilungsübergreifend und nicht in Silos. Bei einer Big Bang-Migration ist diese Frage jedoch nachgelagert, da sämtliche Ressourcen in einem Rutsch übertragen werden. Dementsprechend müssen interne Abhängigkeiten nicht wesentlich berücksichtigt werden.	Bei einer gestuften Migration müssen organisatorische Strukturen sorgfältig betrachtet werden, da diese während der einzelnen Migrationsphasen weiterhin arbeitsfähig bleiben müssen. Es müssen also Pakete aus zusammengehörigen Ressourcen geschnürt werden, um die Arbeitsfähigkeit auch in der neuen Umgebung zu erhalten. Dies ist jedoch nicht für alle Dienste möglich (bspw. Teams). Benutzer müssen also teilweise in beiden Umgebungen arbeiten.
Zu migrierende Dienste	Die Bestimmung der zu migrierenden Dienste kann einen erheblichen Einfluss darauf haben, wie die Migration ablaufen kann. Wenn beispielsweise nur die "Standard"-Dienste Exchange, SharePoint und Teams zu migrieren sind, so lässt sich das mit allen gängigen Migrationslösungen gut und schnell bewerkstelligen. Kommen jedoch weitere Dienste hinzu (vor allem solche, die nicht direkt migriert werden können), so mag ein Big Bang-Ansatz nicht durchgängig anwendbar sein.	Ein gestuftes Verfahren kann hier in unterschiedlichen Varianten erfolgen: A) Dienst für Dienst B) Standard-Dienste / erweiterte Dienste Bei Variante A ist zu beachten, dass es Abhängigkeiten zwischen den Diensten gibt, so dass die zusammengehörend betrachtet werden müssen. Beispielsweise sollten persönliche Teams-Chats nicht ohne Exchange-Postfach migriert werden, da diese das Postfach als Speicherort nutzen. In Variante B werden die Standard-Dienste zusammengehörend betrachtet und erweiterte Dienste wie z.B. Forms, Power BI, usw. separat beleuchtet.
Vorgehen für Gerätemigration	Grundsätzlich ist es empfehlenswert, die Geräte im Rahmen der Migration aufzufrischen - beispielsweise durch Neuinstallation oder durch Austausch. Sofern jedoch nicht genügend Zeit für die entsprechenden Vorbereitungen gegeben ist, kann die Gerätemigration von den restlichen Migrationsmaßnahmen entkoppelt werden. Wichtig ist in diesem Fall, dass bei einer Integration ggf. Sicherheitseinschränkungen des aufnehmenden Mandanten die Einbindung solcher Geräte verhindern können (unverwaltet).	Ein gestuftes Verfahren kann hinsichtlich der Geräte in zwei Varianten erfolgen: A) Geräte werden vor der Migration ausgetauscht/neu installiert B) Geräte werden nach der Migration ausgetauscht/neu installiert Beide Varianten dienen dazu, die Aufwände der eigentlichen Migration zu reduzieren, so dass nur die Hintergrundaufgaben (Datenmigration, Umstellung Apps, etc.) geplant und durchgeführt werden müssen. Die Umstellung der Geräte kann hierbei in angepassten Wellen erfolgen (z.B. bereichsweise, standortweise, usw.).
Leistungsfähigkeit der Migrationslösung	Die gängigen Migrationslösungen verfügen üblicherweise über eine direkte Anbindung an das Microsoft-Backend. Dementsprechend können Daten sehr schnell übertragen werden (Ausnahme: Exchange Online, da hier starke Drosselungen implementiert sind). Dies sollte im Vorfeld validiert werden, um auf dieser Basis die voraussichtliche Migrationsdauer näherungsweise berechnen zu können. Auch das durchschnittliche Datenwachstum pro Woche ist ausschlaggebend, um das notwendige Zeitfenster für die Delta-sowie finale Synchronisation bestimmen zu können. Als Faustregel gilt, dass eine Delta-Migration nicht länger als 12 Stunden dauern sollte. Dies räumt üblicherweise genug Zeit ein, um die Migrationsarbeiten durchzuführen und anschließend die abschließende Synchronisation zu initiieren.	Sollte eine Delta-Synchronisation mehr als 12 Stunden benötigen oder nicht performant laufen (beispielsweise weil Postfächer wesentlich mehr Elemente pro Ordner enthalten als offiziell unterstützt), so scheidet ein einzelnes Migrationswochenende für alle Objekte aller Wahrscheinlichkeit aus. In diesem Fall müssen Migrationswellen geplant werden, die je nach personeller Ressourcenstärke (Helpdesk) und Anzahl der Mitarbeitenden geplant werden müssen. Ziel sollte sein, den parallelen Betrieb von Alt- und Neuumgebung so kurz wie möglich zu halten, da dies erfahrungsgemäß die meisten Störungsanfragen erzeugt.
Verfügbarkeit personeller Ressourcen	Im Rahmen der Migrationsdurchführung werden Beteiligte aller Projektbereiche benötigt, um die jeweiligen Schritte effizient und vollständig durchführen zu können. Für den tatsächlichen Ressourcenbedarf kommt es darauf an, wie sehr sich die Durchführung automatisieren lässt (bspw. durch den Einsatz von Skripten). Vor allem nach der Migration entsteht jedoch typischerweise ein hoher Ressourcenbedarf für die Analyse und Beseitigung von Störungen, besonders dann, wenn viele Systeme auf einmal umgestellt werden. Es werden hierbei sowohl Mitarbeitende für die Infrastruktur als auch Mitarbeitende für den Helpdesk (remote und vor Ort) benötigt, da Störungen schnellstmöglich beseitigt werden müssen. Kann dieser Ressourcenbedarf nicht angemessen bereitgestellt werden, ist ein Big Bang-Ansatz wahrscheinlich nicht möglich oder nur mit erheblichen Beeinträchtigungen der Mitarbeitenden möglich.	Ein gestuftes Verfahren ist dann ratsam, wenn nicht genügend personelle Ressourcen vor allem für die Entstörung zur Verfügung stehen. Dies trifft insbesondere dann zu, wenn die Integration bzw. Ausgliederung insgesamt eng getaktet ist. In einem solchen Fall müssen die zur Verfügung stehenden personellen Ressourcen über einen längeren Zeitraum geblockt werden, damit diese für jede Migrationswelle zur Verfügung stehen. Der Einsatz unterschiedlicher/mehrerer Teams ist nur dann ratsam, wenn dieser stark eingegrenzt bleibt. Ansonsten kann nicht auf bereits vorhandene Erfahrungen zurückgegriffen werden, da jedes Team erneut eigene Erfahrungen und Vorgehensweisen aufbauen und etablieren muss.
Zeitliche Kritikalität	Ein wesentlicher Faktor für die Auswahl des Migrationsverfahrens ist die zur Verfügung stehende Zeitspanne. Eine enge Taktung spricht eher für eine Big Bang-Migration, allerdings mag eine solche aufgrund der anderen Faktoren in dieser Tabelle nicht zielführend sein. Dies mag dann Anlass sein, die geplante Zeitspanne zur Diskussion zu stellen und die Gründe hierfür klar zu benennen. Bei einer Microsoft 365-Migration gilt im Besonderen der Leitspruch "Qualität vor Geschwindigkeit", da es viele Stellschrauben gibt, die die Qualität und damit die Benutzererfahrung erheblich mindern können. Und gerade für die Nutzung von Microsoft 365 sollten negative Benutzererfahrungen nach Möglichkeit auf ein Minimum reduziert werden, da sonst auch die effiziente Zusammenarbeit innerhalb des Unternehmens leiden kann.	Falls ausreichend Zeit für die Planung, Vorbereitung und Durchführung zur Verfügung steht, so kann grundlegend ein gestuftes Verfahren in Betracht gezogen werden. Dies gilt jedoch vorbehaltlich der Frage, ob die anderen Faktoren ebenfalls für ein gestuftes Verfahren sprechen. Aus Erfahrung ist ein Big Bang-Ansatz im Rahmen von Microsoft 365-Migrationen üblicherweise besser, da die Benutzererfahrung dann üblicherweise nur einmal beeinträchtigt wird.

Klar, das ist ganz viel (trockene) Theorie. Zusammenfassend kann ich aus eigener Erfahrung sagen, dass ich ein Big Bang-Verfahren grundsätzlich immer vorziehen würde, solange es irgendwie möglich ist.

Benutzer verwirrt der Wechsel zwischen unterschiedlichen Umgebungen typischerweise sehr (Welches Konto muss ich für was nehmen? Warum bekomme ich diese Nachricht nicht / warum ist meine Nachricht nicht beim Gegenüber angekommen (stattdessen beim Gastbenutzer)?) und die Verwirrung nimmt zu, je länger die Übergangsphase dauert. Daher bin ich ein Freund davon, alles so schnell wie möglich zu übertragen und das entsprechend sorgfältig vorzubereiten!

Beispielszenarien

Um dies einmal anschaulich zu machen, zeige ich in der Folge einige Beispielprojekte und warum wir uns hier für das jeweilige Migrationsverfahren entschieden haben.

Szenario 1: Nur Exchange

Eckparameter	Details
Kurzbeschreibung	Ausschließliche Migration von Postfächern zwischen Exchange Online-Umgebungen
Kundenumgebung	Hauptumgebung: hybrid mit lokalem Active Directory und Exchange Server (nur Verwaltung) Zu integrierende Umgebung: Standort in anderem Land, reine Cloudbereitstellung; ca. 50 Benutzer
Zeitlicher Rahmen	3 Monate
Genutzte Migrationslösung	CodeTwo Office 365 Migration
Migrationsverfahren	Big Bang

Das Big Bang-Verfahren war in diesem Fall naheliegend, da es sich um eine geringe Menge an Mitarbeitenden handelte und ausschließlich Postfächer migriert werden sollten. Dementsprechend waren die vorbereitenden Maßnahmen wie Bereitstellung von Benutzerkonten und Postfächern sowie Erfassung der genutzten E-Mail-Adressen schnell durchgeführt.

Für die Durchführung wurde der Morgen eines Wochentags bestimmt, da nur eine finale Synchronisation und der Umzug der benutzerdefinierten Domäne durchgeführt werden mussten. Die Geräte verblieben in ihrem Zustand und die neuen Konten wurden lediglich neu in den Apps eingebunden. Die Geräte wurden dann zu einem späteren Zeitpunkt auf Basis ihres Lebenszyklus gegen standardisierte Geräte der aufnehmenden Gesellschaft ausgetauscht.

Szenario 2: Eingliederung von Unternehmen in der Muttergesellschaft

Eckparameter	Details
Kurzbeschreibung	Integration aller Unternehmen aller Unternehmensgruppe in die zentrale Muttergesellschaft
Kundenumgebung	Hauptumgebung: reine Cloudbereitstellung mit vereinzelten Infrastruktur-Komponenten in Azure Zu integrierende Umgebungen: unterschiedlich, d.h. hybrid mit Active Directory, reine Cloudbereitstellungen, teilweise Azure-Infrastruktur und/oder lokale Infrastruktur; unterschiedliche Benutzerzahlen (15-500)
Zeitlicher Rahmen	6 Monate mit Stichtag zum Jahreswechsel (d.h. unveränderbares Enddatum)
Genutzte Migrationslösung	AvePoint Fly
Migrationsverfahren	Big Bang

Zunächst sei gesagt: NICHT NACHMACHEN! 😉 Organisatorisch war festgelegt, dass alle Unternehmen zum Jahreswechsel integriert sein müssen, um ab diesem Zeitpunkt ausschließlich unter dem Namen der Muttergesellschaft zu operieren. Dementsprechend war das vorgesehene Enddatum nicht anpassbar. Zusätzlich war die Vorgabe, dass doppelte Lizenzkosten nach Möglichkeit unbedingt vermieden werden müssen.

Das Projekt wurde ca. Mitte des Jahres begonnen, dementsprechend standen um die 6 Monate für Analyse, Planung und Durchführung zur Verfügung. Aufgrund der zeitlichen und Kostenvorgaben war der Big Bang-Ansatz die einzige Möglichkeit, beidem gerecht zu werden. Dementsprechend haben wir uns in diesem Projekt ausschließlich auf die Erfüllung dieses Ziels konzentriert, gleichzeitig aber versucht, die Benutzererfahrung so wenig wie möglich zu beeinträchtigen.

Dementsprechend wurden die Endgeräte weitestgehend in ihrem IST-Zustand belassen und nur dann in die zentrale Intune-Infrastruktur aufgenommen, wenn dies ohne Geräterücksetzung oder Auswirkungen auf das Benutzerprofil möglich war. Im Rahmen der Betrachtung der Microsoft 365-Dienste wurden einzelne Bereiche identifiziert, in denen eine Migration zu aufwändig oder komplex geworden wäre, beispielsweise Plattformen in SharePoint Online für die Zusammenarbeit mit Kunden.

Dementsprechend wurden solche Strukturen vereinzelt in der Altumgebung belassen und ein Zugriff mittels Gastbenutzern aus der neuen Umgebung kosteneffizient realisiert.

Szenario 3: Ausgliederung von Unternehmensstandorten in eigenen Mandanten

Eckparameter	Details
Kurzbeschreibung	Ausgliederung von mehreren Unternehmensstandorten in eigenen Mandanten
Kundenumgebung	Hauptumgebung: Hybridbereitstellung mit lokalem Active Directory Auszugliedernde Umgebung: Hybridbereitstellung mit lokalem Active Directory und Exchange Server (Postfachbereitstellung); ca. 1.500 Benutzer
Zeitlicher Rahmen	ca. 1 Jahr mit Stichtag aufgrund besonderer Lizenzierungsvorgaben (d.h. unveränderbares Enddatum)
Genutzte Migrationslösung	Quest On Demand Migration + Hybrid Exchange
Migrationsverfahren	Big Bang

In diesem Szenario sollten regionale Teile des Unternehmens in einen eigenen Mandanten ausgelagert werden. Jedoch wurden die Unternehmen nicht organisatorisch, sondern lediglich technisch getrennt. Dementsprechend war eine weitere Zusammenarbeit zwischen den Unternehmen gewünscht bzw. erforderlich. Dies bedeutete eine gewisse Komplexität bei der Planung, da sorgfältig geprüft werden musste, welche Unternehmens-Apps, Teams-Räume, SharePoint-Seiten, usw. wie genutzt werden, um folgende Änderungen zu planen:

Nur Mitarbeitende der abgebenden Infrastruktur: Mitarbeitenden der auszugliedernden Bereiche entfernen
Nur Mitarbeitende der auszugliedernden Infrastruktur: Daten und Anbindung in neuen Mandanten umziehen und in Altumgebung löschen
Mitarbeitende aus beiden Infrastrukturen: Besitzanteile bestimmen und entweder migrieren und in Altumgebung belassen und Zugriffsrechte neu einrichten

Hierfür wurde eine Entra B2B-Beziehung mit entsprechenden Vertrauenseinstellungen sowie eine mandantenübergreifende Synchronisation aufgebaut, um Querzugriffe zu ermöglichen.

Eine zusätzliche Komplexität ergab sich aus der miteinander verzahnten lokalen Infrastruktur:

Beide Unternehmensbereiche verfügten über ein jeweils eigenes Active Directory
Objekte wurden aus beiden AD über eine zentrale und extern verwaltete Entra Connect Sync-Instanz in die bestehende Umgebung synchronisiert
Die Exchange-Organisation der auszugliedernden Regionen war in einer Hybridbereitstellung mit der abgebenden Umgebung verbunden
Ein Zugriff auf die lokalen Exchange-Postfächer war über die hybride moderne Authentifizierung realisiert.

Ein gestuftes Verfahren hätte hier bedeutet, dass die Benutzer, die über ein mobiles Gerät auf ihr Postfach zugreifen, für die Übergangszeit den Zugriff verloren hätten. Dies wurde als nicht zumutbar deklariert. Folglich blieb nur das Big Bang-Verfahren, welches für ein verlängertes Wochenende geplant wurde, um genug Zeit für alle Umstellungsarbeiten einzuräumen.

Szenario 4: Eingliederung von großer Unternehmenstochter

Eckparameter	Details
Kurzbeschreibung	Eingliederung einer sehr großen Unternehmenstochter
Kundenumgebung	Hauptumgebung: Hybridbereitstellung mit lokalem Active Directory Einzugliedernde Umgebung: Hybridbereitstellung mit lokalem Active Directory und Exchange Server (Postfachbereitstellung); > 10.000 Benutzer
Zeitlicher Rahmen	ca. 1,5 Jahre, Enddatum theoretisch variabel
Genutzte Migrationslösung	Microsoft Migration Orchestrator (Exchange, Teams 1:1-Chats, ShareGate (nur SharePoint/Teams-Räume), Exchange-Hybridbereitstellung (Postfächer)
Migrationsverfahren	Gestuft

In diesem Szenario (ist aktuell in Planung) soll eine sehr große Tochter (weit über 10.000 Benutzerkonten) in die zentrale Umgebung der Muttergesellschaft integriert werden. Aufgrund der schieren Masse an Benutzern (und dementsprechend vielen Unternehmensstandorten) erscheint ein Big Bang-Verfahren jedoch unrealistisch:

Es können in keinem Fall ausreichend personelle Ressourcen für die an die Migration anschließende Hyper Care-Phase bereitgestellt werden.
Kein Hardwarehersteller kann diese Menge an Geräten innerhalb des noch zur Verfügung stehenden Zeitraums liefern. Die Geräte müssten alle lange im Voraus bestellt und eingelagert werden, was im Sinne des Hardwarelebenszyklus als nicht zumutbar eingestuft wird. Außerdem stehen nicht genügend Ressourcen für die initiale Bereitstellung aller Geräte zur Verfügung. Die Geräte werden daher erst nach der Migration betrachtet.
Aufgrund der Vielzahl der zu migrierenden/umzustellenden Ressourcen (bspw. Verteilergruppen, Unternehmens-Apps, usw.) müsste eine Vielzahl an zuständigen Personen während und nach der Migration koordiniert werden, um die Durchführung der jeweils notwendigen Maßnahmen sicherzustellen. Dies wird als unrealistisch eingestuft.

Eine zusätzliche Komplexität ergibt sich daraus, dass sich das Unternehmen dazu entschieden hat, den Microsoft Migration Orchestrator für die Migration der Benutzerdaten einzusetzen. Microsoft verspricht hier unter anderem, dass

Teams 1:1-Chats direkt (d.h. ohne Umwandlung in einen Gruppen-Chat) migriert werden können,
alte Zugriffslinks zu OneDrive- und SharePoint-Freigaben auch nach der Migration weiterhin (mittels einer automatisch eingerichteten Umleitung) funktionieren und
die Migrationsgeschwindigkeit durch die direkte Anbindung erheblich schneller als bei den gängigen Migrationslösungen sein soll.

Für die Migration von SharePoint Online sowie Teams-Räumen kommt ShareGate zum Einsatz, da der Migration Orchestrator deren Migration (noch) nicht beherrscht.

Aufgrund all dieser Faktoren wird ein gestuftes Verfahren zum Einsatz kommen. Über einen Zeitraum von derzeit geplant 3 Monaten werden in mehreren Chargen jeweils 2000 Benutzerkonten inklusive ihrer Daten migriert. Ein Zugriff auf noch nicht migrierte Daten wird über Entra B2B realisiert. Dies macht eine äußerst sorgfältige Benutzerkommunikation erforderlich, um jede Änderung und ihre jeweiligen Auswirkungen auf die Benutzererfahrung im Detail zu erklären.

Sobald diese Migration abgeschlossen ist, werde ich dieses Szenario entsprechend mit den gesammelten Erfahrungen überarbeiten.

Hat Dir dieser Artikel gefallen? Lass es andere wissen!