Group Policy to Intune Migration Guide 2026: Inventory, Mapping and Cutover
tiagoscarvalho.com
Migrating from Group Policy to Microsoft Intune is one of those projects that looks like a tool swap on the slide and feels like an architecture change in the room. The first month is spent inventorying GPOs that nobody remembers writing. The second is spent discovering which ones don't map cleanly. By the third, the team realises the value is not in moving every GPO — it is in leaving behind a decade of accumulated configuration debt and operating endpoints in a model that actually fits a cloud-first organisation. This field guide is the realistic readiness path: inventory, analytics, mapping, the co-management vs cloud-native decision, phasing, cutover, and the operating model after the last device leaves Active Directory.
1. Starting the migration: read top to bottom and follow the implementation phases.
2. Mid-migration, stuck on what doesn't translate: jump to "What translates cleanly, what doesn't" and the Common mistakes list.
3. Migration partly done, validating before broader rollout: use the Validation checklist and the "What to fix first" table.
Introduction
Every Group Policy migration I have done starts the same way. Someone — usually a CIO or an IT director — says "we want to move off Active Directory for endpoints." The endpoint team opens GPMC, exports a list, and discovers somewhere between 150 and 800 Group Policy Objects. Most of them have not been touched in three to seven years. A few of them have. Nobody can confidently say which is which without going through them one by one.
This is the part of the migration that nobody puts on the slide. The Intune-side work — building configuration profiles, deploying compliance policies, wiring Conditional Access — is well-documented and reasonably linear. The AD-side work — understanding what each GPO actually does, whether anyone still needs it, and what should replace it in Intune — is the unglamorous heart of the project. It is also where most of the value sits, because the migration is the only time someone is paid to delete configuration nobody understands.
This field guide is the migration readiness path I follow on real engagements. It is not an Intune setup guide — that ground is covered in the Intune for SMBs series for green-field setups. It is the bridge for tenants that already have Intune running for some of the estate but still have GPO managing the rest, or for tenants that are about to make the cutover commitment and need a defensible plan.
Who this article is for
Enterprise endpoint admins planning a serious GPO-to-Intune migration. Microsoft 365 architects scoping the cloud-native endpoint cutover. MSPs with hybrid clients where the Intune side is in place but the GPO side is still alive. IT directors writing the migration business case who need to defend the timeline against the "shouldn't this be quick?" pressure. It assumes familiarity with Group Policy concepts (GPMC, GPO linking, GPO precedence, Group Policy Preferences) and the basics of Microsoft Intune.
What you are trying to achieve
A defensible migration leaves the organisation with the following state.
- A documented inventory of every GPO that existed before the migration, classified by purpose (security baseline, software config, drive map, logon script, printer map, etc.), and with a status (kept, deprecated, replaced in Intune, retired without replacement).
- Intune configuration profiles, primarily built in the Settings catalog, that deliver the equivalent intended outcomes for the GPOs marked "replaced in Intune."
- A documented decision on the non-translatable items — logon scripts, drive maps, printer maps, software installation GPOs — and the Intune-side replacement (PowerShell scripts, Remediations, Win32 apps, modern printing solutions, etc.).
- A documented architecture decision: cloud-native (devices Microsoft Entra joined, Intune-managed, no AD) vs co-management (Microsoft Configuration Manager + Intune, workloads shifting one by one) vs Microsoft Entra hybrid joined (devices joined to both on-premises AD and Microsoft Entra, with GPO still possible). Each option has a defensible use case, but the team has to pick one consciously.
- A phased cutover plan with named pilot rings, expansion criteria, rollback paths, and a defined success condition for each phase.
- A signal chain that works end-to-end: device enrolled in Intune → configuration profiles applied → compliance policy evaluated → compliance signal consumed by Conditional Access. Validated per ring before broader rollout.
- A post-migration operating model: who owns ongoing Intune configuration changes, how new settings are added, how the team reviews and prunes profiles, when the AD OU for migrated devices is decommissioned.
That is what good looks like. The team that finishes the migration with that state has not just moved tools — they have rebuilt the endpoint configuration model on more defensible foundations.
Architecture context
The most useful thing a team can do before opening Intune is to understand why the Group Policy model does not translate cleanly. Group Policy is a hierarchical, AD-anchored model: GPOs link to OUs, sites or domains; they evaluate at logon, network change, or periodic refresh; precedence follows the LSDOU rule (Local → Site → Domain → OU) with optional enforcement and block inheritance. Group Policy Preferences extends the model into territory the original GPOs never covered — drive maps, printer maps, registry items, files, scheduled tasks.
Intune does not work this way. Intune policies are assigned to Microsoft Entra groups (users or devices), evaluate on device check-in (the interval varies by policy type and platform — typically several hours, with options for forced sync), and the model around conflicts is entirely different: assignment filters, scope tags, and conflict reporting and resolution that depends on the policy type, CSP and platform. Overlapping policies should be avoided rather than relied on. There is no concept of OU-based precedence. There is no direct equivalent to Group Policy's logon-time processing model. There is no built-in Group Policy Preferences equivalent — drive maps, printer maps and the other GPP extensions need to be reimplemented through different mechanisms (Settings catalog where applicable, scripts where not, dedicated modern services where available).
This architectural difference is the source of most migration pain. A team that approaches Intune as "Group Policy in a web interface" will fight the platform for months. A team that approaches it as a different platform with a different model will design profiles that actually fit how Intune evaluates, with names and scopes that make sense in the new context.
Conflict avoidance model
Because Intune's conflict resolution depends on policy type, CSP and platform, the only reliable strategy during a migration is to avoid conflicts rather than rely on the platform to resolve them. The table below captures the conflict patterns that consistently appear during GPO-to-Intune migrations and the rule that handles each.
| Risk | Rule |
|---|---|
| Same setting in GPO and Intune simultaneously | Do not enforce both during cutover. Unlink the GPO from the migrated devices' OU as part of the cutover step — not as a follow-up. |
| Same setting in two Intune profiles | Consolidate into a single profile, or if separate profiles are necessary (different scopes), document the precedence explicitly in the profile names and the operational register. |
| User-targeted and device-targeted assignments overlapping on the same setting | Use groups and assignment filters deliberately. Decide whether the setting is fundamentally a user or device property before assigning — do not assign to both. |
| Security baseline vs custom profile conflict | Validate in pilot ring before broad rollout. The Intune Security baseline and a custom Settings catalog profile can both target the same CSP path; pick one as the source of truth for each setting. |
| Hybrid-joined devices receiving both GPO and Intune | Remove the GPO link from the migrated devices' OU during ring cutover. "We'll keep the GPO as a safety net" is the pattern that produces silent drift six months later. |
| Migrated device still in the old OU after cutover | Move migrated devices to an OU with no GPOs linked (or remove the AD computer object if going fully cloud-native — see the implementation guide for the cleanup nuance). |
Decision framework
Three architecture decisions shape the entire migration. I have rebuilt the same Intune profile twice in different shapes on one engagement because Decision 1 was changed mid-project — rework that would not have happened if the choice had been written down. Each decision is roughly independent and reversible at increasing cost. Get them in writing before any Intune profile is built.
Decision 1 — Cloud-native vs co-management vs hybrid join
| Option | Identity model | Best for | Trade-offs |
|---|---|---|---|
| Cloud-native | Microsoft Entra joined, Intune-managed, no on-prem AD line-of-sight from the device | Greenfield, post-cutover end state, fully remote workforces, organisations with no AD-dependent legacy apps | Cleanest, fewest moving parts. Requires the on-prem dependencies to be sorted out first. |
| Co-management | Microsoft Configuration Manager + Intune, workloads shifting one at a time | Large existing ConfigMgr investments, regulated industries with phased migration requirements, complex software deployment estates | Real transition path. Requires both products operated in parallel. Plan its exit from day one. |
| Microsoft Entra hybrid joined (formerly Hybrid Azure AD joined) | Devices joined to on-prem AD and Microsoft Entra. GPO still applies. Intune can coexist. | Organisations that genuinely need ongoing AD line-of-sight for line-of-business apps, Kerberos-dependent services, or legacy authentication scenarios | Most complex. Two policy systems (GPO and Intune) on the same device. Hardest to operate long-term. Microsoft has signalled cloud-native as the strategic direction. |
Decision 2 — Autopilot path
For new device provisioning, decide between Microsoft Entra joined Autopilot (cloud-only) and Microsoft Entra hybrid joined Autopilot. The cloud-only path is the cleaner option and the direction Microsoft has been pushing. Hybrid Autopilot is still in product but has carried significant deprecation signals. New deployments should default to cloud-only Autopilot unless a documented requirement explicitly forces hybrid — and "we have always done it this way" is not a documented requirement. See the Windows Autopilot and Pre-Provisioning guide for the deeper Autopilot path.
Decision 3 — Settings catalog vs Administrative templates vs OMA-URI
| Mechanism | When to use |
|---|---|
| Settings catalog | Default for almost everything. The largest, most current library of supported settings. Searchable. Use this first. |
| Administrative templates | Older mechanism, still supported. Mostly subsumed by Settings catalog for new policies. Existing Administrative templates policies can stay; new ones should be in Settings catalog unless there is a specific reason. |
| Imported ADMX (custom Administrative templates) | For third-party settings whose ADMX is not built into Intune (e.g. Adobe, Chrome, third-party app settings). Upload the ADMX/ADML into Intune and deploy the imported administrative template settings. |
| OMA-URI / custom configuration | For settings not exposed in Settings catalog or Administrative templates. Last resort — harder to maintain, harder to audit, more brittle when Microsoft changes the underlying CSP. |
| PowerShell scripts / Remediations | For configuration that genuinely cannot be expressed as a policy — one-shot setup tasks, complex registry conditions, custom logic that GPO logon scripts used to handle. |
What translates cleanly, what doesn't
This is the table that should be on the project wall from week one. It is what determines whether week four is calm or chaotic.
| GPO category | Translates to | Difficulty |
|---|---|---|
| Computer Configuration → Administrative Templates (most) | Settings catalog (search by the GPO setting name) | Low — most settings have direct equivalents |
| User Configuration → Administrative Templates | Settings catalog (user scope) or Administrative templates | Low to medium — user-scope policies are supported but the model is different |
| Security Settings (account policies, audit, user rights) | Settings catalog, Security baselines, or Endpoint security policies | Low to medium — many settings are covered, but user rights, audit policy granularity, firewall nuances and legacy security options require careful validation |
| Windows Update settings | Windows Update for Business + Update rings in Intune | Low — well-documented path, see the Windows Update Rings guide |
| Software installation (MSI deployment via GPO) | Intune Win32 apps, Enterprise App Catalog, or Microsoft Store apps. MSI LOB apps can work for simple MSI deployment, but Win32 is usually the more flexible standard for enterprise packaging, detection rules and dependencies. See the Intune App Packaging Decision Guide. | Medium — same outcome, different model. Win32 packaging takes longer than expected. |
| Logon / startup scripts | PowerShell scripts (run on enrolment or schedule) or Remediations | Medium — scripts can be lifted but the trigger model is different (no logon hook) |
| Group Policy Preferences → Drive maps | Migrate to OneDrive/SharePoint where possible. Where genuinely needed, PowerShell script via Intune. | High — this is where projects get stuck. The honest answer is often "stop using mapped drives where the business process allows it." For legacy apps or manufacturing-floor scenarios, keep the mapping but treat it as a documented exception. |
| Group Policy Preferences → Printer maps | Universal Print (Microsoft), Printix or other modern printing solutions, or PowerShell script via Intune | High — cloud printing is a separate project. Budget for it explicitly. |
| Group Policy Preferences → Registry items | Settings catalog (most), PowerShell scripts, or Remediations for conditional logic | Medium — usually possible, often requires conditional logic GPP made easy |
| Group Policy Preferences → Scheduled tasks | PowerShell script or Remediations | Medium — lifts cleanly if the task is self-contained |
| Group Policy Preferences → Files / Shortcuts | PowerShell script via Intune, or Win32 app for installer-style payloads | Medium |
| Folder Redirection | OneDrive Known Folder Move (KFM) is the modern replacement for common user folders such as Desktop, Documents and Pictures — not a one-for-one replacement for every folder redirection scenario (departmental shares, redirected AppData, legacy app dependencies still require case-by-case design) | High — cultural change for users, not just configuration |
| Internet Explorer settings / IE Mode for Edge | Edge configuration policies via Settings catalog | Low to medium — well-supported but IE Mode site list deserves its own planning |
| BitLocker | Endpoint security policies in Intune (Disk encryption profile) | Low — Endpoint security Disk encryption policies handle this cleanly |
| Local administrator accounts / LAPS | Windows LAPS with Microsoft Entra ID / Intune policy support | Low to medium — well-supported, but verify the current Intune policy path and supported scenarios |
| WMI filters | Assignment filters (Intune) where the equivalent attribute exists; PowerShell logic otherwise | Medium — conceptually similar, syntactically different |
Recommended baseline
Minimum baseline (any defensible migration)
The minimum baseline is the following. A complete inventory of every GPO in the production OU with an owner, a purpose, a "kept/deprecated/replaced/retired" status, and a target Intune mechanism for everything in "replaced." A deprecation pass run before any Intune work starts — the unused GPOs are unlinked first, the operations confirmed stable, then deleted. Group Policy analytics in Intune run against every "replaced" GPO to confirm what is supported. Settings catalog as the primary destination for everything that translates cleanly. A documented strategy for each non-translatable item (Group Policy Preferences, logon scripts, software installation) with the Intune-side replacement mechanism. Pilot ring of 10 to 30 named users in real roles — not lab machines — with a defined success criterion before expanding. Compliance policy and Conditional Access wired end-to-end and validated per ring.
Recommended baseline (adds on top)
Cloud-native chosen as the target state unless a documented exception forces hybrid join. Co-management explicitly time-boxed if used at all — with named exit criteria ("co-management complete when all workloads are Intune-managed for >90 percent of the estate"). Windows LAPS configured through Intune / Microsoft Entra ID support for all migrated devices. Endpoint security baselines applied (Windows + Defender + Edge), validated and documented. Defender for Endpoint onboarded through Intune (see the Defender for Endpoint Onboarding with Intune field guide). A retirement plan for the AD OU containing migrated devices — if devices are cloud-native, they no longer need to live in that OU. A communications plan for affected users: cultural change matters as much as technical change, and "where is my drive?" tickets become "I get it now" feedback when the change is communicated well.
Recommended first 3 actions
If the team can only carve out one afternoon to start, do these three things. Each one is independently valuable and each one changes the size of everything that follows.
| First action | Why |
|---|---|
| Run the GPO deprecation pass before opening Intune | Most of the project value is in deleting configuration nobody understands — not in migrating it. The deprecation pass is the cheapest, highest-impact work in the project, and it changes the size of everything that follows. |
| Pick the target architecture in writing: cloud-native, co-management or hybrid join | Every Intune profile, every Conditional Access policy, every compliance check is shaped by this choice. Decisions deferred without record become decisions never made — and the team rebuilds the same profile three times in different shapes. |
| Stand up Group Policy analytics in Intune and import the GPO backups | This is the only honest answer to "what translates to Intune and what doesn't." It is also the artefact that turns the migration from a vibes-based exercise into one with numbers. |
Common mistakes
These are not theoretical. Each one is something I have seen in the last twelve months, often in tenants that did a lot of things right elsewhere.
- Lift-and-shift mindset.Trying to recreate every GPO in Intune as a configuration profile, one for one. I have watched the same conversation in three different organisations: "we have 340 GPOs, we need 340 profiles." The team that starts there finishes with 340 profiles nobody can audit and a maintenance burden that is worse than what they migrated from.
- Skipping the deprecation pass.The single biggest source of wasted time in any migration. A significant portion of the inventory is often unused, deprecated or contradictory. Carrying that debt into Intune does not improve it — it just changes where the debt lives.
- Underestimating Group Policy Preferences.The team scopes the project around Administrative Templates because those are visible in GPMC's familiar tree. Then they discover that the drive maps, printer maps and registry items in GPP cover more day-to-day user functionality than the entire Computer Configuration tree.
- Co-management as the destination, not the transition.Co-management is a transition path. Without named exit criteria, it becomes a permanent state of running two products in parallel and never finishing the migration. The conversation that needs to happen on day one is "what does 'co-management complete' look like, and when do we get there?"
- Forgetting Conditional Access compliance during cutover.The device moves from AD-joined to Microsoft Entra joined. It enrols in Intune. The configuration applies. The compliance policy is missing or misconfigured. The user signs in fine until Conditional Access requires a compliant device, at which point everything stops working — usually on a Monday morning.
- Not validating per-device before broad rollout.The pilot ring is 10 lab machines that nobody uses. The signal chain (device → compliance → CA) is "validated" without ever facing a real user. The first ring of real users discovers the issues the lab masked. Pilot rings must be real users.
- Treating Autopilot as a separate project.The migration plan covers existing devices but ignores how new devices arrive. Six weeks in, a new starter joins, gets handed a freshly-imaged laptop from the old imaging pipeline, and the migration team is back to square one. Autopilot is part of the migration plan, not a follow-up.
- Logon scripts that don't translate.The GPO logon script ran on every interactive logon and reacted to user identity, time of day, group membership and AD attributes. The Intune-side replacement (PowerShell script or Remediation) runs on a different trigger model. The team rewrites the logic without realising the trigger is different and is surprised when the script doesn't fire when expected.
- Drive maps as a hill to die on.The honest answer to "how do I migrate drive maps to Intune?" is often "stop using mapped drives." Move the content to OneDrive, SharePoint or Teams. Where mapped drives are genuinely required, script them via Intune — but recognise that this is the hardest, most fragile part of the project and budget for it.
- Printer maps and on-prem print servers.Same shape as drive maps. The modern answer is Universal Print, Printix or equivalent cloud printing. The lift-and-shift answer (scripts that map printers via Intune) works but is fragile and does not scale. Decide which approach the organisation will take before reaching the printer-map question.
- "We'll keep the OU for now."The migration succeeds. Devices are Microsoft Entra joined and Intune-managed. The OU in AD still exists, has no purpose, but nobody removes it because "what if?". Eighteen months later, a new admin sees the OU, assumes it is active, links a new GPO to it, and re-introduces conflict the migration was supposed to eliminate.
- Ignoring the cultural change.Endpoint admins who spent a decade in GPMC suddenly find themselves in Intune admin center. The mental model is different. The audit tools are different. The terminology is different. The migration is not just a tool change — it is a workflow change. Without explicit time for the admin team to learn the new platform, the migration is fragile after go-live.
Implementation guide
The migration is phased. Each phase has a defined output and an exit criterion. Resist the temptation to start Intune profile work before the inventory phase is complete — the rework cost is high.
Phase 1 — Inventory current GPOs
Use Group Policy Management Console or PowerShell to export every GPO in the production OUs. Get-GPOReport -All -ReportType Xml produces machine-readable output. Build the inventory register with one row per GPO: name, linked OU(s), purpose (one-line description), owner (named person), last modified date, last-known purpose status, status (kept / deprecated / replaced / retired). Where the owner field is empty, that GPO is a deprecation candidate by definition — if nobody owns it, nobody can defend it.
Phase 2 — Deprecate the dead GPOs
Walk the inventory with the endpoint and security teams. Any GPO without a clear current purpose: unlink it (not delete — unlink first). Let the change soak for two weeks. If nothing breaks, delete. In many environments, this stage retires a meaningful portion of the inventory, sometimes 30 to 60 percent. This is the part of the project that produces the most operational value per hour invested, and the part that the team is most tempted to skip in the interest of "moving faster." Do not skip it.
Phase 3 — Classify the remaining GPOs
For each surviving GPO, classify by purpose: security baseline / Administrative templates / GPP drive map / GPP printer map / GPP registry / logon script / software installation / Windows Update / other. This classification maps directly to the translation matrix above and is what tells you the difficulty distribution of the remaining work.
Phase 4 — Run Group Policy analytics in Intune
In the Microsoft Intune admin center, navigate to Devices → Group Policy analytics. Import the GPO backup/report exports. Validate the current supported import format in Intune before standardising the export process — Microsoft has iterated on what the analytics import accepts. The tool analyses each setting and marks it as supported, partially supported, deprecated, or not supported in Intune. Export the analysis. This is the artefact that converts the migration from "we think it'll work" to "we have a per-setting gap list."
Phase 5 — Pick the architecture path
Cloud-native, co-management, or Microsoft Entra hybrid joined. Document the decision and the rationale. If co-management, write the exit criteria at this point — not later. Validate the decision against on-premises dependencies (line-of-business apps requiring Kerberos, certificate enrolment via NDES, specific group memberships used by non-cloud services). For some of those dependencies, see the Microsoft Cloud PKI in Intune article for the modern replacement.
Phase 6 — Build Intune configuration profiles
In Settings catalog first. For each "replaced" GPO, find the equivalent setting in Settings catalog, build the profile, and assign to a small pilot ring. Naming convention matters: profiles should be named so that an admin two years later can read the profile name and know its purpose, scope and origin. A pattern like WIN-Sec-BitLocker-PilotRing-2026 reads better than BitLocker at scale. I have inherited tenants where every profile was named "New Policy" or "Test" — an admin discoverability disaster that is more common than it should be. Decide the naming convention once, document it, enforce it from profile one. The Settings Catalog guide covers the mechanics in depth.
Phase 7 — Address non-translatable items
For each Group Policy Preferences item, logon script and software installation GPO, document the replacement mechanism: OneDrive KFM for folder redirection, Universal Print (or equivalent) for printers, PowerShell scripts / Remediations for scheduled tasks and conditional registry settings, Win32 apps for software installation. Build each replacement, test in the pilot ring, validate the end-user experience before broadening.
Phase 8 — Build the compliance + Conditional Access signal chain
Compliance policy in Intune that reflects the security posture of a migrated device (encrypted, up to date, Defender active, etc.). Conditional Access policy that requires a compliant device for the relevant cloud apps. Roll out CA in Report-only mode first, then enforce per ring. The Intune Compliance Policy Builder 2026 covers the compliance side; the Conditional Access Architecture Framework covers the CA side.
Phase 9 — Pilot ring with real users
10 to 30 named users in real roles — not lab machines. The pilot soaks for at least two weeks. Track tickets, capture feedback, document anything that did not translate as expected. The pilot is where you find the GPO that turned out to be load-bearing despite having no owner, the script that fires at the wrong time, the printer map that everyone forgot. Better to find it here than at scale.
Phase 10 — Expansion rings
Expand in waves. A common cadence: pilot → early adopters (department-scale, 50 to 200 users) → broad (rest of the estate). Between rings, run the post-ring review: what worked, what surprised, what should change before the next ring. Resist the urge to push tickets out of one ring into the next without resolving them — the unresolved issues compound.
Phase 11 — Cutover
For each ring, the cutover step is: unlink the relevant GPOs from the migrated devices' OU (or move the devices to an OU with no GPOs linked), confirm the Intune policy is doing the work, validate compliance + CA signal. Devices that are being rebuilt or provisioned as cloud-native should not remain operationally dependent on the old AD OU — plan AD object cleanup carefully, because removing an in-place device from AD without rejoin or reprovision is not always a clean operation. Devices remaining Microsoft Entra hybrid joined stay in AD but with the GPO link removed. Cutover is the irreversible point — have the rollback documented even if it is never used.
Phase 12 — Decommission
After the broad ring is stable for at least one quarter, retire the OU that held the migrated devices (or document why it cannot be retired). Archive the GPO inventory register as a historical artefact — you will reference it when someone asks "why did we do it this way?" three years from now.
Validation checklist
After implementation, the following must be true. Each item is a yes/no. Any "no" should pause broad rollout until the gap is understood and either fixed or formally accepted as an exception.
-
GPO inventory complete and classified. Every GPO in the production OUs is in the register with owner, purpose, status and target Intune mechanism. Unowned GPOs flagged for deprecation.
-
Deprecation pass executed before Intune work started. Unused GPOs unlinked, soaked, and deleted. The Intune project is not carrying old debt.
-
Group Policy analytics report produced and exported. Per-setting gap list available. Unsupported settings have a documented alternative.
-
Architecture path documented (cloud-native / co-management / hybrid join). Decision in writing with rationale. If co-management, exit criteria defined.
-
Settings catalog profiles built for every "replaced" GPO. Naming convention applied. Scopes documented. Assignments use the pilot ring first.
-
Non-translatable items handled. Drive maps, printer maps, scripts, software installation each have a documented Intune-side replacement that has been built and tested.
-
Autopilot path configured for new devices. New devices arrive into the new model, not the old. Old imaging pipeline retired or explicitly preserved with documented justification.
-
Compliance + Conditional Access signal validated end-to-end. Test sign-in from a migrated device produces the expected CA outcome. Test sign-in from a non-compliant device produces the expected block.
-
Pilot ring soaked with real users for at least two weeks. Tickets captured, feedback documented, anomalies resolved before broader rollout.
-
Cutover step documented per ring with rollback plan. Unlink GPOs, confirm Intune doing the work, validate. Rollback path written even if unused.
-
Post-migration operating model documented and owned. Named owner for ongoing Intune changes. Cadence for profile review. Process for adding new settings.
-
OU containing migrated devices retired or documented. If devices are cloud-native, the OU is removed. If retained, the reason is recorded so a future admin does not re-link a GPO to it.
Putting it together — worked scenario
I have run this scenario in roughly this shape three or four times. The numbers below come from a recent engagement, lightly anonymised. A 1,500-user manufacturing company with eight years of accumulated Group Policy. The production OU has 340 GPOs. The Intune licences have been in place for a year but only 220 devices are enrolled (mostly the new starters). Internal audit flagged "endpoint configuration debt" as a Tier 1 finding. The leadership commitment was 12 months to be predominantly cloud-native; this is the 90-day readiness path that fit.
Weeks 1–2. GPO export and inventory. Get-GPOReport -All -ReportType Xml produced 340 GPO definitions. The register was built in a Microsoft List with the columns described above. Endpoint and security teams walked the list together. By the end of week 2: 198 GPOs flagged as deprecation candidates (no owner, no purpose), 142 as kept-or-replaced. That single afternoon of honesty changed the project scale.
Weeks 3–4. Deprecation pass. The 198 candidates were unlinked. The change soaked for two weeks. Three GPOs were re-linked after issues surfaced (two were genuinely needed; one turned out to be load-bearing despite having no documented owner — classic). Net: 195 GPOs deleted. The remaining 147 GPOs were classified by purpose.
Weeks 5–6. Group Policy analytics in Intune run on the surviving 147. Output: 109 GPOs translate cleanly to Settings catalog, 23 partially, 15 unsupported. The 15 unsupported items were almost entirely Group Policy Preferences (printer maps, drive maps, scheduled tasks) and one logon script. The team built the per-item replacement plan: Universal Print for printers (separate project, agreed timeline), OneDrive KFM for the documents share (folder redirection equivalent), PowerShell script via Intune for the logon-script equivalent.
Weeks 7–8. Architecture decision: cloud-native target with co-management as a six-month transition for the manufacturing-floor devices that still needed AD line-of-sight for a legacy production system. Exit criterion: "co-management ends when the legacy production system is replaced or modernised, scheduled for Q3 next year." Compliance + Conditional Access wired. Settings catalog profiles built for the 109 clean-translation GPOs. Naming convention applied. Pilot ring identified: 25 users across IT, finance, marketing and engineering — deliberately not the easy roles.
Weeks 9–10. Pilot ring cutover. Devices enrolled in Intune, AD GPO links removed from those devices, compliance signal validated. Twelve tickets in the first week, four in the second — mostly printer issues that confirmed the Universal Print project timeline was the right one. One ticket revealed a GPO that delivered a registry setting nobody had thought about; the setting was added to a new Settings catalog profile.
Weeks 11–12. Expansion to the 200-user early-adopter ring (finance, IT, marketing departments). Ticket volume scaled linearly with users, not exponentially. Post-ring review identified two profile name conventions to adjust, three Settings catalog values to refine. End of 90 days: 225 devices fully migrated; cutover plan for the remaining 1,275 devices on quarterly waves through the rest of the year, with the manufacturing-floor cohort in co-management awaiting the production system modernisation.
What to fix first
For migrations already in progress that have lost momentum or visibility, fix in this order.
| Finding | Fix first | Why |
|---|---|---|
| No documented GPO inventory or classification | Build the register first, even retroactively | Without it, the team cannot answer "are we done?" — and projects without that answer never finish. |
| GPOs being migrated one-for-one without deprecation pass | Stop. Run the deprecation pass. Resume with the smaller set. | The biggest single source of saved time in the whole project. |
| No architecture decision in writing | Make the decision. Write it down. | Without it, every Intune profile is shaped by an implicit assumption that someone else may not share. |
| Pilot ring is lab machines, not real users | Move the pilot to real users in real roles | Lab pilots produce false confidence that ends at the first real ring. |
| Group Policy Preferences items not addressed | Identify drive maps / printer maps / scheduled tasks / registry items; build replacements | This is the part that breaks at scale. It cannot be a "we'll figure it out later" item. |
| Co-management running with no exit criteria | Write the exit criteria now | Without them, co-management becomes the destination, and the migration never finishes. |
| OU for migrated devices still has GPOs linked | Unlink them as part of the cutover step | Cutover is incomplete until the GPO can no longer apply. Forgotten links cause silent drift. |
Troubleshooting notes
Setting applied in Intune does not take effect on the device
Most common cause: an existing GPO is still applying the same setting with a different value, and the AD-joined device evaluates GPO at logon. Run gpresult /h on the device, find the conflicting GPO, unlink it from the migrated devices' OU. Less commonly, the Intune profile is assigned to a Microsoft Entra group the device is not in, or the assignment filter excludes the device.
Device enrolls in Intune but no profiles apply
Check that the device shows in Devices → All devices with the expected join type (Microsoft Entra joined for cloud-native, Microsoft Entra hybrid joined otherwise). Check the assignment of the Settings catalog profile: is the device in the assigned group? Has the device checked in since assignment? Force a sync from the device (Settings → Accounts → Access work or school → Sync) and re-check after 15 minutes.
Conditional Access blocks the user after cutover
Almost always a compliance signal issue. Check the device compliance state in Intune: is the device showing compliant? Check the compliance policy: does it apply to the right Microsoft Entra group, and does the device meet all of its conditions? Check the CA policy: is the device-compliant grant control correctly configured? Pair this troubleshooting with the Conditional Access Report-only Rollout 2026 article — the same patterns apply.
"Where is my drive?"
Drive map ticket on day two of cutover. Either the Intune-side script that maps the drive did not run, or the drive map has not been built in Intune at all, or the underlying content has moved to OneDrive/SharePoint and the user expectation has not been reset. Confirm which of the three is happening before acting — the answer determines the fix.
Group Policy analytics shows a setting as "deprecated"
The setting was supported in Group Policy but has been deprecated in modern Windows / Intune. Validate against Microsoft documentation whether the underlying functionality still exists under a different name (often) or has been removed (sometimes). Deprecated settings are an opportunity to ask whether the function is still required — deprecation is sometimes a hint that the underlying behaviour was a workaround for a problem that no longer exists.
New starter received an old-imaging-pipeline laptop
The Autopilot path was not in place when the new device was provisioned. Either the device should be re-provisioned through Autopilot (cleanest), or the device should be enrolled into Intune after-the-fact and the AD-joined state retired. The fix is to ensure Autopilot is in place before the next new starter cohort — this should not have been possible.
Operational model
Migration is not a project that ends on go-live. After cutover, the following cadence keeps the new model defensible.
| Cadence | Owner | Activity |
|---|---|---|
| Weekly | Endpoint team | Review Intune device compliance dashboard. Triage non-compliant devices. Investigate failed configuration profile applications. |
| Monthly | Endpoint team | Review Intune profile assignments. Confirm no profile drift. Validate assignment filters still target the right populations. |
| Monthly | Migration lead | Co-management progress check (if applicable). Are workloads shifting per plan? Is the exit criterion closer? |
| Quarterly | Endpoint team + Security team | Endpoint security baseline review. Defender posture review. Compliance policy review against current threat landscape. |
| Quarterly | Identity team | Audit Microsoft Entra joined vs hybrid joined device counts. Confirm hybrid-joined devices still need to be. |
| Annually | Architecture review | Re-validate the architecture decision. Cloud-native vs co-management trends evolve. The decision that was right last year may be revisitable. |
Ownership matters. The endpoint team takes the configuration profiles. The security team takes the compliance and baselines. The identity team takes the CA layer. The migration lead owns the co-management exit criteria if those exist. Without named owners, the post-migration model drifts back to the kind of unowned configuration debt the migration was supposed to leave behind.
Final thoughts
GPO-to-Intune is not a tool swap. It is the chance to leave behind a decade of accumulated endpoint configuration debt and operate the endpoint estate in a model that fits a cloud-first organisation. The teams that get the most from the migration are not the ones with the most profiles built — they are the ones that deleted the most GPOs in the deprecation pass and rebuilt only what the organisation actually needed.
The hard part is not Intune. Intune is well-documented, supported and increasingly capable. The hard part is the cultural and architectural shift: from logon-time, OU-anchored, hierarchical configuration to identity-anchored, check-in-time, group-assigned configuration. The teams that succeed are the ones that recognise the shift and budget time for the team to learn the new model, not just the new tool. In the migrations that go well, the project plan has a "team learns Intune" line item with hours allocated. In the ones that struggle, that line item was assumed.
If the migration is already in progress and the team cannot answer "yes" to every item in the validation checklist, the gap is usually not the configuration. It is the operating model around the configuration — the deprecation pass that was skipped, the inventory that was never built, the architecture decision that was never written down. The fix is closer than it looks. The longer it sits, the harder the rest of the project becomes.
- Group Policy analytics in Microsoft Intune
- Use the settings catalog to configure devices
- Use Administrative Templates in Intune to configure Windows devices
- Co-management for Windows devices (Microsoft Configuration Manager + Intune)
- Windows Autopilot overview
- Microsoft Entra hybrid joined devices
- Windows LAPS overview (including Microsoft Entra ID support)
- Microsoft Universal Print documentation
- OneDrive Known Folder Move (KFM)
- Microsoft Intune security baselines
- Assign Intune device configuration profiles — assignment filters and scope tags
- Intune management extension — PowerShell scripts and Remediations
Start with the deprecation pass
Of all the work in a GPO-to-Intune migration, the single highest-impact step is the deprecation pass before any Intune work begins. Half the inventory does not need to migrate. Walk it with the security and endpoint teams, retire what nobody owns, and watch the project shrink to its real shape.
Start with the First 3 Actions