Autopilot readiness assessment: what it should check, what you walk away with, and when you don't need one

Most IT leaders treat an Autopilot readiness assessment as a formality: a consultant exports your Intune config, writes a roadmap, and quotes a rebuild. If the report doesn't name the phase where enrollment actually fails, you didn't get an assessment. You got a sales call.

This is the checklist we use when we assess Autopilot tenants: who needs one, what it should inspect, what you should hold in your hand at the end, and what to ask any provider before you sign.

Who needs an Autopilot assessment, and who doesn't

An assessment pays off when the problem is bigger than one device. The usual triggers: ESP failures that repeat across the fleet with different error codes each week, a tenant inherited half-configured from a previous admin or MSP, a hardware refresh that will put hundreds of new devices through the same broken path, and a move off imaging or task sequences.

You probably don't need one if the tenant is small, you built it, and Autopilot already finishes cleanly on pilot devices that match production. Spend that budget on the rollout instead.

If you're coming from imaging or task sequences, know what changes. Autopilot doesn't reimage. It provisions the OEM image that ships on the device. For a ConfigMgr shop, co-management moves workloads to Intune on existing devices, while the identity change to Entra join usually happens at hardware refresh, since moving from hybrid join to Entra join means a reset. A useful assessment sorts the fleet by refresh date so the plan follows the hardware calendar instead of fighting it. Microsoft Learn's co-management overview is the right starting reference.

What breaks it:

• Assessing a symptom instead of a path. If the brief to the provider is "fix error 0x800705b4," you'll get one fix. Ask for the enrollment path end to end.
• No representative failure evidence. Pick two or three devices that actually failed and keep their logs. A clean lab device proves nothing.
• Unclear ownership. Decide up front whether your team keeps Autopilot afterwards. That answer changes what the plan should recommend.

What a good Autopilot assessment checks

The visible error is rarely the whole problem, so the inspection has to go wider than the deployment profile. Microsoft's Windows Autopilot requirements set the floor for licensing, networking and configuration. On top of that, a real assessment works through:

• Deployment profile assignment and Enrollment Status Page behavior, including which apps ESP blocks on
• Required-app detection, dependencies, install context and sequencing, because two required apps racing each other look like an ESP timeout
• Configuration, compliance and security-policy conflicts that land during setup
• Entra and Intune readiness, licensing and device identity
• On-premises resource access and Cloud Kerberos Trust prerequisites
• Defender endpoint controls, Universal Print and pilot-device evidence when they're in scope

Failure families like an ESP timeout or a hash import stuck at Syncing usually have a cause one layer away from where they surface.

What breaks it:

• A config export as the deliverable. A long settings export is inventory, not analysis.
• Skipping identity and licensing. A missing license or a device identity problem stops enrollment before your profile ever applies.
• Reading policy without reading logs. The settings tell you intent. The device logs tell you what happened.

What you should walk away with, and what to ask before you sign

At the end you should hold three things. First, the failing phase or app, named. Second, a prioritized plan: what to fix first, what can wait, and what to stop doing. Third, a recommendation for the next step that fits how your team operates: remediate the agreed fixes, design and pilot a supportable path before scaling, keep an engineer on an advisory retainer, or hand enrollment ownership to someone else.

If you'd rather have someone run that assessment against your own tenant, our Windows Autopilot Consulting Assess path reviews profiles, ESP, app dependencies, policies, identity, and licensing, then hands back a prioritized recovery plan before anyone quotes a rebuild.

Admins in r/Intune threads about hiring Intune help keep coming back to the same few checks:

1. Have you done this before, and what did you learn? Ask about prior projects and what they'd change.
2. Do you bring a standard baseline? A provider who asks you "what should we do?" is billing you to learn.
3. What's the fixed scope before work starts? Deliverables, boundaries, and who owns the result when they leave.
4. Can you coexist with our MSP? The Autopilot work shouldn't require replacing whoever runs your helpdesk.

The same threads carry warnings about firms that kept people going in circles. A written scope is the cheapest protection.

What breaks it:

• A quote before evidence. Nobody can price a remediation honestly before they've seen the enrollment path. The shape that holds up is diagnostic first, then scope and quote.
• No straight answer. "You need a rebuild" with no failing phase named is a pitch. "You don't need us" should be a possible outcome.

What "good" looks like: the five-move baseline

1. Write down the decision you're making: assess, rebuild, or hand off. Then pick the evidence that would settle it.
2. Collect failure evidence from two or three real devices before anyone starts.
3. Check against Microsoft's requirements first, then profiles, ESP, apps, policy, identity and licensing, in that order.
4. Insist on a named failing phase and a prioritized plan as the deliverable.
5. Get scope in writing before remediation: what's included, what's excluded, and who owns enrollment afterwards.

If you'd rather not own enrollment day to day, the Managed path is the ongoing alternative.

The uncomfortable question

The question isn't whether your tenant is "ready for Autopilot." It's whether you can say which phase fails today and on which devices. Open the Windows Autopilot deployments report in the Intune admin center (Devices > Monitor) and filter to failures from the last 30 days. If you can't name the top failing app or phase from that list, start there, with or without help.