Group Policy to Intune Migration: Move Settings Without Losing Security Controls

Moving Windows devices from Group Policy to Intune is where security settings quietly go missing: a GPO that applied 300 settings becomes a settings catalog profile with 180, and nobody notices the other 120 until an audit or an incident. This playbook is for endpoint and identity teams moving to Entra joined, Intune managed Windows devices. It covers inventorying GPOs, using Group Policy analytics, choosing between the settings catalog, security baselines, endpoint security policies and imported ADMX templates, handling settings with no MDM equivalent, resolving conflicts and precedence during co-existence, testing in rings, and retiring GPOs safely. For securing each side, see the Group Policy Security Guide and the Microsoft Intune Guide. Product behaviour described here was checked against Microsoft Learn on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Group Policy is not being retired, but Microsoft says Entra join should be the default for new and reset endpoints, and Entra joined devices do not process domain GPOs, so the move is driven by the device join model, not a deadline.
• Group Policy analytics tells you what maps, not what matters. An MDM Support percentage of 90% can still hide the one unmapped setting your auditors rely on, so review unsupported settings by risk, not by count.
• Rebuild security settings from baselines, migrate the rest. Use Intune security baselines and endpoint security policies for the security core, and the analytics Migrate feature for application and user experience settings.
• Co-existence is the dangerous phase. On hybrid joined devices both channels can set the same value; MDMWinsOverGP only covers Policy CSP settings, so everything else is a race you must prevent by design.
• Decommission GPOs by unlinking, not deleting. Back up, unlink per OU after the ring is stable, keep the backup for rollback, and only then delete, so a missed setting can be restored in minutes.

What is changing and why

Group Policy applies settings to computers and users that are members of an Active Directory domain, delivered from domain controllers over SMB and LDAP. Intune applies settings through the Windows MDM channel using configuration service providers (CSPs), delivered over the internet to devices that are enrolled. The change is not a product retirement; it is a change in how devices are joined and managed.

• Device identity: Microsoft's guidance on join types states that "Microsoft Entra Join should be your default option for new and reset endpoints" and that hybrid join "shouldn't be long term nor the end goal for any organization". Entra joined devices are not domain members, so domain GPOs do not reach them. See the Entra Device Identity guide.
• Delivery model: Microsoft describes cloud-native endpoints as Autopilot deployed, Entra joined and MDM enrolled, and "recommends that organizations focus on adopting cloud-native endpoints".
• Setting model: a GPO setting is usually a registry value under a Policies key written by a client-side extension. The Intune equivalent is a CSP node, for example ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption. Many settings exist on both sides; some exist only in Group Policy.

Official timeline and current status

There is no Microsoft end date for Group Policy, and none of the official pages checked for this guide announce one (checked 8 November 2026). The dates that do constrain a migration are the ones around it:

Microsoft's advice is to change join type at a "complementary event" such as a hardware refresh, OS upgrade or a reset during troubleshooting. Most organisations therefore run both channels for at least one refresh cycle, so co-existence design matters more than the cut-over date.

Who and what is affected

• Identity and directory teams: GPO ownership, delegated rights on GPOs and OUs, and the domain itself change role. GPO edit rights remain a privilege escalation path while any device still processes them (MITRE ATT&CK T1484.001 Group Policy Modification).
• Security operations: detections that watch GPO changes (directory service change event 5136 on Group Policy containers) need an Intune equivalent: audit logs for policy changes and Multi Admin Approval.
• Audit and compliance: evidence of configuration moves from GPO reports and RSOP output to Intune per-setting reports and baseline status.
• Service accounts and machine credentials: GPO-driven scheduled tasks or scripts that run with stored credentials are non-human identities. Re-platforming is the moment to remove embedded passwords rather than copy them into an Intune script. See the Service Account Security Guide.

Finding affected systems and identities

Step 1: inventory GPOs and their reach

1. Export every GPO, its links, enforcement, security filtering, WMI filters and delegation from the Group Policy Management Console or the GroupPolicy PowerShell module. Record which OUs the target devices sit in.
2. Use Policy Analyzer from the Microsoft Security Compliance Toolkit to find redundant and conflicting settings across GPOs before you migrate them, and export the comparison to Excel as your working register.
3. Capture the effective result on a representative device per persona (RSOP or gpresult) so you test against what devices actually receive, not what GPOs claim.

Step 2: run Group Policy analytics

Save each GPO as an XML report from GPMC (Save report, type XML File) and import it under Devices, Manage devices, Group Policy analytics. Each file must be under 4 MB with proper Unicode encoding; larger GPOs fail and must be split. The import needs the Intune administrator role or a role with the Security baselines and Device Configuration permissions, and scope tags chosen at import control which admins can see the result.

Two limits matter. Analytics parses the Policy, PassportForWork, BitLocker, Firewall and AppLocker CSPs plus Group Policy Preferences; anything else may show as unknown. And Microsoft states the tool only supports non-ADMX settings in English, so GPOs authored in other languages give an inaccurate MDM Support figure.

Step 3: classify every Not supported setting

• Not applicable to cloud-native devices: domain controller settings, Kerberos settings that only matter for domain sign-in, folder redirection to on-premises shares. Drop them, with a note.
• Replaced by a different control: drive maps replaced by OneDrive or SharePoint, printer GPOs by a cloud print service, legacy LAPS by Windows LAPS.
• Still required, no CSP: deliver by a Remediations package or platform script that writes and checks the value, owned and reviewed like code.
• Security-relevant with no replacement: escalate as a risk acceptance; do not silently drop it.

Migration options

Decision guidance: rebuild security settings rather than translate them. Intune baselines come from the same Microsoft team as the GPO baselines, minus domain controller settings. Diff the two with Policy Analyzer, carry over your deliberate exceptions, and let the rest go. Use the Migrate feature for the long tail of browser, Office and usability settings. Small organisations with a handful of GPOs can rebuild entirely in the settings catalog; large estates should consolidate first, since Microsoft warns against migrating all GPO settings without review. See the Microsoft Security Baselines and Security Compliance Toolkit Guide.

Conflict and precedence during co-existence

• Entra joined devices: only Intune applies. Conflicts are between Intune policies: when two configuration policies set different values Intune reports a conflict and you resolve it manually; a compliance policy setting takes precedence over the same setting in a configuration profile.
• Hybrid joined devices: both channels apply. Set ControlPolicyConflict/MDMWinsOverGP to 1 (Windows 10 1803 and later) so that for Policy CSP settings with a Group Policy equivalent the MDM value wins and the GP value is blocked. Microsoft is explicit that it does not cover other CSPs such as the Defender CSP, and that configuring the same setting in both channels otherwise creates "a race condition and no guarantee which one wins".
• Windows Update: Microsoft recommends IgnoreWindowsUpdateGroupPolicies rather than MDMWinsOverGP for update settings.
• Verification: the MDM Diagnostic report on the device (Settings, Accounts, Access work or school, Advanced Diagnostic Report) lists GP settings that MDM blocked.

The safe pattern is to stop the GPO reaching a device when the Intune profile arrives (move it to an OU without the link, or deny Apply Group Policy to a pilot group) rather than rely on precedence.

Testing and rollback

1. Ring 0, IT test devices: fresh Autopilot builds, Entra joined, with the new profiles. Compare effective settings with the step 1 gpresult capture and record every difference.
2. Ring 1, IT staff and willing users (about 1 to 2%): real workloads for two weeks. Watch per-setting status in each profile, baseline status, and helpdesk tickets tagged to the pilot.
3. Ring 2, representative departments (about 10%): include one team with line-of-business apps that relied on custom ADMX or Preferences.
4. Ring 3, broad deployment: by refresh or reset wave, targeted by groups or filters.
5. Hybrid devices that stay hybrid: migrate one GPO family at a time. For each, assign the Intune profile, then unlink the GPO from the pilot OU, confirm, and widen.

Rollback: take a GPMC backup of every GPO before you unlink it. To roll back a hybrid device, relink the GPO and unassign the Intune profile; remember that setting MDMWinsOverGP back to 0 restores saved GP policies (Windows 10 1803 excepted, so confirm that version's rollback path with Microsoft). Allow for timing: Microsoft notes that removing a profile after group removal can take up to 7 hours or more, and maintenance syncs run roughly every 8 hours, so do not judge a rollback after ten minutes. Entra joined devices have no GPO to fall back to, so ring 0 must be thorough.

Risks of doing nothing

• Unmanaged new devices: devices provisioned as Entra joined while settings stay in GPO receive no configuration at all, which is worse than either model.
• Remote devices drifting: hybrid joined devices need line of sight to a domain controller for policy refresh, so remote users drift. See the Configuration Drift and Baseline Enforcement Guide.
• Persistent attack path: GPO edit rights remain a domain-wide code execution route for attackers who reach Active Directory.

Common failure patterns

• Signing off on percentages: treating 85% MDM support as success while an unmapped audit policy or user right goes unreplaced.
• Dual delivery without control: leaving GPOs linked to hybrid devices and assuming MDM wins, when the setting lives in a CSP that MDMWinsOverGP does not cover.
• Multiple owners per setting: the same BitLocker or Defender setting in a baseline, an endpoint security policy and a catalog profile, producing permanent conflicts.
• Copying credentials into scripts: moving a GPO Preferences task that stored a password into an Intune script, re-embedding a static secret.
• Deleting GPOs first: deleting rather than unlinking, leaving no quick rollback when a missed setting surfaces.

Measuring progress

• Percentage of in-scope settings classified (migrated, replaced, accepted, dropped), target 100% before ring 3.
• Number of open Intune configuration conflicts, target zero.
• Devices reporting baseline compliance in Endpoint security, Security baselines.
• GPOs still linked to OUs containing in-scope devices, trending to zero.
• Helpdesk tickets per 100 migrated devices in the two weeks after each wave.

Practitioner checklist

• Export and back up every GPO with links, filters and delegation; set aside unlinked and empty GPOs.
• Run Policy Analyzer to remove redundancy and conflicts before importing to Group Policy analytics.
• Import GPO XML reports (under 4 MB each) and classify every Not supported and Unknown setting by risk.
• Rebuild the security core from current Intune security baselines and endpoint security policies, carrying only documented exceptions.
• Assign one owner and one policy per setting; resolve all Intune configuration conflicts.
• On hybrid devices, set MDMWinsOverGP and IgnoreWindowsUpdateGroupPolicies, and still stop GPOs reaching migrated devices.
• Replace stored credentials in GPO tasks and scripts instead of copying them into Intune.
• Pilot in rings, comparing effective settings against gpresult captures from the original estate.
• Unlink GPOs per OU only after each ring is stable; keep backups and delete after an agreed retention period.
• Protect Intune with scoped roles and Multi Admin Approval, since it now carries the authority GPO rights used to hold.

Standards and references

• Microsoft Learn: Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune
• Microsoft Learn: Migrate your imported GPOs to a settings catalog policy in Microsoft Intune
• Microsoft Learn: ControlPolicyConflict Policy CSP
• Microsoft Learn: Import custom ADMX and ADML administrative templates into Microsoft Intune
• Microsoft Learn: Microsoft Entra joined vs. hybrid Microsoft Entra joined in cloud-native endpoints
• Microsoft Learn: Use security baselines to configure Windows devices in Intune
• Microsoft Learn: Microsoft Security Compliance Toolkit
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Group Policy Security Guide · Microsoft Intune Guide · Configuration Manager to Intune · Local Administrator Password Solution (LAPS) Guide · Microsoft Security Baselines and Security Compliance Toolkit Guide