GPO to Intune Migration Strategy: Co-Management, ConfigMgr, and MMAT Insights · CloudEngineerHub
SCCM / MECM13 min read19 views
GPO to Intune Migration Strategy: Co-Management, ConfigMgr, and MMAT Insights
A staged GPO-to-Intune migration: Backup-GPO and MMAT assessment, rationalizing dead policy, and co-management workload slides from compliance to client apps — with rollback windows per ring.
C
CloudEngineerHub Team
Published: September 15, 2026· Last Updated: October 28, 2026·13 min read
GPO to Intune Migration Strategy: Co-Management, ConfigMgr, and MMAT Insights
Nobody migrates "a few GPOs." Real estates carry hundreds of Group Policy objects accumulated over a decade, complete with dead links, duplicated settings, and Group Policy Preferences registry hacks from admins long gone. A successful move to Intune is a governance project with tooling support — not a lift-and-shift. Here is the sequence that works, with assessment tools and the co-management bridge.
Visual Walkthrough
Where every classic GPO behavior lives in modern management.
Side-by-SideGPO → Intune — Translation Map6/6
Group Policy
on-prem AD
Intune
cloud authority
ADMX templates + GPP
Settings Catalog + ADMX ingestion
Domain membership required
Entra identity, anywhere check-in
VPN/line-of-sight refresh
Push notification + 8h cycle
gpresult / RSoP reporting
Per-setting reports in portal
Scripts via GPO preferences
Platform scripts / remediations
GPO → Intune — Translation Map. Group Policy vs Intune. Group Policy: ADMX templates + GPP · Intune: Settings Catalog + ADMX ingestion — Group Policy: Domain membership required · Intune: Entra identity, anywhere check-in — Group Policy: VPN/line-of-sight refresh · Intune: Push notification + 8h cycle — Group Policy: gpresult / RSoP reporting · Intune: Per-setting reports in portal — Group Policy: Scripts via GPO preferences · Intune: Platform scripts / remediations
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Inventory access: Group Policy Management Console rights for Backup-GPO, plus a device list per OU for assessment tools.
Assessment tooling: the Microsoft MDM Migration Assessment Tool (MMAT), or Group Policy analytics in Configuration Manager if you run it.
For the co-management bridge: Configuration Manager with Entra hybrid join, a cloud management gateway (CMG), and Entra user discovery enabled.
Licensing: Intune licenses for the co-managed population, plus Windows 10/11 Enterprise entitlements for remediations-era parity.
A ring model with rollback windows defined per ring — this is a change-management project as much as a technical one.
Assess and Rationalize Before You Migrate
Backup first, always:
PowerShell
1
2
3
4
Import-Module GroupPolicy
Backup-GPO -All -Path C:\GPO-Backup
Get-GPOReport -All -ReportType Html -Path C:\GPO-Reports\All-GPOs.html
# Expected output: a backup folder per GPO plus one consolidated HTML report for the review workshop
Then assess MDM coverage. The MMAT ingests a device list, examines the GPO settings those devices receive, and reports which settings have MDM/Intune CSP equivalents — invaluable for scoping the true gap. MMAT is aging and does not know every new CSP, so treat its output as a floor, not a ceiling, and spot-check unusual settings against current MDM coverage tables. If you run Configuration Manager, Group Policy analytics imports GPO backups and produces a modern CSP-support report with suggested Intune policies.
Expect the classic result: a large share of GPOs are obsolete, duplicated, or irrelevant. Rationalize aggressively before converting anything — translating dead settings into Intune profiles is pure waste and doubles your future review surface. Fold legacy GPP registry tweaks into settings catalog profiles, and use Administrative Templates only where an ADMX-backed setting has no settings catalog equivalent yet; the settings catalog is Microsoft's forward investment and where new CSP coverage lands first.
How Migration Actually Works: Management Authority
Interactive FlowGPO to Intune migration flow6/6
1Inventory GPOs (MMAT / GPA)
2Map settings to Intune profiles
3Discard obsolete settings
4Pilot group
5Monitor drift
6Bulk migrate + remove GPO links✦
GPO to Intune migration flow. Full text: Inventory GPOs (MMAT / GPA)
Map settings to Intune profiles
Discard obsolete settings
Pilot group
Monitor drift
Bulk migrate + remove GPO links
The core mechanic is management authority: while a device is GPO-managed, Group Policy applies its settings at every refresh; Intune applies its profiles over MDM independently. During overlap the settings fight — same registry key, two writers — so the migration order is really a cutover plan: Intune profile lands first (verified), then the GPO link is disabled for that ring, never the reverse. Co-management formalizes this with workloads: ConfigMgr hands a workload (say, device configuration) to Intune for a pilot collection, and only devices in that collection take policy from Intune. That's why co-management is the controlled bridge — the switch is per-collection and reversible, unlike a GPO link deleted in a hurry.
Co-Management as the Controlled Bridge
For ConfigMgr estates, co-management is the migration runway. Prerequisites: Entra hybrid join, a cloud management gateway (or cloud distribution points), and Entra user discovery. Piloted devices report co-managed state in both consoles — the ConfigMgr client applet shows the Co-managed label, giving you per-device source of truth during the slide. Enable co-management from the ConfigMgr console under Administration → Cloud Services → Co-management, then slide workloads from the pilot collection to all devices in decreasing-risk order:
Compliance policies — Intune compliance + Conditional Access is the end-state anyway.
Device configuration — the point where ADMX-based settings become Intune profiles.
Windows Update settings — WUfB rings replace SUP-driven updates.
Resource access — Wi-Fi, VPN, certificates move to Intune profiles.
Endpoint protection — Defender policy from the MDE connector.
Client apps — then Office Click-to-Run last, when app deployment is proven.
Once the device configuration workload belongs to Intune, ADMX-based settings flow as Intune profiles. Verify parity with gpresult /h report.html on pilot machines plus Intune's per-setting status reports before decommissioning the source GPOs, and keep a rollback window per ring — the ConfigMgr agent can reclaim a workload if something regresses. Collect MDM-side diagnostics when something does not land:
PowerShell
1
2
3
# Collect MDM diagnostic state for policy-not-applying tickets
MdmDiagnosticsTool.exe -area"DeviceEnrollment;DeviceProvisioning;AutoEnroll" -zip C:\Temp\mdmdiag.zip
# Expected output: 'Succeeded' and a zip with the HTML report + enrollment/autopilot event logs
Plan the end state explicitly: Autopilot for new builds (no OSD task sequence for standard images), MDM-only policy, and a shrinking ConfigMgr footprint retained only for exceptional OS deployment needs.
Real-World Enterprise Scenario: 380 GPOs to 46 Intune Profiles
A manufacturer inherited 380 GPOs from a 2009 domain. The workshop pass — backup, HTML report, MMAT output, and two hours per OU with the OU owners — classified 41% of settings as obsolete, 18% as duplicated, and 12% as GPP registry hacks rewriteable as settings catalog rows. Only 138 GPOs survived into conversion, producing 46 Intune profiles. Co-management slid workloads over eight rings in ten weeks; each ring had a two-week rollback window during which the ConfigMgr client could reclaim device configuration. Total helpdesk impact: 41 tickets, none structural. The lesson the team recorded: rationalization, not tooling, cut the project from a year to a quarter.
Troubleshooting
Symptom
Likely cause
Fix
Intune profile applied but setting unchanged on device
GPO still applying the same setting
Disable the GPO link for that ring; verify with gpresult /h
Device not showing as co-managed
Workload slide not configured, or hybrid join broken
Check co-management configuration and Entra hybrid join state
Settings catalog missing an ADMX setting
No CSP equivalent yet
Use Administrative Templates profile for that setting; track CSP coverage updates
CMG clients can't reach management point
Certificate or client-auth chain issue
Verify CMG TLS cert and the client authentication certificate on the CMG
Workload reverted unexpectedly
Rollback executed by the ConfigMgr admin
Coordinate workload slides via change management — both consoles need one owner
Compliance policies first — least invasive, fastest feedback.
switch 2
3
Switch device config
Intune becomes authority for configuration profiles.
switch 3
4
Switch updates & endpoint security
WUfB + Defender policies move under Intune authority.
switch 4
5
Switch apps & Office
Win32 + Click-to-Run complete the migration surface.
6
Steady state
Both consoles live; reports show which authority owns what.
Continuous cycle
Co-Management — Workload by Workload. 1. Enable co-management: SCCM agent + Entra hybrid identity + license verified. — 2. Pilot workloads: Compliance policies first — least invasive, fastest feedback. — 3. Switch device config: Intune becomes authority for configuration profiles. — 4. Switch updates & endpoint security: WUfB + Defender policies move under Intune authority. — 5. Switch apps & Office: Win32 + Click-to-Run complete the migration surface. — 6. Steady state: Both consoles live; reports show which authority owns what.
Best Practices
Backup-GPO before anything; keep the HTML report as the rationalization workshop artifact.
Migrate in rings with defined rollback windows; never big-bang the workload slide.
Prefer settings catalog over Administrative Templates when both exist.
Convert GPP registry hacks into documented settings catalog rows, not blind custom profiles.
Define the end state in the charter: Autopilot new builds, MDM-only policy, ConfigMgr by exception.
Security Considerations
Migration windows are security-relevant: duplicate firewall, BitLocker, and Defender settings from two sources create drift that attackers and auditors both notice. Keep security workloads (endpoint protection, BitLocker via MDM with key escrow) in the co-management slide order only after configuration is proven, and validate encryption state on migrated devices immediately. Finally, retire unused GPO passwords (GPP cpassword) as part of rationalization — decade-old credentials in SYSVOL are a standing finding.
FAQ
Do I need Configuration Manager to migrate GPOs to Intune?
No — native Intune tenants migrate via backup/rationalization + settings catalog rebuilds. Co-management and Group Policy analytics simply make large ConfigMgr estates safer and faster.
What exactly is MMAT?
The Microsoft MDM Migration Assessment Tool: feed it device lists, and it reports which GPO settings those devices receive and whether MDM equivalents exist. Aging but still the fastest scoping pass.
What is the workload slide order for co-management?
Compliance policies → device configuration → Windows Update → resource access → endpoint protection → client apps → Office Click-to-Run — decreasing-risk order.
When is it safe to delete a source GPO?
After the corresponding Intune profile verifies per-setting on pilot devices AND the GPO link is disabled for a rollback window with no regression. Disable first, delete last.
How long should a rollback window be?
One to two weeks per ring — long enough to catch scheduled tasks and monthly update cycles, short enough to keep momentum.
Conclusion
Migration is twenty percent tooling and eighty percent governance. Backup, rationalize hard, use MMAT or Group Policy analytics to scope reality, slide co-management workloads in decreasing-risk order, and verify per-ring before decommissioning anything. Prove your readiness with /mock practice exams, speed up policy conversion with /tools, and arm the whole team with the /store learning packs.
Comments
0No comments yet — be the first to share your thoughts.