Microsoft 365-Migrationen | Teil 3: Projektorganisation

Es ist beschlossen - das zugekaufte Unternehmen soll integriert oder ein Teil des Unternehmens in eine eigene Umgebung überführt werden.

Diese Entscheidung wird normalerweise nicht durch die IT, sondern durch die Geschäftsführung getroffen. Dementsprechend ist zum Zeitpunkt der Entscheidung üblicherweise nicht bekannt, welchen Aufwand die Migration verursachen wird. Und keine Migration ist wie die andere. Es werden zwar grundsätzlich die gleichen Dienste betrachtet und migriert, es können und werden sich jedoch ganz individuelle Herausforderungen ergeben.

Wie ist also vorzugehen, wenn der Auftrag zur Migration kommt? Und welche Hilfsmittel aus Microsoft 365 können einem hierbei das Leben erleichtern? Das zeigt dieser Artikel!

Projektplanung

Eine Microsoft 365-Migration ist keine Veränderung, die man "im Vorbeigehen" erledigt. Es handelt sich um die zentrale Plattform für Zusammenarbeit und Kommunikation, von denen viele Unternehmensprozesse abhängen - und damit auch der Geschäftsbetrieb. Dementsprechend wird klar, dass es eine ordentliche Organisation benötigt, um alle wesentlichen Aspekte der Veränderung abzudecken.

Für solche Zwecke gibt es etablierte Projektstruktur-Ansätze. Welcher gewählt wird, ist von den Unternehmensvorlieben und ggf. auch von dem/den Mitarbeitenden abhängig, welche(r) die Projektsteuerung übernehmen. Ein Projekt schafft den notwendigen Rahmen, um die notwendigen Vorbereitungen und Planungen vorzunehmen und das Projekt letztendlich durchzuführen.

Die folgenden Ansätze sind daher nicht exklusiv für eine Microsoft 365-Migration, sondern können grundsätzlich für jedes Projekt Anwendung finden. Sie werden trotzdem zur Vollständigkeit aufgeführt, da es auch immer wieder Unternehmen gibt, die solche Projekte ohne saubere Planung durchführen oder meinen, dass ein Projektmanager hierfür nicht erforderlich sei.

Projektsteuerung

Viele Unternehmen machen den Fehler, so ein Projekt an die IT zu beauftragen. Die IT ist zwar die ausführende Kraft, hat jedoch typischerweise keine personellen Ressourcen und/oder keine Kenntnisse in Projektplanung und -steuerung (es gibt natürlich Ausnahmen). Besser ist es, die Beauftragung an entsprechend geschulte Projektmanager zu erteilen, die dann ihrerseits die notwendigen Ressourcen aus allen Fachbereichen (sowohl IT als auch Unternehmen) einplanen.

In kleineren Projekten (z.B. <100 Benutzer) mag diese Rolle auch einem Architekten zufallen können, wenn dieser über die notwendigen Projektsteuerungsfähigkeiten verfügt. Dieser sollte dann jedoch nicht mehr operativ in das Projekt eingebunden sein, sondern lediglich eine steuernde Rolle übernehmen.

Projektumfang

Am Anfang eines jeden Projekts stellen sich die typischen W-Fragen (die Liste ließe sich noch fortführen):

• Warum soll migriert werden?
• Was soll migriert werden?
• Wer ist für welche Tätigkeiten einzuplanen/zuständig?
• Wieviel Zeit wird das Projekt in Anspruch nehmen?
• Wieviel Budget wird das Projekt benötigen?
• Wann muss die Migration abgeschlossen sein?

Die Antworten auf diese Fragen sind entscheidend, um das Projekt sauber planen zu können. Die folgenden Kapitel zeigen einmal auf, warum gerade die genannten Fragen so wichtig sind.

Warum soll migriert werden?

Bei Microsoft 365-Zusammenführungen wird üblicherweise eine Verbesserung der internen Zusammenarbeit verfolgt. Trennungen hingegen mögen andere Dinge vereinfachen können, beispielsweise Entscheidungswege und Strukturen.

Dies ist entscheidend für die Projektkommunikation, da positive Aspekte wichtig für die Akzeptanz der Benutzer sind. Diese sind von so einer Migration am stärksten betroffen und sollten dem Projekt gegenüber daher grundsätzlich positiv eingestellt sein. Dies sollte daher das Ziel jeglicher Kommunikation sein! Diesem Thema ist daher ein eigener Teil gewidmet.

Was soll migriert werden?

Der Projektumfang ist entscheidend dafür, welche personellen Ressourcen benötigt werden und wie der Zeitplan für sämtliche Tätigkeiten aussehen kann. Auch ist es wichtig, eine Abgrenzung zu schaffen, damit nicht immer wieder neue Themen in das Projekt eingefügt werden und so eine verlässliche Planung letztlich unmöglich wird.

Des Weiteren muss anhand des Projektumfangs geprüft werden, welche Lösungen für die Durchführung benötigt werden und wo es ggf. Zuarbeit von Drittherstellern oder weiteren Dienstleistern braucht (bspw. für die Umstellung von Applikationen und Systemen).

Im Rahmen einer Microsoft 365-Migration ergeben sich u.a. wieder einige W-Fragen hinsichtlich des Projektumfangs:

• Welche Dienste sollen migriert werden (z.B. Exchange Online, SharePoint Online, OneDrive, ...)?
• Welche Dienste können nicht migriert werden bzw. erfordern manuelle Nacharbeiten (z.B. Power BI, Forms, Intune, ...)?
• Was passiert mit lokaler Infrastruktur?
• Welche Applikationen müssen in welcher Form umgestellt werden?
• Werden Endgeräte migriert oder erhalten die Mitarbeitenden in diesem Zuge neue standardisierte Geräte?
• Welche Umstellungen/Einschränkungen können den Mitarbeitenden zugemutet werden?

Ein Ergebnis dessen kann sein, dass Unter-/Teilprojekte für einzelne Bereiche gebildet werden, falls die Komplexität als zu hoch für ein gesamtheitliches Projekt eingestuft wird.

Wer ist für welche Tätigkeiten einzuplanen/zuständig?

In einem komplexen Projekt wie einer Microsoft 365-Migration kann es nicht "die eine" Person geben, die sich technisch um alles kümmert. Sobald der Umfang des Projekts feststeht, ist daher als nächstes ein Projektteam zusammenzustellen. Innerhalb des Teams sollte es mindestens die folgenden Rollen geben:

Darüber hinaus müssen je nach Komplexität weitere Unternehmensbereiche zumindest teilweise eingeplant werden, um nicht-technische Tätigkeiten vorzubereiten und durchzuführen:

Projektstruktur

Aus den zuvor beschriebenen Rollen kann sich bspw. folgende Projektstruktur ergeben:

• Organisatorisch wird das Projekt (oder auch die Projekte) von einem Gesamt-Projektleiter gesteuert.
• Technisch wird das Projekt (oder auch die Projekte) von einem leitenden Architekten gesteuert.
• Projektleiter und leitender Architekt stimmen sich eng über den Projektfortgang ab.
• Für die einzelnen Fachbereiche werden Fachexperten eingesetzt, die sich eng mit dem leitenden Architekten abstimmen.
• Für die einzelnen Fachbereiche werden je nach Bedarf zusätzliche Mitarbeitende eingeplant, die individuelle Aufgaben durchführen (bspw. Analyse, Konzepterstellung, funktionale Tests, usw.)

In komplexeren Umgebungen kann es noch weitere Themengebiete geben, die separat betrachtet werden sollten. Dieses Schaubild ist daher als Anregung für die Ausgestaltung des eigenen Projekts zu verstehen.

Plattform für die Zusammenarbeit

Jedes Projekt benötigt neben der Organisation auch zentrale Strukturen für die Zusammenarbeit. Was liegt näher, als hierfür Microsoft Teams zu verwenden? 😉 Natürlich gibt auch andere geeignete Plattformen. Diese sollten jedoch mindestens über folgende Funktionen verfügen:

• Virtuelle Besprechungen
• Automatische Transkription für Besprechungen - gerade bei M365-Migrationen kommt es auf viele kleine Details an, die bei manueller Transkription oft verloren gehen
• Zentrale Dateiablage - die Ordnerstruktur ist vom Projektleiter fest vorzugeben und sollte über alle Bereiche/Teilprojekte gleich sein
• Gemeinsames Bearbeiten von Dateien
• Möglichkeit zur Einbindung weiterer hilfreicher Werkzeuge, bspw. Mindmaps, Schaubilder (Visio/Draw.io, Miro), Aufgabenplanung (Planner/Asana), usw.

Wichtige Rahmenparameter einer Zusammenarbeitsplattform sind überdies die folgenden:

Schon gewusst? Microsoft Planner verfügt zwar über eine Möglichkeit zum Exportieren, jedoch nicht zum Importieren. Dadurch können bereits ausgereifte Planner-Boards nicht einfach in andere Mandanten übertragen werden. Es gibt jedoch Addins von Drittherstellern sowie Möglichkeiten über Power Automate, um Aufgaben aus einer Excel-Liste zu importieren.

Terminplanung

Üblicherweise erstellt der Projektleiter als erstes einen Projektplan. Im ersten Entwurf kann dieser bestenfalls grob ausfallen, da noch nicht alle Schritte im Detail bekannt sind. Der Projektplan wird üblicherweise mit Fortgang des Projekts immer weiter verfeinert, da die durchzuführenden Maßnahmen bekannt werden und entsprechende Aufwände geplant werden können.

Die typischen Termine können jedoch bereits festgelegt werden, bspw.

• Vorgegebene Laufzeit des Projekts
• Start des Projekts (sog. "Kick-Off")
• Regeltermine (Jour Fixes)
• Grobe Meilensteinplanung (welche Projektphase soll/muss bis wann erledigt sein)

Hierfür hat es sich bewährt, eine sogenannte rückwirkende Projektplanung vorzunehmen. Diese orientiert sich am spätestmöglichen Zeitpunkt für die Umstellung und rechnet dann zurück, welcher Vorlauf für die einzelnen Phasen und Schritte mindestens eingeräumt werden muss. Dies setzt jedoch voraus, dass die Projektbeteiligten schon über etwas Erfahrung in solchen Migrationen verfügen und dementsprechend die potenziellen Aufwände gut einschätzen können.

Der folgende Ablaufplan illustriert ein Beispiel:

• Die Interessenvertreter definieren den spätestmöglichen Zeitpunkt für die Durchführung der Migration.
• Im Rahmen einer Erst-Analyse verschafft sich der leitende Architekt einen groben Überblick über den IST-Zustand.
• Ausgehend von diesem Überblick wird bestimmt, wie viel Vorlaufzeit die einzelnen Phasen benötigen, damit sämtliche Tätigkeiten passend durchführbar sind.
• Es wird zurück gerechnet, wann das Projekt spätestens starten muss, um genügend Zeit für alle Phasen bereitstellen zu können.
• Hieraus ergibt sich der Ressourcenbedarf für die einzelnen Themenbereiche und es können Meilensteine und Regeltermine (insbesondere der Versand von Kommunikationen) geplant werden.

Auch hier gilt: dies ist lediglich als Anregung zu betrachten.

Zugriffsberechtigungen

Für die Analyse der Umgebungen mag es zunächst im Sinne gängiger bewährter Methoden genügen, reine Leserechte zu beantragen (z.B. Globaler Leser und Sicherheitsleseberechtigter). Im Fall von Teams und SharePoint Online können jedoch weitere Rechte erforderlich sein, um individuelle Berechtigungen auf Sites und Kanäle nachvollziehen zu können.

Spätestens zur Migration sollte es dem durchführenden Team jedoch möglich sein, bei Bedarf höhere Rechte (bis hin zu Globaler Administrator) anzufordern. Eine Microsoft 365-Migration stellt einen erheblichen Eingriff in die Infrastruktur dar und erfordert grundsätzlich viele Berechtigungen, um alle damit verbundenen Tätigkeiten durchführen zu können.

Es sollte daher unbedingt vermieden werden, dass am Migrationstag einzelne Schritte aufgrund fehlender Rechte nicht durchgeführt werden können, so dass die Migration im schlimmsten Fall abgebrochen werden muss.

Tipp: In Migrationen hat es sich gezeigt, dass mittels Entra Privileged Identity Management aktivierte Rollenzuweisungen oftmals nicht wie erwartet funktionieren. So konnten bspw. in Exchange Online zusätzliche E-Mail-Adressen nicht hinzugefügt werden, obwohl der zuständige Mitarbeitende die Rolle Exchange-Administrator aktiviert hatte (eine Neuanmeldung, private Browser-Sitzung, usw. wurden getestet).

Daher mag es zumindest für den Migrationszeitraum besser sein, die Rollen fest zuzuweisen, um solche Probleme ebenfalls zu vermeiden.

Projektphasen

Unabhängig von der Projektstruktur durchläuft ein Projekt typischerweise einige Phasen, die jeweils einen bestimmten Fokus haben. Die folgenden Kapitel erläutern die diese Phasen. Diese sind nicht exklusiv für Microsoft 365-Projekte zu sehen, sondern können in dieser Form durchaus auch in anderen Projekten vorkommen.

Phase 1: IST-Analyse

Zu Beginn des Projekts ist es erforderlich, sich einen Überblick zu verschaffen - sowohl über die Quell- als auch die Zielumgebung. Diese sogenannte IST-Analyse muss mindestens zu folgenden Ergebnissen führen:

• Der zeitliche und organisatorische Aufwand für die Migration wird einschätzbar.
• Potenzielle Hürden und verhindernde Dinge werden erfasst, so dass entsprechende Mitigationen erarbeitet werden können.
• Es existiert ein Überblick über die zu betrachtenden und migrierenden Dienste und Ressourcen.
• Ggf. notwendige infrastrukturelle Anpassungen werden offensichtlich (bspw. Active Directory, lokale Exchange Server, Endgeräte).
• Rahmenbedingungen für die Migration werden festgelegt (Compliance- und Sicherheitsvorgaben, Budget, usw.).
• Kommunikationsbedarfe werden ermittelt (z.B. Migrationsdatum, Mitwirkungspflichten der Benutzer, Anpassungen mit Auswirkungen auf Benutzer, usw.).
• Es können einzelne Aufgaben(-pakete) erstellt und den Projektbeteiligten individuell zugewiesen werden.

Phase 2: Konzeption

Auf Basis der Ergebnisse der IST-Analyse kann nun eine Detailplanung für die Vorbereitung und Durchführung der Migration erarbeitet werden. Je nachdem, ob es sich dabei um eine Integration oder eine Ausgliederung handelt, können hierbei unterschiedliche Dokumente entstehen, beispielsweise:

Parallel dazu ist die für die Aufgabenplanung verwendete Lösung (z.B. Microsoft Planner) mit passenden Detailaufgaben zu versehen und den Projektbeteiligten zuzuweisen. Wichtig ist hierbei die Definition eines jeweiligen Enddatums sowie die Berücksichtigung von Abhängigkeiten.

Phase 3: Vorbereitung

Sobald das Migrationskonzept erstellt und die Aufgabenplanung befüllt sind, kann mit den vorbereitenden Maßnahmen begonnen werden. Diese teilen sich in technische und organisatorische Vorbereitungen auf.

Technische Vorbereitungen

Technische Vorbereitungen sind beispielsweise:

• Aktivierung und Grundeinrichtung der Migrationslösung
• Entwicklung eines Verfahrens für die Geräteübernahme oder Planung eines Gerätetauschs inkl. automatischer Installation
• Bei Ausgliederung: Aufbau des neuen Mandanten und Härtung gemäß Konzept(en) sowie Übernahme von Konfigurationen der einzelnen Dienste
• Bei Integration: Vorbereitung von Infrastruktur, Diensten und Ressourcen für die Aufnahme neuer Objekte (Benutzer, Gruppen, Geräte)
• Durchführung von initialen und Delta-Datensynchronisationen

Ziel dieser Teilphase ist es, die Zielumgebung und die zu migrierenden Ressourcen so vorzubereiten, dass die eigentliche Migration in einem möglichst kurzen Zeitfenster und ohne größere Beeinträchtigungen durchgeführt werden kann.

Organisatorische Vorbereitungen

Organisatorische Vorbereitungen sind beispielsweise:

• Vorbereitung und Versand von Kommunikationen (ggf. inkl. Anleitungen)
• Anforderung notwendiger Berechtigungen für die betroffenen Dienste (auch externe Dienste wie DNS-Verwaltung)
• Anpassung von Microsoft 365-Abonnements (Umstellung auf monatlich, kündigen)
• Marktkommunikation (Ankündigung der Veränderung inkl. potenzieller Auswirkungen auf künftige Zusammenarbeit)
• Durchführung von FAQ-Termin(en) mit Mitarbeitenden des betroffenen Unternehmens

Ziel dieser Teilphase ist es, alle relevanten Vorgaben und Rahmenbedingungen zu erfüllen, so dass die Migration wie geplant durchgeführt werden kann.

Phase 4: Migration

Sind alle Vorbereitungen erfolgreich abgeschlossen, kann die Migration im geplanten Zeitfenster durchgeführt werden. Je nach Migrationsverfahren und Umfang der zu migrierenden Ressourcen sind hierfür unterschiedliche Zeitfenster denkbar:

^{* teilweise gestuft: Datenmigration im Übernahmeverfahren, Endgeräte im Anschluss und schrittweise}

Am Tag der Migration ist am Morgen ein Abstimmungstermin zu planen. Dieser hat die folgenden Ziele:

• Verifikation = alle für die Migration zwingend benötigten Projektbeteiligten sind anwesend und verfügbar
• Verständnis = alle Projektbeteiligten sind sich darüber im Klaren, dass eine Migration bevorsteht und welche Rolle sie dabei spielen
• Zugriff = alle während der Migration notwendigen Zugriffe sind bekannt, verfügbar und funktionieren

Für die eigentliche Migration ist ein separater Termin aufzusetzen. Es empfiehlt sich, diesen (auch) in digitaler Form zu planen. Auf diese Weise können sich die Projektbeteiligten schnell miteinander abstimmen, vor allem, wenn sie sich nicht am gleichen Standort befinden.

Auch ist es so Interessenvertretern möglich, sich in den Termin einzuklinken und einen aktuellen Status zu ermitteln.

Phase 5: Priorisierte Unterstützung

Es wäre illusorisch, zu erwarten, dass eine Migration völlig ohne Störungen oder Probleme abgeschlossen werden kann. Typischerweise funktionieren die geplanten Abläufe (z.B. MFA-Registrierung, Umstellung von Endgeräten, Zugriff auf die migrierten Daten) für den Großteil der Benutzer.

Einige Benutzer mögen jedoch aufgrund unterschiedlicher Ursachen auf Probleme stoßen. Gerade bei größeren Unternehmen kann so schnell eine sehr hohe Arbeitslast für den Servicedesk entstehen.

Aufgrund dessen ist es empfehlenswert, vorübergehend zusätzliche Ressourcen für die Abarbeitung solcher Störungen bereitzustellen. Diese Ressourcen können beispielsweise vom Projektteam gestellt werden. Alternativ ist auch der Einsatz eines externen Dienstleisters oder das Hinzuziehen anderer (IT-)Bereiche des Unternehmens denkbar, beispielsweise sogenannte "Power User".

Ziel ist es, Störungen so schnell wie möglich zu beseitigen, um den ordentlichen Geschäftsbetrieb sicherzustellen. In größeren Migrationen trägt dies auch dazu bei, die Akzeptanz der noch zu migrierenden Benutzer sicherzustellen. Diese sehen, dass schnell auf Störungen reagiert wird und können so mit einem guten Gefühl in ihre eigene Migration gehen.

Die Dauer einer solchen priorisierten Unterstützung (auch als "Hyper Care" bezeichnet) richtet sich nach dem Migrationsvorgehen und nach der Anzahl umgestellter Benutzer. Dementsprechend kann diese Phase typischerweise von einigen wenigen Tagen bis zu einer oder zwei Wochen reichen.

Phase 6: Nachbereitung

Nachdem die Migration abgeschlossen wurde und keine größeren Störungen mehr vorhanden sind, kann die letzte Phase starten. Diese hat zum Ziel, Quell- und Zielumgebung zu bereinigen und das Projekt zum Abschluss zu bringen.

Zur Bereinigung gehören beispielsweise:

• Entfernung von Zugriffen (personalisierte Konten und Zugriffe für die Migrationslösung)
• Abbau nicht mehr benötigter Systeme (z.B. Migrationslösung, Exchange Server)
• Kündigung von Abonnements (Drittherstellerprodukte, Microsoft 365-Lizenzen, usw.)

Zum Abschluss des Projekts ist es empfehlenswert, eine Abstimmung mit allen Projektbeteiligten durchzuführen und Erfahrungen zu sammeln:

• Was ist gut gelaufen?
• Was hätte besser laufen können?
• Wie wurde die Kommunikation während des Projekts wahrgenommen?
• War der geplante Projektzeitraum realistisch angesetzt?
• Wurden ausreichende Ressourcen für das Projekt eingeplant?
• ...

Die gesammelten Erfahrungen können dazu beitragen, künftige Projekte zu verbessern, besonders wenn weitere Microsoft 365-Migrationen anstehen. Diese können entscheidend von diesen Erfahrungen profitieren. Daher ist es auch empfehlenswert, im Projektverlauf immer wieder darauf hinzuweisen, dass die Projektbeteiligten ihre Erfahrungen notieren sollen.

Fazit

Eine Microsoft 365-Migration ist grundsätzlich ein sehr komplexes Vorhaben. Eine planvolle Vorgehensweise und überlegte Projektstruktur tragen jedoch entscheidend zum Erfolg eines solchen Projekts bei. Dadurch wird eine sorgfältige und durchdachte Durchführung der Migration ermöglicht und die daraus gewonnenen Erfahrungen sind sehr wertvoll - nicht nur für Microsoft 365-Migrationen!

Gefällt Dir der Beitrag? Lass es andere wissen!

• Share on LinkedIn
• Share on Bluesky
• Share on Facebook
• Email this Page
• Share on Reddit