The Problem

I kept seeing the same pattern in Windows 10 to Windows 11 migrations: some devices moved, others stayed behind, and the reasons looked random.

What I tried first was checking hardware readiness only. That was not enough.

The real issue was three control failures mixed together:

  1. Assignment failure: Windows servicing intent depended on user context.
  2. Lifecycle failure: stale or split objects across Intune, Autopilot, and Entra ID.
  3. Eligibility failure: some devices were not Windows 11 capable.

The effective fix was to treat Windows lifecycle as a device problem, not a user problem.

Constraints

  • Mixed endpoint states: primary-user devices, shared devices, and devices with weak user affinity.
  • Legacy assignment model where update rings were attached to user groups.
  • Object lifecycle drift across Intune, Autopilot, and Entra ID.
  • Hardware mix with both Windows 11-capable and unsupported devices.

Decision

For this migration, I moved the servicing control plane to device groups:

  • Update rings -> device groups
  • Windows 11 feature update policy -> device groups
  • User groups kept only for user-context scenarios (apps/settings), not OS version control

This aligns with Microsoft guidance that update rings should be assigned to device groups so policy can apply without waiting for user sign-in.

Implementation

1. Stabilize Targeting First

In Intune admin center -> Devices -> Devices overview, I reworked servicing assignments into device cohorts.

Example cohort pattern:

  • W11-Pilot-Devices
  • W11-Broad-Devices
  • W10-Unsupported-Devices
  • W11-Stale-Orphaned-Devices
  • W11-Shared-NoPrimaryUser-Devices

These names are examples. Use your own convention, but keep the split clear.

2. Use Feature Update Policy as Version Authority

I stopped relying on “eventual” upgrade behavior from rings alone.

In Intune admin center:

  1. Go to Devices -> Windows -> Feature updates for Windows 10 and later
  2. Create policy targeting the Windows 11 version you want
  3. Assign to pilot device cohort first, then broad cohort
  4. Exclude unsupported hardware cohort

This gives explicit version intent and a reporting view for blocks like safeguard holds.

3. Build a Triage Matrix for Every Non-Upgraded Device

Each device that does not move should map to one status only:

  • Not targeted
  • Targeted but not eligible
  • Targeted but blocked by safeguard hold
  • Targeted but blocked by app/driver compatibility
  • Stale/duplicate/orphaned object
  • Provisioning/user-affinity timing issue

I used Intune Windows update reports to force this classification instead of guessing.

4. Handle “No Primary User” as a Data Signal

A device can be fully Intune-managed and still have no useful primary user mapping for user-targeted policies.

I treated that as data quality, not as a servicing dependency:

  • Keep servicing assignments device-targeted
  • Review shared/reimaged/reassigned devices for affinity quality
  • Do not block upgrade governance on perfect primary-user data

5. Clean Lifecycle Objects in the Correct Order

For retired/replaced devices, order matters:

  1. If the physical device is still active, stop and validate management state first.
  2. If retired/disposed and present in Intune, retire/delete in Intune.
  3. If Autopilot record exists, deregister/delete Autopilot object.
  4. If stale Entra object remains, disable then delete Entra device object.
  5. Keep Intune cleanup rules enabled to reduce stale Intune-only records.

Important: Intune cleanup rules do not clean Entra ID or Autopilot records.

6. Split Unsupported Hardware into Its Own Lane

Unsupported Windows 10 devices were moved into a dedicated cohort:

  • Excluded from Windows 11 feature update targeting
  • Kept on supported Windows 10 servicing
  • Exported into a replacement planning list (model, serial, assigned user/owner, department)

This turned a vague “some devices are stuck” conversation into a clear replacement workflow.

Measured Outcome

After shifting servicing to device-based control:

  • Upgrade intent became predictable for both user-affinitized and shared devices.
  • Reporting clearly separated unsupported, blocked, untargeted, and stale-object scenarios.
  • Cleanup work became procedural instead of ad-hoc.

The key improvement was operational clarity: every device had one lane and one next action.

Trade-offs and Watch-Outs

  • Policy effect is not immediate after provisioning. Group membership and Windows Update evaluation still need time.
  • Safeguard holds are legitimate service protections. Track them instead of bypassing them.
  • Cleanup in the wrong order can leave ghost records and false ownership signals.
  • Keep special-purpose/kiosk/shared profiles intentionally excluded where needed.

Validation Checklist

  • 100% of Windows servicing policies assigned to device groups (not user groups)
  • Every Windows 10 device appears in exactly one status lane: Ready, Blocked, Unsupported, or Stale
  • Intune reporting explains all non-upgraded devices
  • Unsupported devices are excluded from W11 targeting and included in replacement planning
  • Stale object count trends down across Intune, Autopilot, and Entra ID

Ops and Rollback

Ops

  1. Start with one pilot device cohort.
  2. Use phased rollout options after pilot health is clean.
  3. Monitor safeguard holds and deployment errors in feature update reports.

Rollback

  1. Remove affected device cohort from Windows 11 feature update policy.
  2. Keep update ring baseline in place.
  3. Reassign impacted devices to the Windows 10 servicing cohort if needed.