Geglückte Tenant Migration in Office 365

Geglückte Tenant Migration in Office 365 durchgeführt

Wir durften einen Kunden bei einer «Firmenfusion/Übernahme» begleiten. Zwei bisher organisatorisch und technisch voneinander getrennte Unternehmen mussten dabei «technisch» zu einer neuen Firma «fusioniert» werden (tenant to tenant migration). Die bestehenden Mail-Adressen/Mail Domänen sollten im Nachgang aber weiter genutzt werden können.

Vom Kunden haben wir folgende Grundsatz-Anforderungen erhalten:

• Zwei bestehende Office 365 Tenants sollen auf einen neuen Office 365 Tenant migriert werden.
• In einem bestehenden, lokalen Active Directory mit AD Connect (mit folgenden Objekten: Benutzer, Kontakte, Gruppen, Shared- und Equipment-Mailboxen) soll auch nach der Umstellung auf den neuen Office 365 Tenant die Möglichkeit bestehen, diese Objekte im AD zu verwalten.
• Komplette Umstellung aller Mails (Exchange Online) sowie OneDrive Daten an einem vordefinierten Wochenende.
• OneDrive Freigaben zu externen Mitarbeitern/Lieferanten mussten automatisch übernommen werden, sodass diese nichts von der Umstellung merkten, resp. nicht dadurch beeinträchtigt wurden.
• Die Benutzer sollten nach dem Migrations-Wochenende selbst in der Lage sein, Ihre lokalen Mail-Client Profile sowie OneDrive Ordner in Betrieb zu nehmen, respektive umzustellen.
• Signierte und/oder verschlüsselte Emails mussten auf dem Ziel-Tenant von den entsprechenden Benutzern gelesen oder bearbeitet werden können.
• Microsofts Multi-Faktor-Authentifizierung (MFA) muss auf Quell- und Ziel-Tenants aktiviert sein.

Folgende Microsoft Restriktion galt es zu beachten, bevor mit der Planung begonnen werden konnte:

• Es können maximal 300 MB Maildaten pro Benutzer pro Stunde migriert werden (der von uns effektiv gemessene durchschnittliche Migrations-Performance entsprach 260MB/h).
• Es können pro Migrations-Account maximal 100 Benutzer gleichzeitig migriert werden.

Um die gewünschten Anforderungen des Kunden, unter Berücksichtigung der erwähnten Restriktionen umzusetzen, wurde folgendes Vorgehen für die Migration gewählt:

• Erstellung sämtlicher Objekte im Ziel-Tenant als reine Cloud-Objekte, damit eine Vorab-Migration von Mail-Daten überhaupt möglich gemacht werden konnte.
• Erstellung der Objekte als lokale AD-Objekte (Import in lokale AD)
• Vorab-Migration der Maildaten älter als sechs Monate, zwei Wochen vor dem Wochenende der Umstellung.
• Trennung der Benutzer in verschiedene Migrations-Batches (separate Migrationsprojekte mit eigenen Konnektoren und eigenen Admin-Accounts). Die zu migrierenden Benutzer wurden dann gleichmässig über die verschiedenen Batches verteilt.
• Um die Anforderung abzudecken, dass die Benutzer selbst die Umstellung Ihrer Applikationen vornehmen können, wurde in der Vorbereitungs-Phase entsprechende Anleitungen für MFA, Mac- und Windows-Benutzer geschrieben und dem Kunden zur Verfügung gestellt.
• Umschaltung der AD Connect Synchronisation auf den neuen Office 365 Tenant am Migrations-Wochenende.
• Automatische Übernahme der OneDrive Freigaben durch das Migrations-Tool.
• Umschaltung DNS Records am Wochenende, Einrichten von Backup Queues bei der Cut-Over Migration (man weiss ja nie)

Um die Kundenanforderung möglichst effizient umsetzen zu können, haben wir uns dazu entschieden mit einer Migrationssoftware zu arbeiten, welche die Migration von signierten und verschlüsselten Mails unterstützt. Vorsicht bei der Wahl der Migrationstools, die Liste der «not supported» Objekte kann ziemlich lang sein, daher gut prüfen was migriert werden soll und ob das Tool dies kann.

Dank der Vorab-Migration der Maildaten welche älter als 6 Monate waren, konnten wir die Migration über das Migrations-Wochenende erfolgreich abschliessen 😊

WICHTIG: Bereits im Voraus migrierte Mailobjekte werden übrigens als «migriert» gekennzeichnet, sodass sie bei einem erneuten Migrations-Lauf nicht erneut übertragen werden müssen.

Dabei entstehen implizit folgende Nachteile:

• Bereits migrierte Mailobjekte werden von der Migrations-Software als migriert gekennzeichnet und am Zielort nicht mehr verändert, oder nachsynchronisiert.
• Wenn also ein Benutzer zwischen den Migrations-Läufen sich dazu entscheidet, bereits migrierte Maildaten zu verändern, zu verschieben oder gar zu löschen, werden diese Änderungen nicht auf dem Ziel-Tenant nachgezogen.
• Verändert ein Benutzer beispielsweise den Namen eines Ordners in seiner Inbox, so wird dieser als neues Objekt gewertet. Nach einem erneuten Migrationslauf wird dieser Ordner am Zielort neu erstellt, der alte bleibt ebenfalls bestehen – sprich doppelt gemoppelt.

Grundsätzlich empfehlen wir nach Möglichkeit zu einer Migrations-Art, bei welcher nur ein Migrations-Lauf stattfindet, sofern es die Grösse und Komplexität des Unternehmens natürlich zulassen.

Gründe:

• Weniger Risiko, dass Benutzer in der Zeit zwischen den Migrations-Läufen Daten auf dem Quell-Tenant verändern und diese Änderungen am Ziel-Tenant dann leider erneut gemacht werden müssen.
• Der Kunde kann auf dem Ziel Tenant sofort weiterarbeiten. Die Daten werden nach und nach migriert.

Um einen möglichst fliessenden Übergang auf den neuen Tenant sicherzustellen und allfällige Probleme rasch zu beheben, empfiehlt es sich nach der Migration genügend Personal vor Ort zu haben, in unserem Falle zwei Kollegen, die den Helpdesk bei Problemen zur Seite standen. Das Gros der Benutzer konnte bereits um 10 Uhr morgens auf der neuen Plattform problemlos weiterarbeiten.

Fazit

Ein interessantes Migrations-Szenario, welches wir in Zukunft sicher öfters antreffen werden, da die Anzahl der Office 365 migrierten Firmen stetig zunimmt 😉