ongoing
Hybrid identity modernization
Moving a legacy AD DS domain onto native Entra ID Governance — and finding out which migration steps only cause problems once real objects are moving through them.
- status
- Ongoing — new sync scenarios added as they're tested
- directory
- On-prem AD DS domain, hybrid-joined to a dedicated Entra ID tenant
- stack
- Microsoft Entra Connect / Cloud Sync, Entra ID Governance, PowerShell
- scope
- Generic migration patterns only — no specific organization's directory structure
The question
Plenty of documentation exists for the individual pieces — how sync works, how a hybrid join works, how Entra ID Governance is configured. Far less exists on the sequencing: what order to migrate things in so that a legacy directory becomes a governed cloud identity system without a week of broken group memberships in the middle.
So the question here isn't "does hybrid identity work" — it does. It's "what does the transition actually look like while it's half-finished."
Setup
A small on-prem AD DS domain runs alongside the lab's Entra ID tenant, hybrid-joined so sync behavior can be observed directly rather than inferred from documentation. Legacy patterns — on-prem security groups doing double duty as both permission and distribution groups, service accounts with directly assigned rather than group-based access — get introduced deliberately, since those are exactly the patterns that make a real migration harder than the reference architecture suggests.
What gets measured
- Sync latency and failure modes as object volume and group nesting increase.
- What breaks first when a hybrid-joined device loses connectivity to the on-prem domain controller.
- How cleanly a legacy security group converts into an Entra ID Governance access package without a gap in who has access.
- Where a cutover sequence creates a window of either excess access or lost access — and how to size that window before it matters.
Ongoing. Each migration pattern is written up once it's been run through fully, including the failure cases. Nothing here jumps straight to the tidy end state.
Notes so far
- The gap between "sync is configured" and "sync is trustworthy" is measured in edge cases, not documentation pages. Nested groups and duplicate-purpose groups cause most of it.
- Cutover sequencing matters more than any individual configuration choice. The same end state can be reached safely or dangerously depending on the order objects move in.
Generic patterns only. This project models directory structures and migration sequences in general — it does not describe, reference, or reveal any specific employer's or customer's actual environment.
Reproducing it
Everything here uses Microsoft's documented sync tooling and public Graph PowerShell cmdlets. The only lab-specific part is the deliberately messy starting directory structure, described in each write-up as it's published.
Related work in the lab
Access packages behave differently once objects are syncing in from an on-prem directory — that overlap is where most of the interesting findings show up.