Field notes · 9 min read
Migrating 500 Users to Intune — Lessons Learned
A no-fluff, field-tested playbook from the trenches: how to move 500 users from legacy MDM (or nothing) onto Microsoft Intune without burning down the service desk.
The context
500 Windows 10/11 endpoints, a mix of laptops and a small desktop fleet, distributed across three offices and a growing remote workforce. Legacy imaging, patchy GPOs, inconsistent local admin rights, and a helpdesk drowning in "can you install this app for me?" tickets. The goal: modern management on Intune, Autopilot for new devices, self-service via Company Portal, and Conditional Access enforcing a real compliance baseline.
The rollout plan
The single most important decision was phased, not big-bang. Five waves, two weeks apart:
- Wave 0 — IT team (10 users). We eat our own dog food. Every policy hits us first.
- Wave 1 — friendly pilot (40 users). Volunteers from each department. Feedback loop is daily.
- Wave 2 — department by department (150). Start with the least critical, end with finance and execs.
- Wave 3 — the bulk (250). By now policies and apps are stable; scale hard.
- Wave 4 — the stragglers (50). Field staff, shared devices, edge cases.
Autopilot & enrollment
For existing devices we used Group Policy auto-enrollment to hand hybrid-joined machines over to Intune. For new devices we cut over to Windows Autopilot with hardware hashes imported directly from Lenovo at order time. Result: a new hire opens the box, signs in, and 25 minutes later has a fully configured device without an IT technician touching it.
- Autopilot deployment profile: user-driven, Azure AD join, hide EULA, hide privacy settings
- Enrollment Status Page: block until critical apps land (Teams, Office, VPN, security agent)
- Named a technical contact — users see a real name during OOBE, not a generic email
- Set a device name template (LT-%SERIAL%) so asset tracking stays sane
Compliance & Conditional Access
This is where migrations go to die. A compliance policy that's too strict on day one locks out users; too lax and there's no point running Intune at all. What worked for us:
- Start Conditional Access in report-only mode for 2 weeks before enforcing
- Scope CA policies to pilot groups first, then expand ring by ring
- Compliance baseline: BitLocker on, Defender healthy, min OS build, no jailbreak
- Grace period on non-compliance (72h) before blocking — gives users time to act
- A break-glass account excluded from all CA policies. Non-negotiable.
App packaging & Win32 apps
We inventoried ~120 apps in use. Roughly a third were replaced by Store or M365 equivalents, a third became Win32 packages via the IntuneWinAppUtil, and the last third stayed as manual installs during the transition. The killer feature nobody talks about: detection rules. Get them wrong and Intune re-installs the same app forever. Always test detection on a clean VM before publishing.
Pitfalls to avoid
GPO / Intune conflicts
Legacy GPOs kept overriding Intune settings. Audit and disable overlapping GPOs before enrollment, or use MDMWinsOverGP.
Company Portal confusion
Users didn't know it existed. Solution: pin it to the taskbar via Intune and send a 90-second Loom video, not a wiki page.
Autopilot pre-provisioning failing
Usually a Wi-Fi driver issue on OEM images. Test white-glove on every hardware SKU before you buy 200 of them.
Licensing gaps
Intune P1 vs P2, Defender for Endpoint, AAD P1 — spec the licenses BEFORE the pilot, not after.
What worked
- Weekly 15-min migration standups with helpdesk — surfaced problems in hours, not weeks
- A single Teams channel per wave for users to ask questions in public
- Ring-based deployment for Windows Updates via Update Rings in Intune
- Endpoint analytics dashboard to prove the fleet was healthier post-migration
- Killing local admin and rolling out LAPS — quietest security win of the year
What I'd do differently
Start with app rationalization
We packaged apps that nobody actually used. Cull the catalog first, then package.
Involve HR earlier
Onboarding docs still referenced the old imaging process for months. HR should be in wave 0.
Buy training, don't wing it
A 2-day Intune bootcamp for the team pays for itself in the first week of the rollout.
Document detection rules
Six months later, nobody remembers why a Win32 app was set up a certain way. Comment your rules.
FAQ
How long does an Intune migration of 500 users take?
A well-planned migration typically takes 8–12 weeks: 2 weeks discovery, 2 weeks pilot, 4–6 weeks phased rollout, 2 weeks stabilization.
Should I co-manage with SCCM or go cloud-native?
If you already run SCCM, co-management is the safer path — you can shift workloads (compliance, apps, updates) to Intune gradually. Greenfield or SMB? Go cloud-native from day one.
What's the biggest risk in an Intune rollout?
Conditional Access policies locking users out before their device is compliant. Always stage CA policies in report-only mode first, then scope to pilot groups.
Do I need Autopilot for 500 users?
Yes. Manual enrollment at 500 devices burns weeks of technician time. Autopilot + a hardware-hash import from your OEM turns a 45-minute setup into a self-service unbox.
How do I handle users who resist the migration?
Communicate early, show the benefit (self-service password reset, install apps from Company Portal, work from anywhere), and give power users a preview build. Resistance drops when they feel involved.
Key takeaways
- Phase everything. Big-bang Intune migrations fail publicly.
- Report-only mode is your best friend for Conditional Access.
- Autopilot is worth the setup cost the moment you enroll device #50.
- The migration is 40% technical, 60% communication. Budget accordingly.
Planning your own Intune rollout? I've done this in production.
Let's talk →