Entra-ID-Migrationsstrategie: Identitäten zusammenführen ohne Nutzerstörung

Identität ist die Steuerungsebene jedes modernen Unternehmens. Wenn zwei Organisationen fusionieren, ist die Identitätsschicht die erste Abhängigkeit und das Letzte, was schiefgehen darf. Eine misslungene Entra-ID-Migration sperrt Mitarbeitende aus ihren Werkzeugen aus, bricht Anwendungsintegrationen und untergräbt das Vertrauen in das gesamte Transformationsprogramm.

Dieser Leitfaden behandelt Strategie, Sequenzierung und technische Details für eine reibungslose Zusammenführung von Entra-ID-Tenants. Er basiert auf der Erfahrung von CC Conceptualise bei der Konsolidierung von Identitätsumgebungen europäischer Unternehmen.

Warum Identitätsmigration der kritische Pfad ist

Jede Workload-Migration hängt von der Identität ab: Postfach-Umzüge benötigen Ziel-UPNs, SharePoint-Berechtigungen benötigen Ziel-Gruppen, SaaS-Apps benötigen Ziel-SAML-Assertions. Wenn Identität nicht zuerst gelöst ist, stockt alles Nachgelagerte.

Gleichzeitig ist die Identitätsmigration die für Nutzer sichtbarste Veränderung. Wenn sich der Login eines Mitarbeiters ändert, bricht die Routine. Passwort-Abfragen tauchen unerwartet auf. MFA-Challenges feuern auf vertrauten Geräten. Das Ziel ist, diesen Übergang so unsichtbar wie möglich zu gestalten.

Leitprinzip: Nutzer sollten am Migrationstag aufwachen, sich wie gewohnt anmelden und feststellen, dass alles funktioniert. Alles andere ist ein Planungsfehler.

Schritt 1: Identitätslandschaft kartieren

Bevor Sie einen Migrationsansatz wählen, erstellen Sie ein vollständiges Bild beider Umgebungen.

Was inventarisiert werden muss

Benutzerobjekte: Anzahl, UPN-Format, benutzerdefinierte Attribute, Erweiterungsattribute, die von nachgelagerten Anwendungen verwendet werden
Gruppen: Sicherheitsgruppen, Microsoft-365-Gruppen, Verteilerlisten, dynamische Gruppen. Verschachtelungstiefe beachten
Service Principals und App-Registrierungen: Diese werden am häufigsten übersehen und sind am fragilsten. Dokumentieren Sie für jede App die Berechtigungen, Redirect-URIs und Zertifikat-/Secret-Ablaufdaten
Conditional-Access-Richtlinien: Als JSON aus beiden Tenants exportieren. Nebeneinander vergleichen — Richtliniennamen stimmen selten überein, aber die Logik überschneidet sich oft
Authentifizierungsmethoden: Welche MFA-Methoden sind pro Nutzer registriert? Authenticator-App, FIDO2-Schlüssel, Telefonnummern, Software-OATH-Token
Privilegierte Rollen: PIM-Zuweisungen, stehende Admin-Konten, Break-Glass-Konten
Hybrid-Identity-Komponenten: Azure AD Connect oder Cloud Sync Konfiguration, Sync-Regeln, Filterung, Password Hash Sync vs. Pass-Through Authentication vs. Federation

Konflikte identifizieren

Die häufigsten Konflikte:

UPN-Kollisionen: Zwei Nutzer mit demselben UPN-Suffix aber unterschiedlichen Identitäten (z. B. beide Organisationen haben mmueller@firma.de)
ProxyAddress-Konflikte: Überlappende SMTP-Adressen blockieren die Postfach-Migration
Gruppennamen-Kollisionen: Zwei Gruppen namens „IT-Alle" mit unterschiedlichen Mitgliedschaften
Doppelte Gastkonten: Nutzer, die vor der Fusion bereits B2B-Gäste im jeweils anderen Tenant waren

Dokumentieren Sie jeden Konflikt. Eine nachträgliche Behebung nach der Migration ist zehnmal aufwändiger als eine vorherige Klärung.

Schritt 2: Migrationsmuster wählen

Option A: Cross-Tenant-Synchronisation + B2B-Zusammenarbeit

Einsatz wenn: Sie eine verlängerte Koexistenzphase benötigen (3–12 Monate), beide Tenants betriebsbereit bleiben müssen oder der Ziel-Tenant noch nicht für die vollständige Migration bereit ist.

Funktionsweise:

Entra-ID-Cross-Tenant-Sync projiziert Nutzer aus dem Quell-Tenant als B2B-Member-Accounts in den Ziel-Tenant
Nutzer behalten ihre Quell-Anmeldedaten, können aber auf Ressourcen des Ziel-Tenants zugreifen
Workloads (Mail, SharePoint, Teams) werden schrittweise migriert, die Identität wird zuletzt umgestellt

Vorteile: Geringe Störung, reversibel, ermöglicht phasenweise Migration. Nachteile: Zwei Tenants zu verwalten, B2B-Konten haben einige Funktionseinschränkungen (z. B. bestimmte Teams-Calling-Features, einige Power-Platform-Funktionen).

Option B: Vollständige Tenant-zu-Tenant-Identitätsmigration

Einsatz wenn: Ein klarer Schnitt machbar ist (kleine Nutzerpopulation oder kurzes Koexistenzfenster) oder der Quell-Tenant schnell stillgelegt wird.

Funktionsweise:

Ein Migrationstool (Microsoft nativ, Quest, Binary Tree) verschiebt Benutzerobjekte, Gruppen und Attribute vom Quell- in den Ziel-Tenant
Nutzer werden im Ziel-Tenant mit neuen Anmeldedaten neu provisioniert
Workloads werden gleichzeitig oder unmittelbar danach migriert

Vorteile: Sauberer Endzustand, nur ein Tenant zu verwalten. Nachteile: Höhere Störung, erfordert sorgfältige Credential- und MFA-Planung, schwerer rückgängig zu machen.

Unsere Empfehlung

Für die meisten Unternehmensfusionen empfehlen wir, mit Option A (Cross-Tenant-Sync) für sofortige Zusammenarbeit zu starten und dann Option B als letzten Schritt durchzuführen, sobald alle Workloads migriert sind. Dieser hybride Ansatz bietet die beste Balance aus Geschwindigkeit und Sicherheit.

Schritt 3: Conditional Access harmonisieren

Zwei Organisationen haben nahezu sicher unterschiedliche Conditional-Access-Richtlinien. Bevor Nutzer zwischen Tenants wechseln, benötigen Sie ein einheitliches Richtlinienset — andernfalls treffen migrierte Nutzer auf unerwartete Blockaden oder, schlimmer noch, auf schwächere Sicherheit als beabsichtigt.

Harmonisierungsprozess

Alle Richtlinien exportieren aus beiden Tenants als JSON (via Graph API oder Entra-Portal)
Vergleichsmatrix erstellen: Jede Quell-Richtlinie ihrer Ziel-Entsprechung zuordnen, basierend auf der Intention (z. B. „MFA für alle Nutzer erforderlich", „Legacy-Authentifizierung blockieren", „Konformes Gerät für Office 365 erforderlich")
Die strengere Richtlinie übernehmen bei Konflikten. Es ist einfacher, eine Richtlinie nach der Migration zu lockern als zu verschärfen
Im Report-Only-Modus testen vor der Erzwingung. Die harmonisierten Richtlinien mindestens zwei Wochen im Ziel-Tenant als Report-Only deployen und Anmeldeprotokolle auf unerwartete Blockaden prüfen
Named Locations und vertrauenswürdige IPs adressieren: Beide Tenants haben wahrscheinlich unterschiedliche Büro-IP-Bereiche konfiguriert. Führen Sie diese vor der Migration in den Named Locations des Ziel-Tenants zusammen

Richtlinien, die häufig überraschen

Device-Compliance-Anforderungen: Wenn der Ziel-Tenant Intune-registrierte Geräte verlangt und der Quell-Tenant nicht, werden am ersten Tag alle Quell-Nutzer blockiert — es sei denn, Sie registrieren ihre Geräte vorab
App-Protection-Policies: Mobile Apps der Quell-Nutzer (Outlook, Teams) müssen sich möglicherweise erneut bei Intune App Protection im Ziel-Tenant registrieren
Session Controls: Wenn der Ziel-Tenant eine Anmeldefrequenz von 1 Stunde verlangt, der Quell-Tenant aber 24 Stunden nutzte, sehen Nutzer mehr Prompts als erwartet

Schritt 4: MFA-Neuregistrierung planen

MFA-Anmeldedaten sind tenant-gebunden. Wenn ein Nutzer von Tenant A nach Tenant B wechselt, folgen Authenticator-App-Registrierungen, FIDO2-Schlüssel und Telefonnummern nicht automatisch.

Optionen für die MFA-Migration

Ansatz	Nutzererfahrung	Aufwand
Temporary Access Pass (TAP)	Nutzer erhält einen Einmalcode zur Anmeldung und MFA-Neuregistrierung im Ziel-Tenant	Mittel — erfordert Koordination und Helpdesk-Kapazität
FIDO2-Schlüssel-Neuregistrierung	Nutzer registriert seinen vorhandenen Hardware-Schlüssel im Ziel-Tenant	Gering pro Nutzer, muss aber individuell durchgeführt werden
Telefonnummer-Vorpopulation	Telefonnummern im Ziel-Tenant vorab eintragen; Nutzer schließt Verifizierung bei erster Anmeldung ab	Geringe Störung, aber telefonbasierte MFA ist weniger sicher
Gestufter Rollout	MFA in Wellen migrieren, mit verfügbarem Helpdesk während jeder Welle	Höchste Erfolgsquote bei großen Populationen

Best Practice

Frühzeitig kommunizieren. Informieren Sie Nutzer zwei Wochen vor der Migration, dass sie MFA neu registrieren müssen. Stellen Sie Schritt-für-Schritt-Anleitungen mit Screenshots bereit
Temporary Access Passes verwenden für die erste Anmeldung am Ziel-Tenant. TAPs sind zeitlich begrenzte Einmalcodes, die Nutzern die Authentifizierung und Registrierung neuer MFA-Methoden ermöglichen
Walk-in-Support anbieten während der Migrationswellen. Einige Nutzer (besonders solche mit FIDO2-Schlüsseln oder Hardware-Token) benötigen persönliche Hilfe
Authentifizierungsfehler in Echtzeit überwachen während der Migration. Richten Sie Alerts in Entra ID für fehlgeschlagene MFA-Challenges migrierter Nutzer ein

Schritt 5: Zeitplan erstellen

Ein realistischer Zeitplan für die Identitätsmigration eines mittelständischen Unternehmens (500–5.000 Nutzer):

Phase	Dauer	Kernaktivitäten
Bestandsaufnahme und Planung	3–4 Wochen	Inventar, Konfliktlösung, Richtlinienvergleich
Cross-Tenant-Sync-Deployment	2–3 Wochen	Sync konfigurieren, B2B-Zugriff testen, Conditional Access validieren
Koexistenz und Workload-Migration	8–16 Wochen	Mail-, SharePoint-, Teams-Migration in Wellen
Identity Cutover	2–4 Wochen	Identitäten migrieren, MFA neu registrieren, Quell-Tenant-Sync stilllegen
Hypercare	2–4 Wochen	Authentifizierung überwachen, Sonderfälle lösen, Aufräumarbeiten

Gesamt: 4–7 Monate für ein gut geplantes Programm. Rechnen Sie zusätzliche Zeit für größere Populationen oder komplexe Hybrid-Umgebungen ein.

Abhängigkeiten auf dem kritischen Pfad

Cross-Tenant-Sync muss live sein, bevor die Workload-Migration beginnt
Conditional-Access-Harmonisierung muss vor dem Identity Cutover abgeschlossen sein
MFA-Neuregistrierung muss mit einer Pilotgruppe getestet werden, bevor der vollständige Rollout startet
Break-Glass-Konten müssen im Ziel-Tenant konfiguriert sein, bevor Admin-Konten migriert werden

Typische Anti-Patterns

Identität zuletzt migrieren: Das erzeugt monatelange B2B-Workarounds und verwirrt Nutzer. Starten Sie die Identitätsarbeit in Woche eins
Service Principals ignorieren: Eine Legacy-LOB-App mit hartcodierter Client-ID und Secret bricht, wenn ihr Service Principal verschoben wird. Testen Sie jede Anwendungsintegration
Den Piloten überspringen: Migrieren Sie immer eine kleine Pilotgruppe (20–50 Nutzer) zwei Wochen vor den Hauptwellen. Der Pilot deckt Sonderfälle auf, die Dokumentation übersieht
Annehmen, dass Entra ID Connect „einfach funktioniert": Wenn beide Organisationen Hybrid Identity nutzen, müssen Sie den Sync-Cutover sorgfältig planen — zwei Connect-Instanzen, die auf denselben Tenant zeigen, führen unweigerlich zu Attributkonflikten

Wie CC Conceptualise unterstützt

Wir sind spezialisiert auf Entra-ID-Migrationen, die Nutzer nicht bemerken. Unsere Berater übernehmen die technische Umsetzung — Cross-Tenant-Sync, Conditional-Access-Harmonisierung, MFA-Migration — und managen gleichzeitig die Kommunikations- und Support-Logistik, die darüber entscheidet, ob Nutzer eine gute Erfahrung machen.

Kontaktieren Sie uns, um Ihr Identitätskonsolidierungsprojekt zu besprechen.