Microsoft 365-Migrationen | Teil 5: Technisches Zieldesign
Krähe mit HutSobald alle organisatorischen und rechtlichen Voraussetzungen geklärt sind, kann es nun endlich mit der Technik losgehen. Und diese hat es in sich - je nach Größenordnung, beteiligten Systemen/Applikationen und geplantem Vorgehen kann es sehr komplex werden!
Typischerweise ergeben sich spätestens jetzt noch einmal Anpassungen am Projektplan. Dieser wurde zunächst eher global und nach bestem Ermessen aufgebaut. Üblicherweise ergeben sich jedoch immer wieder Details, die einer Abstimmung bedürfen, zusätzliche Schritte erfordern oder auch das Projekt vorübergehend zum Stillstand bringen können.
Dieser Artikel soll daher einmal einen Einblick geben, wie ein technisches Zieldesign für eine Microsoft 365-Migration aussehen kann und welche Stolpersteine sich jeweils ergeben können.
Zieldesigns in unterschiedlicher Komplexität
Eines vorweg: es gibt nicht DAS Zieldesign, das jedes Unternehmen für sich anwenden kann. Dies muss individuell bestimmt werden und richtet sich unter anderem nach folgenden Fragestellungen:
- Gibt es ein bereits vordefiniertes Zeitfenster, das unbedingt eingehalten werden muss (z.B. aufgrund rechtlicher Aspekte)?
- Welche Dienste müssen migriert werden? (z.B. Exchange Online, SharePoint Online, Teams, Power Platform, usw.)
- Müssen eventuell auch lokal bereitgestellte Systeme bei der Migration berücksichtigt werden (z.B. Active Directory, Exchange Server, SharePoint Server, usw.)?
- Wie stark soll die Umstellung der Benutzer/Geräte automatisiert werden bzw., erhalten die Benutzer in diesem Zuge neue Geräte?
- Welcher Ansatz wird für die Entstörung potenziell auftauchender Fehler und Ausfälle verfolgt (sogenannter "Fix forward"-Ansatz oder sehr sorgfältige Planung zur Störungsminimierung)?
- Handelt es sich um eine Integration oder eine Ausgliederung?
Die folgenden Kapitel zeigen einige Zieldesigns, die ich in der Praxis schon geplant und umgesetzt habe. Die Inhalte bauen aufeinander auf, d.h. jedes Kapitel setzt automatisch die Überlegungen und Planungen des vorangegangenen Kapitels voraus.
Geräteunabhängige Migration
| Kurzbeschreibung | Es werden lediglich neue Konten angelegt und Daten aus der Quell- in die Zielumgebung übertragen |
| Szenario | Kurzer Migrationszeitraum (Wochen, wenige Monate), geringe Migrationskomplexität |
Aufgrund von Faktoren wie Firmenauflösungen oder rechtlich zeitkritischen Trennungen kann es erforderlich sein, eine Migration so schnell wie möglich durchzuführen. In so einem Fall wird das absolut erforderliche Minimum an Aufgaben geplant, welches für eine saubere Übertragung von Daten und Konten notwendig ist. Hierzu gehören:
- Bestimmung der zu migrierenden Microsoft 365-Dienste (z.B. Exchange, Teams, SharePoint, OneDrive, aber auch Power Platform, Power BI, Purview, usw.)
- Bestimmung der zu migrierenden Objekte (Benutzer, Gruppen, Sites, an Entra ID angebundene Apps)
- Bestimmung der zu nutzenden Lizenzen in Abhängigkeit von Sicherheits- und Compliance-Vorgaben
- Festlegung, welche Domäne und Benutzernamensyntax für die externe Kommunikation genutzt werden soll/muss
- Ermittlung von Abhängigkeiten von Dritthersteller-Apps und -Systemen zu Entra ID und Microsoft 365 und Planung der Umstellung
Da in diesem Szenario keinerlei oder nur wenige Automatismen (bspw. die Datenmigration) eingesetzt werden, ist eine umfassende und sorgfältige Benutzerkommunikation umso wichtiger. Die Benutzer führen im Regelfall Umstellungsmaßnahmen selbständig durch. Daher benötigen sie hierfür Anleitungen und Informationen zu den bevorstehenden Änderungen in geeigneter Form.
Diese Form der Migration eignet sich jedoch nicht für eine Ausgliederung. In diesem Fall müssen die Endgeräte zwingend mit betrachtet werden, da diese rein rechtlich dem ausgliedernden Unternehmen gehören und ggf. auch Applikationen installiert sind, die durch das ausgegliederte Unternehmen nicht mehr genutzt werden dürfen. Für diesen Fall kommt die nächste Migrationsform in Betracht.
Sofern Infrastruktur über VPN erreichbar ist, kann diese über die bisherige Implementierung weiter genutzt werden. Infrastruktur des aufnehmenden Unternehmens kann entweder über das gleiche VPN oder einen zusätzlichen VPN-Client erreichbar gemacht werden.
Geräteabhängige Migration
| Kurzbeschreibung | Neben den Daten und Benutzerkonten werden auch Endgeräte migriert oder neue Endgeräte bereitgestellt |
| Szenario | Mittlerer Migrationszeitraum (einige Monate), mittlere Migrationskomplexität |
Beim Minimalansatz werden die Geräte der Mitarbeitenden nicht betrachtet (abgesehen vom notwendigen Kontenwechsel). Je nachdem, wie diese Geräte bisher eingebunden waren und verwaltet worden sind, können sich hieraus wiederkehrende Störungen für die Mitarbeitenden oder auch für die Geräteverwaltung ergeben. Die folgende Liste zeigt einige Beispiele hierfür:
- Das Gerät wurde, um das Benutzerprofil des Mitarbeitenden zu erhalten, nicht aus dem Active Directory/Entra ID der Altumgebung entfernt. Der Benutzer muss sich daher weiterhin mit den Daten der Altumgebung am Gerät anmelden.
- Eine Entfernung des Geräts aus einer Verwaltungslösung wie Intune ist unter Umständen nicht ohne eine vollständige Zurücksetzung des Geräts möglich. Eine parallele Verwaltung des Geräts über eine andere Lösung ist jedoch ebenfalls nicht möglich.
- Auch nach Entfernung der alten Konten vom Gerät können Konfigurationsreste auf dem Gerät verbleiben. Diese können dazu führen, dass die Apps immer wieder versuchen, sich über die Altumgebung zu authentifizieren, was zu Fehlermeldungen führt.
Aus diesen Gründen ist es empfehlenswert, auch eine Endgeräte-Migration zu planen. Dies erhöht die Komplexität jedoch erheblich, da die Nutzung der Geräte sorgfältig erfasst werden muss. Die folgende Tabelle zeigt typische Fragestellungen in diesem Kontext:
| Fragestellung | Herangehensweise |
|---|---|
| Können Daten auf dem lokalen Gerät gespeichert werden und wie ist die Unternehmensrichtlinie für den Umgang damit gestaltet? | Daten in OneDrive oder eine andere zentrale Speicherlösung übertragen, lokale Speicherung untersagen |
| Welche Applikationen werden (weiterhin) benötigt und welche Voraussetzungen müssen dafür erfüllt werden? | Bei Ausgliederung: Zugriff per VPN, Remotedesktop oder passender Alternative ermöglichen Bei Integration: Prüfen, wie Zugriff auf die Applikation aus der neuen Umgebung realisiert werden kann |
| Welche Richtlinien und Konfigurationen werden auf den Geräten benötigt? | Bisherige Verwaltungslösung prüfen und Konfigurationen sowie Richtlinien nach Möglichkeit übernehmen |
| Wie melden sich Benutzer an den Geräten an und welche Auswirkungen hat dies auf Sicherheitsanforderungen und Authentifizierungsmethoden? | Anmeldemethode(n) prüfen und ggf. Alternativen bereitstellen. |
| Unterstützen die Geräte moderne Betriebssysteme oder sind aufgrund von Sicherheitsanforderungen (teilweise) neue Geräte erforderlich? | Hardwareausstattung der Geräte erfassen und wo nötig, einen Austausch durchführen |
Je nach Situation können die Geräte mithilfe einer Lösung wie Autopilot in Intune neu installiert werden. Alternativ erhalten die Mitarbeitenden im Vorfeld der Migration neue Geräte. Auf diese Weise können sie sich an Neuerungen und Veränderungen besser gewöhnen, die mit der Migration einhergehen. Auch steht das alte Gerät weiter zur Verfügung, falls noch etwas fehlen sollte.
Vollmigration
| Kurzbeschreibung | Sämtliche (Cloud)-Ressourcen des Unternehmens werden in die zentrale Umgebung integriert bzw. aus der zentralen Umgebung ausgelagert. |
| Szenario | Längerer Migrationszeitraum (viele Monate bis einige Jahre), hohe Migrationskomplexität. Eignet sich eher für kleine Unternehmen oder wenn der Migrationszeitraum nur eine untergeordnete Rolle spielt. |
Das Ziel einer Vollmigration ist ein vollständiger Übergang der Cloud- und ggf. auch lokalen Ressourcen des zu integrierenden bzw. auszugliedernden Unternehmens. Hierbei handelt es sich strenggenommen jedoch nicht mehr um eine reine Microsoft 365-Migration, da auch Ressourcen anderer Dienste wie Azure und Active Directory sowie Serverrollen betrachtet werden müssen. Gerade im Fall einer Ausgliederung mag dies jedoch zwingend erforderlich sein.
Die Migration von lokalen und Azure-Ressourcen bzw. der Aufbau einer neuen Azure-Plattform (oder auch einer lokalen Plattform, falls erforderlich) ist ein sehr komplexer Vorgang und wird daher in dieser Artikelserie nicht weiter betrachtet.
Unabhängig davon kann dieser Migrationstyp dazu genutzt werden, "alte Zöpfe abzuschneiden". Da ohnehin die gesamte Infrastruktur betrachtet wird, ist in diesem Zuge eine Modernisierung sehr sinnvoll. Beispielsweise...
- ...kann ein lokales Active Directory so umgebaut werden, dass die Verwaltung aus Entra ID heraus erfolgen kann.
- ...können klassische Dateifreigaben entweder nach SharePoint Online überführt oder in Cloud-Freigaben in Azure File Shares übertragen werden.
- ...können Drucker über die moderne Variante Azure Universal Print bereitgestellt werden.
Dies kann effektiver sein, als diese Dienste weiterhin klassisch über ein VPN erreichbar zu machen, was mit zusätzlichen Aufwänden für Authentifizierung und Routing verbunden sein kann.
Parallelbetrieb
| Kurzbeschreibung | Aufgrund bestimmter Faktoren kann keine zeitnahe Migration stattfinden. Mitarbeitende müssen jedoch bereits die neue Domäne für die Außenkommunikation verwenden. Mitarbeitende erhalten daher zusätzliche Konten in der neuen Umgebung. |
| Szenario | Längerer Übergangszeitraum, bis blockierende Faktoren beseitigt sind. Migrationszeitraum und Komplexität richten sich nach dem notwendigen Migrationsverfahren. Üblicherweise wird eine Vollmigration gewählt, da in diesem Szenario normalerweise ausreichend Zeit hierfür gegeben ist. |
Es gibt Szenarien, in denen eine Migration aufgrund zeitlicher oder rechtlicher Anforderungen ggf. (noch) nicht möglich ist. In solchen Szenarien kommt ein Parallelbetrieb infrage, bei dem Mitarbeitende für eine gewisse Zeit Konten in beiden Umgebungen erhalten. Dieser Parallelbetrieb gliedert sich wiederum in zwei mögliche Varianten auf:
- Vorab-Zugriff auf interne Ressourcen im Rahmen einer Eingliederung
- Bereitstellung einer vollwertigen Kommunikation unter einer neuen Domäne im Rahmen einer Ein- oder Ausgliederung
Vorab-Zugriff auf interne Ressourcen
Nach dem Zukauf eines neuen Unternehmens wird dieses nicht unbedingt gleich in die interne Infrastruktur integriert. In manchen Fällen wird die neue Gesellschaft zunächst in einer Earn-Out-Phase dahingehend geprüft, ob sie die versprochenen Umsätze erwirtschaften kann. Werden die Anforderungen nicht erfüllt, kann es passieren, dass die Gesellschaft aufgelöst oder abgestoßen wird.
Dennoch kann es erforderlich sein, Mitarbeitenden der zu integrierenden Gesellschaft bereits einen Zugriff auf interne Ressourcen bereitzustellen. Für diesen Fall erhalten die Mitarbeitenden vorab Gastbenutzer in der aufnehmenden Umgebung, damit diese in vorhandene Teams-Räume und Dokumentbibliotheken eingebunden werden können. Auf diese Weise können die neuen Mitarbeitenden bereits interne Strukturen und Abläufe kennenlernen und sich so auf die bevorstehende Integration vorbereiten sowie an Projekten der aufnehmenden Gesellschaft mitarbeiten.
Im Zuge der Integration/Migration werden dann keine neuen lizenzierten Konten angelegt. Stattdessen werden die vorhandenen Gastbenutzerkonten in interne Benutzerkonten umgewandelt und lizenziert. Die Mitarbeitenden erhalten in diesem Zuge dezidierte Zugangsdaten für diese Konten. Ggf. vorhandene Authentifizierungsmethoden wie die Authenticator App bleiben erhalten und können weiter genutzt werden.
In diesem Zuge können jedoch auch die Sicherheitsanforderungen erhöht und die Mitarbeitenden zur Einrichtung einer phishing-resistenten Authentifizierung (z.B. FIDO2-Sicherheitsschlüssel, Passkeys in der Authenticator App, usw.) aufgefordert werden. Dies ist technisch aktuell mit Gastbenutzern noch nicht möglich.
Vollwertige Kommunikation unter einer neuen Domäne
Aufgrund von Faktoren wie Firmenauflösungen oder rechtlich notwendigen Ausgliederungen kann es erforderlich sein, eine Kommunikation unter einer neuen Domäne schnellstmöglich bereitzustellen. In solchen Fällen mag es nicht möglich sein, zuvor eine Migration zu planen und vollständig abzuschließen.
Stattdessen erhalten die Mitarbeitenden vorab bereits Zugänge in der neuen Umgebung, um ihnen die Kommunikation unter der neuen Domäne zu ermöglichen. Hierfür sind vollwertige Zugänge (d.h. lizenzierte Benutzerkonten des Typs "Mitglied") notwendig, da Gastbenutzer kein E-Mail-Postfach in einem anderen Mandanten nutzen bzw. darauf zugreifen können (auch nicht auf freigegebene Postfächer).
In einem solchen Fall muss auch berücksichtigt werden, dass die Kommunikation über die bisherige Domäne technisch unterbunden werden muss. Dies kann für E-Mail beispielsweise über Transportregeln in Exchange Online realisiert werden. In Teams kann die externe Kommunikation selektiv auf Basis von Entra-Sicherheitsgruppen eingeschränkt werden, falls erforderlich.
Hat Dir dieser Artikel gefallen? Lass es andere wissen!
One thought on “Microsoft 365-Migrationen | Teil 5: Technisches Zieldesign”