Microsoft-Tenant Migration

6 Tipps für eine reibungslose Microsoft-Tenant-Migration

Wenn sich die Unternehmensstruktur verändert – sei es durch M&A, durch Fusionen oder durch Carve-outs –, wirkt sich das auch auf die Cloud- & IT-Infrastruktur aus. Systeme und Daten müssen konsolidiert oder getrennt werden, neue Anwendungen werden eingeführt, Legacy-Systeme abgeschaltet. Die nötige Migration ist allerdings oft mit Aufwand und Risiken verbunden – besonders wenn man die Anforderung „im laufenden Betrieb“ vor Augen hat. Für den Fall, dass Sie die Cloud-Plattform von Microsoft nutzen und Azure Tenants migrieren müssen, finden Sie hier sechs Tipps, wie Sie dies erfolgreich angehen können:

1. Klären Sie alle Verantwortlichkeiten vorab

Noch bevor die eigentliche Migration startet, sollten Sie im Team mit allen Beteiligten abklären, wer für was zuständig ist. Das klingt vielleicht banal, wird in der Praxis aber leider häufig nur teilweise oder sogar gar nicht gemacht. Die Folge: Während der Migration kommt es zu Verzögerungen, weil erst jetzt die Zuständigkeiten geklärt werden. Im schlimmsten Fall stellen Sie erst in diesem Moment fest, dass Ihnen wichtige Kompetenzen im Team fehlen. Wir empfehlen Ihnen daher, ein Migrationskonzept zu erstellen, in dem Sie die Rollen und Verantwortlichkeiten festhalten.

Fragen, die Ihnen bei der Erstellung des Migrationskonzepts helfen können, sind:

  • Wer ist für die gesamte Migration hauptverantwortlich?
  • Welche Teams sind jeweils für die betroffenen Microsoft-Tenants verantwortlich und wer ist pro Team Hauptansprechpartner:in?
  • Wer trifft Entscheidungen über die Zielumgebung, z. B. bei unterschiedlichen Sicherheitskonfigurationen oder -konzepten der betroffenen Tenants?
  • Welche weiteren Rollen müssen besetzt sein, z. B. für das Projektmanagement, verantwortliche Personen für die Kommunikation, die Rechtsabteilung, der IT-Support, zusätzliche Entwickler:innen für (Teil-)Automatisierungen etc.
  • Wo muss ggf. der Cloud-Anbieter hinzugezogen werden? Wer übernimmt dies?
  • Wer informiert weitere Stakeholder wie z. B. Compliance- und Datenschutzbeauftragte, Betriebsrat, Fachabteilungen und nicht zuletzt die Anwender:innen?

2. Machen Sie sich den Migrationsumfang klar

Was soll konkret migriert werden? Muss ein gesamter Tenant in einen anderen umziehen oder nur bestimmte Inhalte und Daten? Letzteres kann den Migrationsaufwand erheblich reduzieren. Setzen Sie sich mit allen Projektbeteiligten an einen Tisch.

Überlegen Sie gemeinsam:

  • Welche Subscriptions (Abonnements) & Azure-Ressourcen müssen zwingend umgezogen werden?
  • Welche sind z. B. aus Archivierungsgründen wichtig, aber nicht ständig in Gebrauch und können in einer zweiten Migrationsphase umgezogen werden?
  • Welche Produkte, Ressourcen oder Umgebungen können ganz eingestellt werden und sind daher nicht relevant für die Migration? Dies könnten z. B. Entwicklungs- oder Testumgebungen sein oder Software-Produkte, die im anderen Tenant bereits existieren und keine Dopplung benötigen.
  • Was passiert mit den „Altlasten“? Müssen sie archiviert oder EU-DSGVO-konform gelöscht werden?
Blog

Expert-Talk: „Moderne IT-Infrastruktur ist wie eine Säge: Sie braucht regelmäßiges Nachschärfen“

Die Modernisierung der IT-Landschaft stellt viele Unternehmen vor eine große Herausforderung – und findet im Tagesgeschäft oft kaum Raum. Dr. Jan Ciupka hat in seiner […]

3. Bedenken Sie versteckte Abhängigkeiten

Wenn Sie wissen, welche Inhalte migriert werden sollen, schauen Sie sich als Nächstes deren Abhängigkeiten zu anderen Inhalten an. So überprüfen Sie auch, ob nicht doch Inhalte migriert werden müssen, die Sie bereits aussortiert haben.

Fragen Sie sich daher:

  • Was muss abseits von Subscriptions inkl. derer Ressourcen (z. B.: virtuelle Maschinen oder Speicherkonten) umgezogen werden?
  • Müssen gegebenenfalls neue Subscriptions angelegt werden? Wenn ja, für welche Inhalte?
  • Welche (externen) Abhängigkeiten müssen angepasst werden? Dazu gehören beispielsweise App-Registrierungen, Azure DevOps-Organisationen und Azure Policies. Wer übernimmt in dem Fall die Neuanlage?
  • Wer darf solche Neuanlagen in der Zielumgebung durchführen? Muss dies über einen zentralen Prozess geschehen oder haben Subscription-Verantwortliche (teilweise) selbst ausreichend Rechte dafür?
  • Wo müssen die neu angelegten Abhängigkeiten überall nachgepflegt werden? Hier kann es z. B. Anpassungsbedarf im Quellcode oder dessen Konfigurationen geben. Auch automatisierte Prozesse wie Infrastructure as Code oder CI/CD Pipelines müssen eventuell aktualisiert werden.
  • Welche Prozesse und Dienste hängen von den migrierten Subscriptions und Azure-Ressourcen ab? Kommt es hier zu relevanten Service-Unterbrechungen oder -Einschränkungen? Gibt es nach der Migration weiteren Konfigurationsbedarf, z. B. wegen der Änderung der Tenant-ID oder weil andere Konten genutzt werden?
  • Gibt es Prozesse, die Daten oder Objekte in den Tenant hinein synchronisieren? Sollen diese Prozesse nach der Migration in den neuen Ziel-Tenant synchronisieren oder sind sie nach der Migration überflüssig?
  • Welche Ressourcen haben untereinander Abhängigkeiten und müssen zusammen migriert werden?

4. Berücksichtigen Sie technische Einschränkungen

Nicht alle Ressourcentypen in Azure können ohne Weiteres migriert werden, da dies technisch nicht vorgesehen ist bzw. unterstützt wird. Hierunter fallen z. B. Microsoft Entra Domain Services und der Azure Kubernetes Service, bei denen das Verschieben zwischen zwei Tenants überhaupt nicht unterstützt wird. Bei vielen weiteren Ressourcentypen ist die Migration zwar möglich, aber mit diversen Einschränkungen oder Nacharbeiten verbunden. Die Neuanlage oder Umkonfiguration von solchen Ressourcen kann den Betrieb beeinflussen und muss entsprechend vorbereitet werden, um den Aufwand gering zu halten.

Überlegen Sie vor der Migration:

  • Welche Ressourcentypen kommen im Migrationsumfang überhaupt vor? Beachten Sie, dass manche Ressourcen von Azure automatisch angelegt werden und standardmäßig versteckt sind.
  • Bei welchen Ressourcentypen gibt es Einschränkungen und wie viele dieser Ressourcen müssen umgezogen werden? Zum Beispiel können bestimmte Konfigurationen der Ressourcen dazu führen, dass diese gar nicht oder nur mit großem Aufwand migrierbar sind.
  • Können ggf. existierende Einschränkungen durch Einbeziehung des Cloudanbieters gelockert werden bzw. kann dieser die Migration auf Nachfrage ermöglichen?
  • Welcher Aufwand ist mit einer Neuanlage verbunden?
  • In welchen Fällen muss dieser Aufwand zwingend sofort aufgebracht werden?
  • Wo können Sie die Neuanlage auf einen späteren Zeitpunkt terminieren?
Insight

Zero Trust – Resiliente IT in Zeiten von Cloud und mobilem Arbeiten

Würden Sie sich einen Picasso ins Haus hängen und nur Ihre Haustüre abschließen? Diese Situation ist ähnlich zu dem, was viele Unternehmen jeden Tag tun […]

5. Planen Sie die Kommunikation mit den Usern

Sowohl Anwender:innen und technisch Verantwortliche der Azure-Ressourcen und Subscriptions im eigenen Unternehmen als auch Geschäftspartner und ggf. auch Kunden müssen frühzeitig über die Migration und deren Auswirkungen informiert werden.

Folgende Fragen können Ihnen bei der Kommunikation helfen:

  • Wer ist alles von der Migration betroffen? Für wen ergeben sich Änderungen?
  • Wenn Downtimes nicht vermeidbar sind, zu welchen Zeiten sind am wenigsten Anwender:innen davon betroffen?
  • Wie gravierend sind Änderungen, die sich durch die Migration ergeben, z. B. durch Veränderungen in Bezug auf Sicherheitsmaßnahmen?
  • Wie können Sie Nutzer:innen auf diese Anpassungen optimal vorbereiten und ihnen den Übergang erleichtern?
  • Wer ist der/die Hauptansprechpartner:in für Fragen und die Unterstützung der User? Welche Feedback-Kanäle stehen zur Verfügung?

6. Kalkulieren Sie ausreichend Zeit & personelle Ressourcen für die Migration ein

Nichts ist fataler als eine überstürzte Migration. Im schlimmsten Fall können Mitarbeiter:innen und Partner ihren Aufgaben nur teilweise oder gar nicht nachgehen. Das kann ein Unternehmen neben Geld auch das Image kosten. Daher ist es wichtig, vorab einen realistischen Zeitplan zu erstellen. Auch muss sichergestellt sein, dass ausreichende Kapazitäten bei den Verantwortlichen vorhanden sein werden.

Fragen, die Ihnen die Planung der Migration erleichtern, sind:

  • Wie viel Zeit bedarf die technische Vorbereitung, z. B. das Erstellen von Hilfsscripten und Backups?
  • Wie lange dauern Maßnahmen oder Anpassungen in den Tenants, das Einrichten und Durchführen von Testmigrationen für schwierige oder kritische Fälle und wie viel Zeit muss für das Einrichten neuer Abhängigkeiten eingeplant werden?
  • In welchen Phasen und wann genau soll die konkrete Migration stattfinden?
  • Welche weiteren Aufgaben hat das Migrationsteam sonst noch im operativen Alltag?
  • Müssen externe Kapazitäten für die Zeit der Migration hinzugezogen werden?
  • Welche Zeitpuffer für unvorhergesehene Schwierigkeiten planen Sie ein?
  • Welchen Notfallplan gibt es, wenn Teammitglieder unplanmäßig ausfallen, z. B. krankheitsbedingt?

Insgesamt sind für jede Migration immer eine individuelle Planung und ein gründlich durchdachtes Konzept notwendig. Zudem empfiehlt sich nach erfolgter Migration eine Review, in der Sie eruieren, was gut funktioniert hat und wo Sie bei der nächsten Migration Verbesserungspotenzial sehen.

Wenn Sie sich mit dem Thema Migration beschäftigen und einen Sparringspartner für Ihr Vorgehen oder auch Unterstützung bei Konzeption und Durchführung suchen, wenden Sie sich an Manuel Warcholik und seine Kolleg:innen: Hier können Sie Kontakt mit ihnen aufnehmen.