Microsoft 365-Migrationen | Teil 9: Analyse der Umgebungen
Krähe mit HutEin wichtiger Bestandteil jedes Migrationsprojekts stellt die IST-Analyse dar. Es muss ermittelt werden, welche Ressourcen migriert werden müssen und welche Schritte sich hieraus für die Vorbereitung und Durchführung der Migration ergeben. Hierbei kommt es auch darauf an, welche Migrationslösung ausgewählt wurde, da nicht alle Lösungen über den gleichen Funktionsumfang verfügen. So kann es sein, dass zusätzliche Schritte berücksichtigt werden müssen.
Dieser Artikel beschreibt mögliche Herangehensweisen für die Analyse sowie typische Fragestellungen und Hürden, die sich hierbei ergeben können.
Datenerfassung
Es gibt mehrere Ansätze, die Datenerfassung durchzuführen. Dies ist von der Beantwortung der folgenden Fragen abhängig:
Unabhängig davon fahre ich persönlich in meinen Migrationsprojekten gern einen mehrstufigen Ansatz, sofern möglich:
- Erstellung von Berichten mit Microsoft 365 DSC
- Erfassung von Detailkonfigurationen mittels PowerShell-Skripten
- Manuelle Analyse über die unterschiedlichen Admin-Portale
Auf diese Weise werden mehrere Tätigkeiten gleichzeitig abgedeckt:
- Dokumentation des Ausgangszustands
- Nachvollziehbarkeit, welche Analysen durchgeführt werden und welche ggf. noch fehlen
- Ganzheitlicher Blick auf die notwendigen Schritte für Vorbereitung und Durchführung der Migration
In der Folge werden die einzelnen Ansätze näher beschrieben.
Microsoft 365 DSC
Eine schnelle Variante zur Erfassung des IST-Zustands sowohl von Quell- als auch Zielumgebung stellt der Einsatz von Automatisierungswerkzeugen dar. Diese nutzen üblicherweise PowerShell zur Ermittlung von Informationen. Microsoft stellt hierfür eine kostenlose Lösung namens Microsoft 365 DSC zur Verfügung (Introduction - Microsoft365DSC - Your Cloud Configuration).
M365 DSC ist nicht explizit für Microsoft 365-Migrationen gedacht, sondern wird eher dazu genutzt, um Sicherungen der Konfiguration eines Mandanten zu erstellen und Abweichungen davon automatisiert zu beheben oder zu warnen. Auch können die Konfiguration zweier Mandanten miteinander verglichen und Änderungen ermittelt/übertragen werden. Dies eignet sich beispielsweise für separate Testumgebungen, deren Konfiguration möglichst nah an der Produktivumgebung gehalten werden soll.
Diese Funktionalität kann auch dazu verwendet werden, um den IST-Zustand der Quellumgebung sowie Abweichungen zwischen Quell- und Zielumgebung bei einer Microsoft 365-Migration zu ermitteln. Es können Berichte in unterschiedlichen Formaten erstellt werden (CSV, HTML, Excel, Markdown oder JSON).
Das Vorgehen ist wie folgt:
- App-Registrierung in Entra ID mit den notwendigen Rechten erstellen (empfohlen, da diese von allen Diensten unterstützt wird)
- Konfigurationsexport erstellen (Tipp: unter der Webseite Microsoft365DSC - Configuration-as-Code for the Cloud können die Inhalte des Exports granular ausgewählt und der dafür notwendige Befehl generiert werden)
- Bericht aus Konfigurationsexport erstellen
Ein mit M365 DSC HTML-Bericht sieht beispielhaft wie folgt aus:
Erfassung von Detailkonfigurationen mittels PowerShell
Der mittels M365 DSC generierte Bericht kann sehr umfangreich sein. Gleichzeitig sind bei weitem nicht alle gesammelten Informationen im Rahmen einer Migration relevant. Auf der anderen Seite fehlen wichtige Detailinformationen, die für die Migration benötigt werden. Dies ist auch nachvollziehbar, da diese für den Zielkontext von M365 DSC (Diensteinstellungen und Alarmierung/automatische Rekonfiguration im Fall einer Abweichung) nicht notwendig sind.
Aus diesem Grund habe ich mir eine Sammlung an Skripten erstellt, mit denen ich wichtige Detailinformationen in Exportdateien sichere. Dies hat mehrere Hintergründe:
- Dokumentation des Ausgangszustands für Detailkonfigurationen, so dass diese entweder 1:1 oder möglichst nah in der Zielumgebung nachgebildet werden können.
- Übergabe an das aktuelle Betriebsteam zur Ermittlung von Migrationsbedarfen oder zur Bereinigung nicht mehr benötigter Ressourcen.
Die folgende Tabelle zeigt die Skripte und deren jeweiligen Einsatzzweck. Diese habe ich aktuell noch nicht in meinem Skriptnest abgelegt, dies werde ich jedoch nach und nach tun, wenn die Skripte vorzeigbar sind. 😉
| Skript | Bereich | Verwendungszweck(e) |
|---|---|---|
| Export-EIDGuestUsers.ps1 | Entra ID | Export aller Gastbenutzer. Gastbenutzer werden normalerweise nicht migriert, sondern nach Bedarf in der Zielumgebung neu eingeladen. Die Liste ermöglicht eine Bewertung, welche Gastbenutzer weiterhin benötigt und dementsprechend informiert werden sollten. Die Exportdatei enthält nützliche Informationen zur Bewertung, bspw. Einladungsdatum, Einladungsstatus und letzte Änderung. |
| Export-EIDUserPhotos.ps1 | Entra ID | Export von Benutzerfotos für einen späteren Import in der Zielumgebung. Dies ist dann notwendig, wenn die Migrationslösung nicht für die Migration von Benutzerkonten genutzt wird (bzw. werden kann) oder hierbei die Fotos nicht übertragen werden. |
| Export-EXOEmailAliases.ps1 | Exchange Online | Export von E-Mail-Aliasen aller Postfächer, Verteilergruppen und E-Mail-aktivierter Sicherheitsgruppen für einen späteren Import in der Zielumgebung |
| Export-EXOEOPandMDOPolicies.ps1 | Exchange Online | Export von Richtlinien in Exchange Online Protection und Defender for Office 365, sofern in Verwendung zur späteren manuellen Neuanlage in der Zielumgebung |
| Export-EXOInboxAndForwardingRules.ps1 | Exchange Online | Export von Posteingangsregeln in den Postfächern sowie serverseitigen Weiterleitungs-/Umleitungsregeln. Die Regeln werden nur sicherheitshalber exportiert, da diese normalerweise durch die Migrationslösungen übertragen werden. Bei Fehlern kann jedoch ggf. die Exportliste herangezogen werden. |
| Export-EXOMailboxAccessPermissions.ps1 | Exchange Online | Export der Postfachberechtigungen "Senden als", "Senden im Auftrag von" und "Vollzugriff". Die Berechtigungen werden nur sicherheitshalber exportiert, da diese normalerweise durch die Migrationslösungen übertragen werden. Bei Fehlern kann jedoch ggf. die Exportliste herangezogen werden. |
| Export-EXOPublicFolders.ps1 | Exchange Online | Export aller Öffentlichen Ordner, sofern vorhanden. Sinnvollerweise werden Öffentliche Ordner vorbereitend in freigegebene Postfächer überführt. Ist weiterhin ein Einsatz Öffentlicher Ordner notwendig, so kommt es auf die Migrationslösung an, ob diese migriert oder manuell neu angelegt werden müssen. |
| Export-PPLAdminFlows.ps1 | Power Platform | Export der Admin-Flows aus der Power Platform. Flows können bei manchen Migrationslösungen zwar mitgenommen werden, müssen allerdings in der Zielumgebung manuell angepasst werden (bspw. Connectors oder URLs). Die Exportliste kann außerdem als Bewertungsgrundlage verwendet werden, welche Flows ggf. nicht mehr benötigt werden. |
| Export-PVWPolicies.ps1 | Purview | Export aller Richtlinien, bspw. Aufbewahrungs- und DLP-Richtlinien. Diese müssen bei Bedarf später in der Zielumgebung neu angelegt und wieder auf die Zielressourcen angewendet werden. Wird der Microsoft Migration Orchestrator verwendet, müssen außerdem jegliche Richtlinien deaktiviert werden, da diese die Migration blockieren. |
| Export-TMSChannelAddresses.ps1 | Teams | Export der E-Mail-Adressen von Microsoft 365-Gruppen und Teams-Kanälen. Typischerweise werden die E-Mail-Adressen nicht aktiv verwendet und die Gruppen und Kanäle können nach der Migration eine neue Adresse erhalten. Für den Fall, dass die bisherigen Adressen aktiv genutzt werden, können diese anhand der Exportliste bei Bedarf wiederhergestellt werden. |
| Export-TMSPhoneNumberAssignments.ps1 | Teams | Falls Teams-Telefonie eingesetzt wird, können hiermit die Rufnummer-Zuweisungen exportiert werden. Der Export kann verwendet werden, um die Rufnummern in der Zielumgebung wieder zuzuweisen. |
Manuelle Analyse
Neben all den technischen Möglichkeiten verschaffe ich mir auch gern noch einmal ganz klassisch selbst einen Überblick über die Quellumgebung. Hierzu fordere ich zunächst die Rollen Globaler Leser, Sicherheitsleser und Leser für Azure an. Diese sind erst einmal für einen groben Überblick ausreichend.
Stelle ich fest, dass das Unternehmen auch die Power Platform nutzt und/oder Individuallösungen in SharePoint Online einsetzt, sind üblicherweise weitere Berechtigungen erforderlich, um hier weiteren Einblick zu nehmen. Die Leserollen erteilen nämlich keinen Zugriff auf Bereiche innerhalb der jeweiligen Plattform. Alternativ kann die Detailanalyse in diesen Bereichen auch zusammen mit dem Betriebsteam für die Umgebung erfolgen.
Im Rahmen dieser Analyse erstelle ich weitere Exporte aus den einzelnen Bereichen. Diese werden in der folgenden Tabelle im Detail dargestellt:
| Bereich | Exporte und Inhalte | Verwendungszweck(e) |
|---|---|---|
| Entra Admin Center | - App-Registrierungen - Geräte - Interne Benutzer - LAPS - Sicherheitsgruppen - Unternehmensanwendungen | Es muss geprüft werden, ob es App-Registrierungen und/oder Unternehmensanwendungen gibt, die auch nach der Migration weiter benötigt werden. Diese müssen in der Zielumgebung manuell neu angelegt werden. Bei Geräten kann der Einbindungstyp relevant für die Entscheidung sein, ob diese migriert werden oder nicht. Typischerweise wird durch die Migration ein neues Benutzerprofil erzeugt und der Mitarbeitende muss dieses komplett neu einrichten. Dies ist jedoch eher in Verbindung mit einem Gerätewechsel sinnvoll. Interne Benutzer und Sicherheitsgruppen sind ebenfalls dahingehend zu prüfen, ob diese noch benötigt werden und welche Zugriffe/Lizenzen diese benötigen. Gerade Dienstkonten sind oftmals mit zu großen Lizenzen ausgestattet und verursachen daher unnötige Mehrkosten. Setzt das Unternehmen LAPS ein und werden die Geräte nicht migriert, so ist zu beachten, dass während der Laufzeit der Geräte weiterhin ein Zugriff auf die Altumgebung erforderlich ist, um Administratorkennwörter abrufen zu können. |
| Exchange Online Admin Center | - Benutzer-, Funktions- und freigegebene Postfächer - Connectors - Kontakte - Ressourcenpostfächer - Transportregeln - Verteilergruppen (inkl. E-Mail-aktivierte Sicherheitsgruppen) | Alle Postfächer sind dahingehend zu prüfen, ob sie noch weiterhin benötigt werden. Ebenfalls ist zu prüfen, ob lizenzierte Postfächer weiterhin eine Lizenz benötigen oder auch in ein freigegebenes Postfach umgewandelt werden können. Kontakte können auch in Verteilergruppen eingebunden und daher im Rahmen von Arbeitsprozessen wichtig sein. Dies ist zu prüfen. Kontakte müssen bei Bedarf in der Zielumgebung neu angelegt und in Gruppen integriert werden. E-Mail-aktivierte Sicherheitsgruppen werden üblicherweise dazu verwendet, um Berechtigungen auf Postfächer und/oder Öffentliche Ordner zu erteilen. Nicht alle Migrationslösungen können diese migrieren, daher müssen sie üblicherweise manuell neu angelegt werden. |
| Intune Admin Center | - Apps, jeweils pro Plattform - Konfigurationsprofile, jeweils pro Plattform - Skripts und Wartungen - Antivirus-Richtlinien - BitLocker-Richtlinien - Endpoint Privilege Management-Konfigurationen - EDR-Richtlinien - App Control für Business-Richtlinien - Richtlinien zur Verringerung der Angriffsfläche | Unabhängig davon, ob Geräte im Rahmen der Migration ebenfalls migriert werden oder nicht, ist es sinnvoll, die derzeitige Konfiguration der Geräte zu erfassen. Dementsprechend kann die Konfiguration in der Zielumgebung vorbereitet werden, so dass alle neu ausgegebenen Geräte bereits alle Vorgaben erfüllen und direkt nutzbar sind. Setzt das Unternehmen BitLocker ein und werden die Geräte nicht migriert, so ist zu beachten, dass während der Laufzeit der Geräte weiterhin ein Zugriff auf die Altumgebung erforderlich ist, um Wiederherstellungskennwörter abrufen zu können. |
| Microsoft 365 Admin Center | - Microsoft 365-Gruppen (ohne Teams-Aktivierung) - Microsoft 365-Gruppen (mit Teams-Aktivierung) - Nutzung von Umfragen | Manche Migrationslösungen verwenden unterschiedliche Mechanismen zur Migration von Microsoft 365-Gruppen, je nachdem, ob sie für Teams genutzt werden oder nicht. Das Attribut "Teams-aktiviert" wird nur über einen Export im M365 Admin Center ausgegeben, nicht in Entra ID. Umfragen können nicht migriert werden. Falls diese weiter benötigt werden, müssen Benutzer diese manuell neu anlegen (existierende Antworten können exportiert, jedoch nicht wieder importiert werden). Eine Übersicht aller Umfragen kann exportiert werden (Microsoft 365 admin center). Hinweis: damit im Nutzungsbericht ersichtlich ist, wer welche Umfrage erstellt hat, muss die Option zum Ausblenden von Benutzernamen deaktiviert werden (Einstellungen - Microsoft 365 admin center). |
| Power BI Admin Center | - Power BI-Arbeitsbereiche | Power BI-Arbeitsbereiche können bei den meisten Migrationslösungen nicht migriert werden und müssen dementsprechend neu angelegt werden. Es muss jedoch zuvor beurteilt werden, ob der jeweilige Bericht in der Zielumgebung noch benötigt wird und überhaupt lauffähig wäre (aufgrund von ggf. fehlenden Abhängigkeiten). |
| Power Platform Admin Center | - Flows - Power Apps - Systemumgebungen | Die Admin-Flows werden über ein Skript exportiert. Systemumgebungen und Power Apps können bei manchen Migrationslösungen migriert werden, allerdings sind je nach Konfiguration noch einige Nacharbeiten erforderlich. Dementsprechend ist vorher zu prüfen, welche Apps und Umgebungen weiterhin benötigt werden, damit entsprechende Vorbereitungen in der Zielumgebung getroffen werden können. |
| SharePoint Online Admin Center | - Aktueller Speicherverbrauch - SharePoint-Sites (ohne Microsoft 365-Gruppe) | Werden SharePoint-Sites in die Zielumgebung übertragen, wächst dort der Speicherbedarf. Ggf. wird der aktuell zur Verfügung stehende Speicher (zusammengesetzt aus 1 TB für das Unternehmen + 10 GB pro gebuchter M365-Lizenz) jedoch bereits überschritten. Dies ist einerseits für die Kostenplanung relevant. Falls in der Zielumgebung noch die statische Ergänzung von Speicher mittels Addon verwendet wird, muss der zusätzlich benötigte Speicherplatz außerdem rechtzeitig vor der Synchronisation der Daten hinzugefügt werden. Die SharePoint-Sites sind dahingehend zu prüfen, ob sie noch benötigt werden. Außerdem kann es vorkommen, dass Individuallösungen genutzt werden, die ggf. noch veraltete SharePoint-Funktionen und -Strukturen nutzen. Für diese muss ggf. ein eigenes Migrationsprojekt aufgesetzt werden (je nach Komplexität). |
| Teams Admin Center | - Zusätzlich eingebundene Apps - App-Nutzung | Apps können nicht migriert werden. Werden Apps weiterhin benötigt, so müssen diese in der Zielumgebung neu hinzugefügt und den Benutzern zugewiesen werden. Eine Übersicht der aktuell genutzten Apps kann exportiert werden. |
Infrastruktur
Neben den Cloud-Diensten kann auch die Konfiguration lokal bereitgestellter Systeme im Namen der Microsoft 365-Migration relevant sein. Die folgenden Kapitel gehen auf einige Bereiche ein.
Active Directory
Viele Unternehmen setzen Active Directory als zentrale Authentifizierungs-Plattform ein und synchronisieren Objekte wie Benutzer und Gruppen nach Entra ID. Dies erzeugt für die Migration eine Abhängigkeit. Im Rahmen der Migration müssen die Objekte so modifiziert werden, dass keinerlei Referenzen zu den benutzerdefinierten Domänen in Microsoft 365 mehr existieren. Nur dann können die Domänen entfernt und in der Zielumgebung neu angelegt werden.
In einer hybriden Infrastruktur müssen die Referenzen jedoch lokal im Active Directory entfernt und die Änderungen synchronisiert werden. Erfahrungsgemäß kann dies zu deutlichen Verzögerungen im Ablauf führen. Daher ist oftmals eine der folgenden Alternativen besser:
- Deaktivierung der Synchronisation im Rahmen der Migration. Dies wandelt alle synchronisierten Objekte in reine Cloud-Objekte um, ohne dass Objekte gelöscht werden. Dadurch werden alle Objekte direkt in der Cloud modifizierbar.
- Umstellung der Autorität für Änderungen auf Entra ID und Exchange Online. Dadurch werden alle Objekte direkt in der Cloud modifizierbar, die Synchronisation als solche kann jedoch aktiviert bleiben. Dies eignet sich für Szenarien, in denen die Altumgebung für andere Zwecke weiterverwendet werden soll.
Ein weiterer Aspekt ist der spätere Benutzerzugriff auf AD-integrierte Ressourcen nach der Migration. Hierbei kommt es darauf an, ob die Zielumgebung ebenfalls Active Directory verwendet oder nicht:
- Ja: die Einrichtung einer Vertrauensstellung ermöglicht den Zugriff auf die Ressourcen der bisherigen Umgebung mit den neuen Benutzerkonten.
- Nein: die bisherigen Benutzerkonten sind weiterzuverwenden. Es ist zu prüfen, ob die Ressourcen in irgendeiner Form migriert, abgelöst oder abgebaut werden sollen.
Netzwerk
Die Netzwerk-Infrastruktur des Unternehmens als solche ist für eine Microsoft 365-Migration zunächst unerheblich. Diese spielt dann eine Rolle, wenn auch andere Themen wie AD-Vertrauensstellungen oder Konnektivität zwischen Standorten bzw. zu einer Azure-Umgebung betrachtet werden müssen. In diesen Fällen muss geprüft werden, ob es Überschneidungen zwischen den Umgebungen gibt, die dann entsprechend aufgelöst werden müssen (bspw. durch Anpassung von Subnetzen oder NAT-Regeln).
Typischerweise stellt das aufnehmende Unternehmen zentrale Applikationen zur Verfügung. Manche davon mögen aus Sicherheitsgründen nur über VPN erreichbar sein. Dementsprechend gibt es die folgenden Wege, den Mitarbeitenden einen Zugriff zu ermöglichen:
- Site-2-Site-VPN zwischen den Standorten der Unternehmen
- Point-2-Site-VPN für die Mitarbeitenden - entweder zusätzlich zu einem S2S-VPN (für den Zugriff aus dem Home Office oder von unterwegs) oder als Alternative, falls S2S-VPN nicht möglich sein sollte
Falls das aufnehmende Unternehmen eine andere Benutzer-App verwendet, ist diese ist den Mitarbeitenden in geeigneter Form in Verbindung mit einer entsprechenden Anleitung bereitzustellen.
DNS
Der Zugriff auf interne wie externe Apps sollte stets über DNS-Namen statt IP-Adressen erfolgen. DNS-Namen sind leichter einzuprägen, besser nachvollziehbar und außerdem mit Zertifikaten sicherbar.
Für interne Apps kann dies beispielsweise über eine bedingte Weiterleitung im verwendeten DNS-Server des Unternehmens realisiert werden. Ich habe in diesem Kontext auch schon Konstrukte auf Basis von privaten DNS-Zonen in Azure in Verbindung mit einem Private Resolver aufgebaut, welcher von lokalen Standorten angesprochen werden kann. Dies ermöglicht eine Zentralisierung der Namensauflösung in der Infrastruktur des aufnehmenden Unternehmens.
Für den Umzug der benutzerdefinierten Domänen in Microsoft 365 wird ein Zugriff auf die DNS-Verwaltung des zuständigen öffentlichen Anbieters benötigt. Idealerweise kann/können die DNS-Zone(n) in die zentrale Verwaltung des aufnehmenden Unternehmens übertragen werden. Dies erleichtert die Verwaltung und vermeidet Verzögerungen während der Migration.
In meinen Projekten sind mir schon sehr sonderbare DNS-Verwaltungen begegnet. In einigen Fällen war es nicht einmal möglich, Einträge selbst hinzuzufügen oder zu modifizieren. Hierzu musste jedes Mal der Anbieter kontaktiert werden. Dies ist für eine Migration denkbar ungeeignet, da hier in einem relativ kurzen Zeitraum einige bis viele Änderungen durchgeführt werden müssen.
Datensicherung
Falls das Unternehmen eine Datensicherungslösung für Microsoft 365 einsetzt, so ergeben sich hier einige Besonderheiten, je nach verwendeter Lösung.
Bei Cloud-zu-Cloud-Lösungen wie AvePoint Cloud Backup for Microsoft 365 ist es typischerweise nicht möglich, die gesicherten Daten in eine andere Lösung zu übertragen. Das gilt selbst dann, wenn beide Seiten die gleiche Lösung einsetzen. Bei lokal bereitgestellten Lösungen wie Veeam Backup for Microsoft 365 können Daten eventuell in die Instanz des aufnehmenden/abzutrennenden Unternehmens importiert werden. Dies ist jedoch mit dem Hersteller-Support zu klären.
Bei diesem Thema spielt die Aufbewahrungspflicht eine Rolle:
- Gibt es eine Anforderung, gesicherte Daten weiter aufzubewahren?
- Wird eine separate rechtssichere Aufbewahrung für geschäftliche Daten eingesetzt oder stellt die Datensicherung die rechtssichere Aufbewahrung bereit?
- Kann die rechtssichere Aufbewahrung auch ohne Datensicherung weiter sichergestellt werden?
Je nach Anforderung kann es also erforderlich werden, die bisherige Datensicherungslösung für den Zeitraum der Aufbewahrungspflicht beizubehalten, wenn die Daten nicht in geeigneter Form in eine neue Lösung übertragen werden können.
Dies kann entsprechend zusätzliche Kosten für die weitere Lizenzierung der Lösung nach sich ziehen. Des Weiteren muss die Lösung auch nach der Migration weiterhin regelmäßig auf ihre Funktionsfähigkeit getestet werden. Hierfür muss ggf. auch die Altumgebung eines integrierten Unternehmens weiterbetrieben werden, falls sich die Lösung nicht auf einen anderen Mandanten schwenken lässt.
Organisation
Neben den ganzen technischen Aspekten gibt es auch organisatorische Aspekte, die im Rahmen einer Migration betrachtet werden müssen. Diese werden in der Folge näher erläutert.
Lizenzierung
Die aktuell für die Mitarbeitenden des betroffenen Unternehmens bereitgestellten Microsoft 365-Abonnements werden nach der Migration im Ausgangs-Mandanten (größtenteils) nicht mehr benötigt.
Damit diese nach der Migration keine unnötigen Kosten mehr verursachen, ist zu prüfen, wann die Abonnements jeweils ablaufen. Des Weiteren ist zu prüfen, welche Abonnements auch in der Zielumgebung weiterhin benötigt werden. Dies betrifft vor allem Produkte, die nicht in den Standardpaketen wie Microsoft 365 E3-E7 enthalten sind, beispielsweise Visio, Project und ggf. Copilot.
Aus diesen Erkenntnissen kann dann abgeleitet werden, wie mit den Abonnements jeweils verfahren wird:
- Automatische Verlängerung beenden
- Jahres-Abonnements durch Monats-Abonnements ersetzen, die dann zeitnah nach der Migration gekündigt werden können
- Weiterhin benötigte Lizenzen prüfen und nach Möglichkeit gegen kostengünstigere Abonnements tauschen (bspw. Microsoft 365 Business Basic statt E3)
Auch kann so der tatsächliche Bedarf für die Zielumgebung ermittelt werden.
Verträge
Ein Unternehmen sammelt mit der Zeit eine Vielzahl an Verträgen an, beispielsweise für Software-Abonnements, Hardwarebereitstellung, usw.
Im Rahmen einer Integration ist daher zu prüfen, welche dieser Verträge gekündigt werden können, da sie durch Verträge des aufnehmenden Unternehmens ersetzt werden können. Bei einer Ausgliederung ist hingegen zu prüfen, welche Verträge das auszugliedernde Unternehmen benötigt, um seine Infrastruktur nutzen und betreiben zu können. Eventuell lassen sich auch Synergieeffekte der Verträge des abgebenden Unternehmens nutzen (bspw. Preisnachlässe, Mengenrabatte oder andere besondere Konditionen).
Bewertung der exportierten Daten
Das Migrationsteam kann im Normalfall nur teilweise bewerten, welche Ressourcen weiterhin benötigt werden. Dementsprechend muss spätestens zu diesem Zeitpunkt das existierende Betriebsteam involviert werden. Dieses hat die Aufgabe, die exportierten Daten zu bewerten, um folgende Fragestellungen zu klären:
- Welche Ressourcen werden weiterhin benötigt?
- Falls Ressourcen nicht durch das Migrationsteam vorbereitet/übertragen werden können: wer kümmert sich um die dafür notwendigen Schritte?
- Welche Ressourcen werden nicht mehr benötigt und können bereinigt werden?
Bei der Bereinigung sind Vorgaben hinsichtlich der rechtssicheren Aufbewahrung geschäftlicher Daten zu berücksichtigen. Ansonsten kann eine Bereinigung vor der Migration dazu beitragen, Lizenzierungskosten für die Migrationslösung einzusparen.
Ableitung von Maßnahmen für Vorbereitung und Durchführung
Auf Basis der Ergebnisse der Analyse sind die notwendigen Maßnahmen abzuleiten, die für die Vorbereitung und Durchführung der Migration getroffen werden müssen. Welche Maßnahmen dies im Detail sein können, wird im nächsten Teil der Serie behandelt.
Hat Dir dieser Artikel gefallen? Lass es andere wissen!
