Entra ID identity readiness before an Intune migration

Start with device identity states, not a migration date

An Intune migration is partly an identity transition. Before moving management workloads or enrollment paths, establish how devices are represented, how users authenticate, and which access decisions depend on device state. A device can be registered, joined, hybrid joined, or in another state with different implications. Avoid treating those labels as interchangeable or assuming that a successful management check-in proves the identity design is correct.

Inventory representative populations and identify how each is created and maintained. Consider corporate Windows devices, shared or frontline devices, remote users, privileged workstations, and devices with special network or application dependencies. Record which populations are in scope for migration and which are not. The objective is not to force every population into one path; it is to understand whether each intended path has a supported, owned enrollment and access model.

Trace the sign-in experience end to end. Ask how authentication, device registration, enrollment, and conditional access interact for a new device, a reimaged device, a user changing roles, and a device with stale or duplicated records. Document which team owns each transition. When an incident crosses identity and endpoint boundaries, a named escalation route is more useful than a general statement that both teams are involved.

Map dependencies that are easy to overlook

Group-based assignment is often central to both identity and endpoint policy. Confirm how users and devices enter groups, how dynamic rules are evaluated, and what happens when attributes are missing or delayed. If access or enrollment depends on a group, test that dependency with a controlled account and device. Do not infer readiness from group names or a spreadsheet that was not reconciled with actual membership.

Review enrollment restrictions, platform controls, licensing assumptions, and delegated permissions with the identity and endpoint owners. Check whether existing device objects, registration processes, or join workflows could produce duplicate or ambiguous records. For hybrid environments, include the directory synchronization and device registration dependencies that apply to the chosen design. Changes to those foundations may affect sign-in or access beyond the migration cohort, so they need their own impact review.

Conditional access deserves careful coordination. Identify policies that use device state, client app, location, or user risk, and determine how the intended pilot device is expected to satisfy them. A policy that blocks an unregistered device may be an intentional security control, but it can also obstruct enrollment if the bootstrap path is not designed. Do not disable broad access protections as a convenience; design and test a narrow, approved path with security stakeholders.

• Inventory actual join and registration states by meaningful device population.
• Trace user, device, group, enrollment, and access dependencies together.
• Check licensing, restrictions, delegated permissions, and existing object lifecycle.
• Review conditional access with identity and security owners before changing enforcement.

Use a migration cohort to prove the identity path

Choose a small cohort that exercises the intended identity paths without including every exceptional case at once. State the prerequisites, success criteria, and stop conditions. Ensure the test devices have an approved owner, recovery plan, and support contact. Test the standard sign-in and enrollment flow, then confirm the device identity and management state using authoritative tenant views and device evidence appropriate to the scenario.

Include role changes and recovery in the test plan where they matter. For example, consider what happens when a user is removed from a target group, a device is replaced, or a registration record becomes stale. The goal is not to induce disruptive failure in production; use controlled test identities and devices to validate lifecycle behavior. Avoid deleting directory objects or changing identity synchronization settings without a reviewed procedure and appropriate permissions.

Correlate access outcomes with the exact identity state, group membership, and policy assignment at the time of the test. Capture enough evidence to reproduce the result while minimizing sensitive data. If the outcome depends on manual correction, document the step and decide whether it becomes an approved operational task or a design issue to resolve before expansion.

Sequence work around blast radius

Migration sequencing should follow dependency and impact, not just management-console ownership. A broad identity change can affect sign-in and application access before endpoint teams notice. Conversely, an endpoint enrollment change can create device state that access policies interpret differently. Coordinate the change windows, communications, monitoring, and rollback or containment across both teams.

Keep the first production cohort narrow and observable. Verify the intended result before proceeding to the next population. Make it possible to pause without leaving users stranded between old and new management paths. Where the previous tool remains active during transition, explicitly define authority for policies, applications, updates, and security controls so two systems do not apply conflicting intent.

The transition is not complete when a device appears in the new console. Confirm that users can authenticate, required work resources remain accessible, support can identify the owner of the next action, and the old path is retired safely. Keep the decision record current as assumptions change. Identity prerequisites are not a one-time checkbox; they are part of the endpoint service’s ongoing operating model.

Readiness decision

Documentation can explain supported identity concepts and enrollment options, but it cannot validate the organization’s synchronization, group logic, access policies, or delegated administration. Confirm current Microsoft guidance for the chosen design and test in a representative tenant scope. Any changes to identity, access, or enrollment require the organization’s security approval, least-privilege permissions, and a tested user recovery path.

Proceed when the team can state which identity path each cohort uses, how the path is verified, what access decisions depend on it, and who responds when the state is unexpected. If those answers are missing, the best migration milestone is to resolve them—not to increase the rollout percentage.

• Device identity state and enrollment path are known for each cohort.
• Conditional access and bootstrap behavior have been reviewed and tested.
• Identity and endpoint owners agree on evidence, escalation, and pause criteria.
• Production sequencing preserves recovery and avoids ambiguous management authority.