Modernization Governance — Whitepaper
Governing the AD to Entra ID migration at federal scale
Modernization Governance
Governing the AD to Entra ID migration at federal scale
Problem. The AD → Entra ID migration is an architectural inversion — from hierarchical placement to attribute-driven identity — that changes what “authoritative” means for every downstream plane. Run as a tools project (Entra Connect, hybrid sync, MFA, retire the domain controllers), it imports the old directory’s hierarchical assumptions into the new tenant and forfeits most of the cloud-native value.
Solution. Governance leads the migration rather than following it: canonize the authoritative attributes, group-computation rules, and provenance envelope first; stand up modernization adapters and compensating enforcement for the GCC-Moderate gaps; treat cutover as a substrate event; and let the drift engine surface inherited inconsistencies afterward — emitting evidence the AO can consume at every phase, not just at the end.
Ask. Sequence the program canon-first — the attribute model is authored and the substrate walker passes before any runtime change — and commit to attribute-driven access in Entra rather than recreating an OU-driven model there, because that is where all of the substrate’s leverage sits.
Executive summary
The Active Directory → Entra ID migration is the most architecturally consequential modernization most federal agencies will execute this decade. It moves identity from a perimeter-administered, OU-hierarchical directory into a cloud-native, attribute-driven identity plane — and in doing so changes what “authoritative” means for downstream addressing, network, telemetry, and compliance planes.
Most agency programs treat the migration as a tools project: deploy Entra Connect, run hybrid sync, extend MFA, retire on-premises domain controllers. FMP’s position is that this framing is structurally incomplete: migration is an architectural inversion of the identity plane, and an agency that runs it as a tools project will inherit the old directory’s hierarchical assumptions in the new tenant — and lose most of the cloud-native value.
This whitepaper explains what changes structurally, why governance must lead the migration rather than follow it, and how FMP’s substrate provides the canonical fabric that makes the migration a one-way modernization rather than a reversible re-platforming.
The companion executive brief is Modernization Overview, and the modernization pillar’s curated surfaces — the transformation series and the adapter interfaces this paper’s approach rides on — are collected at the OrgMod hub. The migration’s specific failure-mode-and-fix is documented in AD to Entra ID Migration Problem. The substrate this paper names as FMP’s is the same one the the compliance series series’ own Vol X — Governance Substrate Integration Overview documents from the product-neutral side — see §3 below.
1. The architectural inversion
On-premises Active Directory operates a hierarchical placement model: identities are positioned within OUs, and access flows from that placement. Entra ID operates an attribute-driven model: identities carry attributes, and access is computed from those attributes by policy.
The two models are not interchangeable. Five concrete consequences for governance:
- Movers stop being a manual workflow. When attributes change, access recomputes. There is no “move the user OU and re-permission the shared drive” step — there are attributes and policies that evaluate them.
- Authoritative identity context becomes the primary engineering artifact. Wrong attributes produce wrong access; right attributes produce right access. The directory’s quality becomes the program’s quality.
- Group membership shifts from administered to computed. Dynamic groups, administrative units, and conditional access rules all consume attributes. Manual group administration is friction, not governance.
- The boundary between identity and policy moves. In AD, ACLs and group memberships hold most policy. In Entra ID, conditional access, PIM, and entitlement management hold policy — and identity is purely attribute-bearing.
- Drift surface changes. Identity drift in AD looks like stale group membership. Identity drift in Entra ID looks like stale or inconsistent attributes feeding policy decisions. Both matter; the detection mechanism is different.
Agencies that approach the migration as “lift the existing directory into the cloud” inherit the OU-driven model in Entra ID and lose attribute-driven value. FMP’s modernization-governance posture is that the migration is the moment to make the inversion explicit and govern it deliberately.
2. Why governance must lead, not follow
A common federal pattern is to run the technical migration first, then “layer governance on top” once the new tenant is live. This pattern fails for three structural reasons:
Failure 1 — once attributes are wrong, every downstream decision is wrong. Attribute-driven identity makes the directory’s content load-bearing. Migrating without canonical attribute definitions produces a tenant that works but does not govern; tightening governance later means re-classifying every identity.
Failure 2 — the addressing and telemetry planes drift first. Identity-derived addressing and identity-correlated telemetry begin emitting against the new tenant the moment it is live. If the identity plane’s truth is not canonical at cutover, downstream evidence inherits the inconsistency.
Failure 3 — compliance evidence becomes uncorrelatable. SSPs authored against the old directory cannot be regenerated against the new tenant if the canonical claim definitions changed. Every ATO touch becomes a re-engineering exercise.
The FMP approach is to canonize the identity plane before cutover — declare the attribute model, the group computation rules, and the provenance envelope in src/fmp/canon/ — so the migration is a substrate change rather than a tooling change.
3. The substrate’s role in migration
The FMP substrate provides four structural mechanisms that make the migration tractable:
| Mechanism | Migration role |
|---|---|
| Canon SSOT | The attribute model lives in canon, not in the directory. Migrating the tenant does not migrate the model. |
| Modernization adapters | modernization-registry.yaml (28 entries) declares change-making adapters, including first-class bluecat-address-manager and infoblox adapters for the addressing plane. Each maps a piece of pre-migration infrastructure to its post-migration target. |
| Provenance envelope | Identity claims emitted during and after migration carry source_classification (authoritative / derived / synthesized), making the migration’s evidence reproducibly classifiable. |
| Drift engine | Schema and provenance drift surface attribute or group-rule mismatches in CI; runtime detection for identity and authorization drift is partially implemented and maturing. |
Because canon is the source of truth, the migration’s evidence does not have to be assembled from the directory’s state — it can be regenerated from canon plus telemetry, deterministically, before and after cutover.
The same four mechanisms are what Vol X of the Federal Compliance series calls, without naming FMP, “a governance substrate that sits underneath the whole series… general-purpose… not itself tied to this series.” Vol X’s canon SSOT and drift-gate mechanics bind the the compliance series series’ own Identity-slot evidence (organizational-user authentication, account management, device identity) to the same substrate this migration’s provenance envelope depends on — a second, independently-authored corpus proving the substrate carries a regime it was never written for, which is the concrete version of this paper’s “canon, not the directory, is the source of truth” claim above.
4. Phased modernization
The substrate’s Modernization Timeline is the canonical month-by-month program plan (six months, workstreams A–D). The five phases below are this paper’s distillation of how governance sequences within that plan:
- Canon-first phase. Author the attribute model, group computation rules, and provenance envelope in
src/fmp/canon/. The substrate walker passes against the new canon before any runtime change. - Modernization-adapter phase. Stand up the modernization adapters for identity (Entra ID), addressing (BlueCat / Infoblox), and the telemetry surface required to correlate them. Adapters emit canonical claims with full provenance from day one.
- Compensating-enforcement phase. Where platform features are unavailable (especially in GCC-Moderate per the Boundary Impact Model), stand up compensating enforcement adapters whose evidence flows through the same chain.
- Cutover. The directory transition is itself a substrate event: the identity plane’s authoritative source switches from on-prem AD to Entra ID, with canon already in place to interpret post-cutover claims.
- Drift-driven cleanup. Post-cutover, the drift engine surfaces inherited inconsistencies (stale attributes, dangling group rules, broken provenance chains). Each is a tracked finding with a remediation contract, not a discovery exercise.
Steps 1–3 are governance-led. Step 4 is the technical event most programs treat as the migration. Step 5 is what determines whether the migration delivers cloud-native value.
Walking one attribute through all five phases. The phases above are sequenced abstractly; concretely, here is what happens to a single authoritative attribute — classification clearance — from canon authoring through post-cutover cleanup:
- Canon-first. Classification clearance is authored in
src/fmp/canon/as an authoritative attribute: its allowed values, its authoritative source (the HR/personnel system of record), and the policies permitted to consume it are declared before any tenant work begins. - Modernization-adapter. The identity adapter for Entra ID is configured to read classification clearance from its authoritative source and write it into the tenant as a directory attribute, emitting a canonical claim with a
source_classification: authoritativeprovenance tag from the first sync. - Compensating-enforcement. Where a GCC-Moderate boundary gap means Entra ID cannot itself enforce a classification-scoped conditional access rule, a compensating enforcement adapter evaluates the same attribute against the same canonical policy and emits evidence in the same shape — so the AO sees one continuous claim regardless of which layer enforced it.
- Cutover. At the AO checkpoint, classification clearance’s authoritative source switches from the on-prem AD attribute to the Entra ID directory attribute. Because the attribute’s definition lives in canon and did not change at cutover, only its supplying system did, this is a single auditable event rather than a re-classification exercise.
- Drift-driven cleanup. Post-cutover, the drift engine compares classification-clearance values and their provenance chains against canon. A record whose AD-era clearance value never migrated cleanly, or whose provenance chain breaks between HR system and tenant, surfaces as a tracked finding with a remediation contract — not a silent access-control error discovered later.
5. What this means for an ATO package
A governance-led migration produces an ATO package the AO can review continuously through the migration rather than at the end:
- Canon citations for every attribute and policy intent.
- Modernization adapter findings emitted into OSCAL throughout the migration, not just post-cutover.
- Drift findings (and remediations) per migration phase, scoped to plane and layer.
- Boundary-aware evidence: GCC-Moderate feature gaps are first-class findings rather than implicit constraints.
The AO does not have to wait for cutover to evaluate the program’s identity posture. Each phase emits evidence the AO can consume, and the phase’s drift findings are themselves a measure of program quality.
6. Honest limits
- The migration is a multi-quarter program for a typical federal agency. FMP compresses the governance timeline by canonizing the model up front; it does not compress the technical migration.
- Several runtime drift classes (identity, authorization, semantic) are only partially implemented today. Agencies in mid-migration will run with schema and provenance drift coverage in CI plus partial runtime coverage; full Optimal-grade runtime drift is engineering work ahead.
- The approach is opinionated. Agencies that elect to keep an OU-driven model in Entra ID can still use FMP, but they will not realize most of the substrate’s value — the substrate’s leverage is in attribute-driven access.
7. Conclusion
The AD → Entra ID migration is one of the rare programs where doing it right and doing it well are the same thing. Doing it well requires a substrate that canonizes the identity model independently of the directory product, governs the migration as a substrate change, and emits reproducible evidence at every phase. The FMP substrate is built for that.
Agencies that adopt this posture do not just migrate. They modernize the identity plane in a way that survives the next directory transition — because the canon is the source of truth, and the directory product is a consumer.