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 a 30–60 minute 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 works differently: 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. Devices shipped with Windows 10, or Windows 11 versions earlier than 24H2, cannot use APDP. 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 › Enrollment › Windows › Autopilot device preparation.
3. Select Create policy.
4. On the Basics page: give the policy a name and 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 page: choose your deployment mode settings.
7. On the Apps and scripts page: add the apps and scripts to deploy during OOBE. These must be assigned to the device group from Stage 1 in Intune already — APDP tracks items assigned to that group.
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 the deployment monitoring screen (the APDP equivalent of the ESP). A successful APDP enrollment completes in under 10 minutes for a typical app set.

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.