Moving from Classic Windows Autopilot to APDP — The IT Admin Migration Checklist

The problem: classic Autopilot is not going away, but APDP is where Microsoft is heading

If you have been running Windows Autopilot for any length of time you know the flow: collect the 4K hardware hash from each device, import it into Intune or have the OEM or reseller register it directly, build a dynamic Microsoft Entra security group keyed on the EnrollmentProfileName or OrderID Autopilot attribute, assign your deployment profile to that group, and watch the Enrollment Status Page crawl to its end.

That flow still works. Microsoft has not announced an end-of-life date for classic Windows Autopilot. But in 2026 the guidance is clear: new Windows 11 user-driven deployments should be built on Windows Autopilot Device Preparation (APDP), and existing classic Autopilot deployments that match the eligibility criteria should be migrated across.

The challenge is that the two systems are architecturally different enough that you cannot simply reassign a policy. There are prerequisites to meet, objects to create, devices to deregister, and a specific pitfall that will silently keep your devices on the classic path even after you believe you have cut them over.

Why it happens: the architectural shift from hash to identity

Classic Autopilot is device-centric. The 4K hardware hash uniquely identifies the physical machine before any user touches it. When the device connects to the internet during OOBE, Windows contacts the Autopilot service and downloads a deployment profile based on that hash. The user has not authenticated yet. The profile dictates what the OOBE looks like and which policies apply.

APDP is identity-centric. There is no pre-registered hash. There is no profile download before the user signs in. Instead, when the user enters their Entra ID credentials during OOBE, the service looks up which APDP policy covers that user, and at that moment the device is added to a static Microsoft Entra security group via Enrollment Time Grouping (ETG). Apps, scripts, and policies assigned to that group are then delivered to the device in near real-time.

How to verify: is your environment APDP-ready?

Before touching any devices or policies, run through this eligibility check. A single "no" in the wrong column means that population must stay on classic Autopilot.

Step 1 — Check device operating system

APDP requires Windows 11, version 24H2 or later, version 23H2 with KB5035942 or later, or version 22H2 with KB5035942 or later. Windows 11 installation media dated April 2024 or later already includes KB5035942, so most in-service 22H2 and 23H2 devices already qualify — do not write those fleets off. Windows 10 is not supported at any patch level. Run this on any candidate device during OOBE (Shift+F10 to open a command prompt) or on an enrolled machine:

Step 2 — Identify which scenarios you are running

Map each of your current Autopilot deployment profiles to the scenarios below. Any population using an unsupported scenario must remain on classic Autopilot.

Step 3 — Check whether devices are currently registered in classic Autopilot

Use this PowerShell script to export a list of all devices registered in your classic Autopilot service. You will need this list during the deregistration step.

The fix: migrating from classic Autopilot to APDP step by step

Migration is a five-stage process. Do not skip stage 2 (Intune Provisioning Client as group owner) — APDP silently fails to add devices to the group if this is missing, and there is no warning in the Intune admin center.

Stage 1 — Create the static Entra security group for devices

APDP uses Enrollment Time Grouping to add each device to a static Entra security group the moment the user authenticates. You need to create this group before you create the policy.

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Groups › All groups › New group.
3. Set Group type to Security.
4. Set Membership type to Assigned (not dynamic — ETG adds devices at enrollment, not via a membership rule).
5. Enter a group name, e.g. APDP-Devices-HQ-Laptops.
6. Confirm Microsoft Entra roles can be assigned to the group is set to No. If this is set to Yes, ETG cannot add devices to the group.
7. Select Create.

Stage 2 — Add the Intune Provisioning Client as owner of the group

This is the step most documentation buries or omits. APDP uses the Intune Provisioning Client service principal (a first-party Microsoft application in your tenant) to add devices to the target group at enrollment time. If this service principal is not an owner of the group, the group membership step silently fails and devices never land in the group.

1. Open the group you just created.
2. Go to Owners › Add owners.
3. Search for Intune Provisioning Client.
4. Select it and choose Select.

You can verify the owner was added correctly with PowerShell:

Stage 3 — Create the APDP policy in Intune

1. Sign in to the Intune admin center (intune.microsoft.com).
2. Go to Devices, and under By platform select Windows. Under Device onboarding select Enrollment, then under Windows Autopilot device preparation select Device preparation policies.
3. Select Create, then User Driven.
4. On the Introduction page, select Next. On the Basics page, enter a Name and optional Description, then select Next.
5. On the Device group page: select the static group you created in Stage 1. This is the ETG target group. Select Next.
6. On the Configuration settings page, expand Deployment settings and set Deployment mode to User-driven, Deployment type to Single user, and Join type to Microsoft Entra joined. Set User account type to Standard User or Administrator.
7. Still on Configuration settings, expand the Apps section (maximum 25 applications) and the Scripts section (maximum 10 PowerShell scripts). Both must already be assigned to the device group from Stage 1, and both must run in the System context, since OOBE runs with no user signed in. Note these are sections inside Configuration settings, not a separate wizard page. Then select Next, select Next again on Scope tags.
8. On the Assignments page: assign the policy to the user group whose members will use APDP when they sign into a new device during OOBE.
9. Select Next › Create.

Stage 4 — Deregister candidate devices from classic Autopilot

Any device you want to migrate must first be removed from the classic Autopilot service. The deregistration does not wipe the device. It removes the entry from the Autopilot database so that on next enrollment the device will not receive a classic Autopilot profile.

In the Intune admin center:

1. Go to Devices › Windows › Windows enrollment › Devices (under Autopilot).
2. Filter by the group tag or serial number range for your pilot cohort.
3. Select the devices and choose Delete (this removes them from the Autopilot service, not from Intune or Entra ID).

For bulk deregistration using the serial numbers from the CSV you exported in Stage 0 (verify step):

Stage 5 — Test with a pilot device

Factory-reset or use a new device that has never been enrolled. Boot to OOBE, connect to the internet, enter the credentials of a user who is in the assigned user group for the APDP policy. Watch for the Setting up for work or school window with its round progress bar. This doubles as your best diagnostic: APDP does not use the Enrollment Status Page, so if the ESP appears, the device is not running an APDP deployment — it is almost certainly still picking up a classic Autopilot registration or profile. Time the run and use that as your own baseline. Microsoft publishes no target completion time, and yours will depend heavily on how many of your 25 permitted apps you actually deploy and how large they are.

Proof it worked: what success looks like in Intune

After a successful APDP enrollment you should see all of the following:

In the Intune admin center — Device list

The device appears in Devices › All devices with the enrollment profile name identifying it as an APDP enrollment (not a classic Autopilot enrollment). The Device enrollment type shows Windows Autopilot device preparation rather than Windows Autopilot.

In the Entra admin center — Group membership

Check the static device group from Stage 1. The new device should appear as a member within seconds of completing enrollment. If it does not appear within a few minutes, the Intune Provisioning Client owner permission is missing (Stage 2).

Confirming no classic Autopilot registration remains

References

• Moving from Windows Autopilot to Windows Autopilot device preparation (Microsoft Tech Community)
• Overview of Windows Autopilot device preparation (Microsoft Learn)
• Compare Windows Autopilot device preparation and Windows Autopilot (Microsoft Learn)
• Windows Autopilot device preparation FAQ (Microsoft Learn)
• Create a Windows Autopilot device preparation policy (Microsoft Learn)

Microsoft MVP community deep-dives

Last updated: 18 September 2026. This post reflects APDP capabilities as of Windows 11 24H2 and Intune September 2026 release. APDP feature parity with classic Autopilot is evolving — check the Microsoft Learn comparison page for the latest supported scenarios.