Blog
So bereiten Sie eine Tenant-to-Tenant-Migration optimal vor
Gute Planung ist das A und O
Eine Tenant-to-Tenant-Migration ist eine technische und logistische Großbaustelle. Für Unternehmens-IT, die damit nicht täglich zu tun hat, bedeutet es enormen Arbeitsaufwand und Stress. Auch die sich ergebenden Änderungen für die Nutzer*innen müssen berücksichtigt werden. Ein klarer Fahrplan und Best Practices unserer Expert*innen helfen, sich gut auf eine solche Migration vorzubereiten.
Wann ist eine Tenant-to-Tenant-Migration notwendig?
Bei Zusammenlegungen oder Firmenaufkäufen müssen meist Nutzer*innen, Daten und Geräte zu einem neuen oder bestehenden anderen Tenant migriert werden. Das ermöglicht die Zusammenarbeit der Mitarbeitenden ohne die sonst vorhandenen Grenzen durch IT-Technologien z. B. bei Zugriffen, Rechten oder Datenständen. Auch die Trennung durch den Verkauf von Firmenteilen, mit der umgekehrten Motivation, kann so eine Migration nötig machen.
Was genau wird migriert?
Bei einer Tenant-to-Tenant-Migration ist die gesamte Microsoft 365 Suite relevant und es werden beispielsweise die Konfigurationen und Daten aus Exchange, OneDrive, Teams und SharePoint transferiert. Technisches Ziel der Tenant-to-Tenant-Migration ist es, entweder die User*innen des zu migrierenden Tenants im Ziel-Tenant im Azure Active Directory anzulegen und dort zu synchronisieren oder sie dort als Cloud-Identitäten anzulegen.
Wie bereite ich eine Migration vor?
Um bei der Migration keine Überraschungen zu erleben, müssen im Vorfeld etliche Vorbereitungen getroffen werden:
Ausgangslage analysieren
Zwischen dem alten Tenant und dem Ziel-Tenant bestehen maßgebliche Unterschiede, insbesondere dann, wenn zu einem bereits bestehenden Tenant migriert wird. Hier gilt es unter anderem die User*innen, deren Arbeitsweisen, die Datenarten und -mengen sowie die Security und Compliance Policies miteinander abzugleichen. Nur so können nötige Anpassungen von Anfang an sauber mit eingeplant werden.
Konfigurationen definieren
Security Defaults im Ziel-Tenant müssen angepasst werden, damit sich die User*innen ohne Probleme in die neue Umgebung einloggen können. Angepasst werden müssen zudem die Usersynchronisation, DNS-Namensauflösung und die Sicherheitspolicies. Wenn Unternehmen Migrationstools von Drittherstellern nutzen möchten, was in der Regel nötig ist, müssen diese ebenfalls für den Einsatz konfiguriert werden.
Zugriffsrechte gewähren
Spezifische Projektmitglieder, in der Regel Admins von beiden Seiten, müssen Zugang zu beiden Tenants und den relevanten Systemen (Hybrid Set-up, Netzwerkzugänge) haben, um wichtige Einstellungsanpassungen vorzunehmen. Ihr IT-Dienstleister braucht sowohl für die Ursprungs- als auch für den Ziel-Tenant einen Service Account, sowie Zugriff auf Migrations-Tools.
„Umzugslisten“ erstellen
Eine Liste aller zu migrierenden User*innen und der von ihnen genutzten Services sowie eine User Mapping Table (User@Source -> User@Ziel) müssen erstellt werden. Auch eine Liste der Nutzer*innen, die mit ihrem ursprünglichen Account bereits in den Ziel-Tenant eingeladen wurden, ist notwendig. Darüber hinaus werden eine Liste aller üblichen Empfänger für Exchange Online und eine Liste aller Gast-Accounts im Ursprungs-Tenant benötigt.
Wie plane ich eine Tenant-to-Tenant-Migration?
Design-Phase
In der Design-Phase werden die notwendigen Konfigurationen, Migrationsschritte, das Projekt Setup und der Ablaufplan festgehalten. Der Ursprungs-Tenant wird inventarisiert, im Ziel-Tenant werden notwendige Konfigurationen vorgenommen (s.o.). Finden Sie in dieser Phase Lösungen für Fälle, in denen sich Policies und Begrenzungen in den Tenants unterscheiden. Betreffen diese Anpassungen die Nutzer*innen unmittelbar, muss eine entsprechende Kommunikation vorbereitet werden.
Worauf ist vor der Tenant-to-Tenant-Migration zu achten?
Vorbereitungsphase
Die Vorbereitungsphase ist besonders arbeitsintensiv und mit zahlreichen unterschiedlichen Workloads verbunden. So müssen etwa die existierenden Mailboxes analysiert werden, um die unterschiedlichen Migrationswellen zu definieren. Darauf ist in den einzelnen Workloads zu achten.
Netzwerk
Verwenden beide Seiten Microsoft 365 Cloud Services, erfolgt ein schneller Check der Netzwerk-Infrastruktur, um zu sehen, ob alle Voraussetzungen zur Migration erfüllt sind. Außerdem wird das Network Setup für die Migrations-Tools und die Datenmigration überprüft.
Identity & Security
Nutzer*innen müssen für die Migration dasselbe UPN-Prefix haben, um eine glatte Migration aller Daten, Zugriffe etc. zu ermöglichen. Sicherheitsstandards in beiden Tenants müssen abgeglichen, angepasst und bei Änderungen an die User*innen kommuniziert werden (s.o.).
Windows Clients
Windows Clients sind an die jeweilige Domain im lokalen Azure Active Directory gebunden, was zu Zugriffsproblemen führen kann. Die Clients-Migration muss deshalb in der Design-Phase mitberücksichtigt werden. Grundlegend hat man hier die Entscheidung, die Clients in ihren ursprünglichen On-Premise Active Directories zu lassen. Bei einem Firmensplit wird meist in einem eigenen Teilprojekt auch die Trennung und Migration des On-Premise ADs verfolgt, was aber in diesem Artikel nicht Thema sein soll.
Mobile Clients / MS Intune
Alle Einstellungen des Endpoint Managers (früher Intune) müssen zwischen Ursprungs- und Ziel-Tenant abgeglichen und angepasst werden. Nutzer*innen mobiler Geräte müssen angeleitet werden, wie die Devices in die neue Umgebung überführt werden können, da dies nicht automatisch erfolgen kann. Neben einem vorbereiteten Manual sollte hier der Service Desk auf mögliche Anfragen vorbereitet werden.
Messaging
Für die Migration müssen Policies, die den Durchfluss von Daten beschränken, in beiden Tenants angepasst werden. Dies kann der Global Admin zunächst für eine begrenzte Zeit von 90 Tagen selbst tun. Weitere 90 Tage müssen per Support Ticket beantragt werden. Die Deaktivierung sorgt für eine Transfergeschwindigkeit von bis zu 150MB per fünf Minuten und Mailbox. In jedem Tenant sollte es einen Service-Account geben, der mindestens Exchange Administrator-Rechte in der Ursprungs- und Zielumgebung sowie Exchange Application Impersonation-Rechte in der Zielumgebung besitzt.
OneDrive for Business
Für die Migration mit einem Dritthersteller-Tool muss ein Global Admin der Applikation Rechte für den Ursprungs- und Ziel-Tenant gewähren. Um die Rechte entsprechend den Usern zu migrieren, ist es auch hier entscheidend, dass das UPN-Prefix in Ursprungs- und Ziel-Tenant gleich ist.
Microsoft Teams
Durch die API-Limitierungen für Teams ist die Migration von Teams in einen neuen Tenant nach wie vor komplex. Mit Migrationstools können die Daten transferiert werden. Auch wenn eine stufenweise Migration theoretisch möglich ist, empfehlen die Skaylink-Expert*innen, ein Team in einem einzigen Durchlauf zu migrieren. Gäste in Teams werden durch die fehlenden APIs nicht migriert. Sie können script-based transferiert werden, allerdings müssen die Gäste einen neuen Registrierungsprozess durchlaufen.
Change & Adoption Management
Wenn sich Quell- und Zielumgebung deutlich unterscheiden, ist es essenziell die Mitarbeitenden durch Change & Adoption-Maßnahmen abzuholen. Dabei ist es wichtig auch den kulturellen Wandel und andere Arbeitsweisen zu bedenken. Wie arbeiten die Kolleg*innen im Team? Wann ist es z. B. üblich eine E-Mail zu schreiben oder den Chat zu nutzen? In der Praxis haben sich hierzu Kurzguides, szenario-basierte Schulungen und Champions-Programme bewährt, um Kolleg*innen bei einem Wandel zu unterstützen. Hierbei erhält man die Chance, nicht nur die Technologien zu migrieren, sondern auch die Produktivität und Zusammenarbeit der nun neuen Kolleg*innen zu fördern.
Ein anderes Beispiel für Umstellungen von gewohnten Arbeitsweisen sind striktere Sicherheitsrichtlinien, die z. B. bei externen Zugriffen immer eine Multi-Faktor-Authentifizierung erfordern. Auch diese Änderung gilt es proaktiv zu kommunizieren, um Mitarbeitende rechtzeitig einzubinden.
Wie läuft eine Tenant-to-Tenant-Migration ab?
In Projekten hat sich die Staged Data Migration als besonders angenehm und effizient erwiesen. Daten werden dabei Schritt für Schritt im Hintergrund migriert, was auch große Datenmengen handhabbar macht, ohne dass es für Nutzer*innen merkbare Veränderungen gibt. Je nach User-Zahl und Datenumfang dauert diese Migration ein bis drei Monate. Nach der Datenmigration im Hintergrund sollten Test- und Pilot-Migrationen durchgeführt werden. So kann die Qualität der Migration überprüft und können mögliche Probleme behoben werden. Im letzten Schritt der Migrationsphase, der je nach Planung circa eine Woche in Anspruch nimmt, werden die letzten Daten transferiert und alle nötigen Konfigurationen, um die Nutzer*innen in die neue Umgebung zu holen, abgeschlossen.
Welche Migrations-Tools sind zu empfehlen?
Einige Microsoft-eigene Tools erleichtern und unterstützen die Tenant-to-Tenant-Migration. Generell leisten hier aber die Tools von Drittanbietern bessere Dienste. Vor allem die Kombination aus BitTitan MigrationWiz und ShareGate Desktop hat sich in der Praxis als sehr effektiv erwiesen, da sich mit ihnen Exchange Online, SharePoint Online, OneDrive for Business und Microsoft Teams migrieren lassen. ShareGate Desktop hat sich vor allem für Teams und Sharepoint bewährt, weshalb es als Ergänzung zu BitTitan MigrationWiz sinnvoll ist. Beide Tools sind GDPR-konform (General Data Protection Regulation). Die Skaylink-Expert*innen ergänzen das Angebot für Tenant-zu-Tenant-Migrationen durch diverse Eigenentwicklungen und Skripte, um eine höhere Automatisierungsrate und Qualität zu erzielen.
Read before you start – Was Sie bei einer Tenant-to-Tenant-Migration unbedingt beachten sollten!
Security-Abstimmung
Da sensible Zugriffe auf Tools und Daten erfolgen, ist eine enge Abstimmung mit dem Cyber Security-Team von Anfang an unerlässlich.
Notwendige Doppellizenzierung
Für den Zeitraum der Migration müssen Nutzer*innen doppelt lizenziert sein – im Ursprungs- und im Ziel-Tenant – damit die Daten migriert werden können! Wenn Sie ein Enterprise Agreement haben, lässt sich mit Microsoft meist aushandeln, die doppelt benötigten Lizenzen für den Migrationszeitraum kostenlos zu bekommen. Alternativ könnten Sie über das Microsoft CSP-Modell Lizenzen nur für den wirklich benötigten Zeitraum erwerben und so die Kosten steuern.
Hybrides Projektmanagement
Für eine Tenant-to-Tenant-Migration müssen viele interne und externe Projektmitglieder koordiniert werden. Es müssen mindestens acht verschiedene technische Workloads zusammenspielen, damit die Migration glatt und störungsfrei für die Endnutzer*innen abläuft. Cloud-Umgebungen und mögliche Änderungen in der Microsoft 365 Suite erlauben in der Regel kein klassisches Waterfall-Projektmanagement: Je nach Zeitrahmen kann es nötig sein, in der Vorbereitungs- oder Migrationsphase nochmal Designänderungen vorzunehmen. Bei Skaylink hat sich hier ein hybrides Projektmanagement bewährt.
Fazit
Eine Tenant-to-Tenant-Migration ist nichts, was neben den üblichen Alltagsaufgaben bewältigt werden kann. Sie braucht Erfahrung, Vorbereitung und Planung. Trotzdem sollte damit nicht zu lange gewartet werden, sonst etablieren sich schnell fehleranfällige Workarounds, Policies werden nicht einheitlich umgesetzt und die Sicherheit und Effizienz im Unternehmen leiden nachhaltig. Oft gibt es bei Firmenverkäufen auch strikte Zeitvorgaben. Erfahrene IT-Dienstleister, die Sie mit Expertise und Fachkräften unterstützen, sind deshalb in der Regel die beste Option, eine Migration erfolgreich und zügig umzusetzen. Fragen Sie uns gern nach unseren Angeboten dazu!