GPO to Microsoft Intune: Practical Cloud-First Migration Guide

For many organizations, Group Policy Objects (GPOs) remain the backbone of Windows configuration. But once devices join Azure — or rather Microsoft Entra ID — without a local Active Directory domain, GPOs no longer apply. This guide is for systems administrators and cloud engineers who must drive this transition in production, with a reproducible method and concrete tools.

Three scenarios, three distinct paths

The first mistake is treating GPO → Intune migration as a single, uniform project. Microsoft Intune is designed to manage devices whether they're on the corporate network or not, whereas GPOs assume a device joined to the domain and reachable by a domain controller. The logical starting point is therefore to segment your fleet by junction type.

Scenario 1 — Cloud-native devices (Microsoft Entra joined)

For any new Microsoft Entra joined device (formerly Azure AD joined), start with a clean slate. Build a cloud-first configuration rather than reproducing GPO history. The recommended sequence:

1. Apply Microsoft Intune security baselines as a foundation.
2. Add validated business settings (OneDrive Known Folder Move, Microsoft Edge, BitLocker encryption).
3. Don't reproduce legacy settings without validating their current relevance.

Scenario 2 — Selective transition of existing settings

If certain behaviors must be preserved (regulatory constraints, line-of-business software), evaluate and rationalize existing GPOs, then recreate in Intune only the settings that are truly necessary and supported. This is deliberate replatforming, not cloning.

Scenario 3 — GPO + Intune coexistence (hybrid)

Hybrid Microsoft Entra joined devices can simultaneously receive both GPO and Intune settings — this is the typical case for co-managed environments with Windows Autopatch or co-management ConfigMgr. This coexistence can last a long time, but it requires rigorous coordination of targeting to avoid conflicts.

Evaluate and rationalize before touching anything

The classic pitfall is rushing into Intune with existing GPOs without questioning their relevance. Most mature environments accumulate obsolete, duplicate, undocumented GPOs, or those applied to overly broad OUs. Migrating this technical debt to Intune perpetuates it.

Audit actions to conduct before the transition

• Export all GPOs from the Group Policy Management Console (GPMC) in XML format.
• Run Gpresult on representative devices to identify GPOs actually being applied.
• Delete or archive unused, redundant, or inherited GPOs before any transition decision.
• Categorize required settings: security, update management, device restrictions, application control, legacy dependencies.
• Document device populations and business requirements associated with each policy.

The following script generates an HTML report of all domain GPOs via GPMC:

1# Prerequisites: GroupPolicy module (installed with RSAT on Windows)
2# Minimum role: read access on all domain GPOs
3# Output: HTML file per GPO in C:\GPO_Export
4 
5Import-Module GroupPolicy
6 
7$OutputPath = "C:\GPO_Export"
8New-Item -ItemType Directory -Path $OutputPath -Force | Out-Null
9 
10$Domain = (Get-ADDomain).DNSRoot
11$AllGPOs = Get-GPO -All -Domain $Domain
12 
13foreach ($GPO in $AllGPOs) {
14    $SafeName = $GPO.DisplayName -replace '[\\/:*?"<>|]', '_'
15    $ReportPath = Join-Path $OutputPath "$SafeName.html"
16    Get-GPOReport -Guid $GPO.Id -ReportType HTML -Path $ReportPath -Domain $Domain
17    Write-Host "Exported: $($GPO.DisplayName) -> $ReportPath"
18}
19 
20Write-Host "Export complete. $($AllGPOs.Count) GPO(s) exported to $OutputPath"

To identify GPOs that don't apply to any object (failing WMI filter, overly restrictive security, empty OU):

1# Output: list of GPOs with no active links or targeting 0 objects
2$Domain = (Get-ADDomain).DNSRoot
3$AllGPOs = Get-GPO -All -Domain $Domain
4 
5foreach ($GPO in $AllGPOs) {
6    $Links = (Get-GPOReport -Guid $GPO.Id -ReportType Xml -Domain $Domain) -as [xml]
7    $LinkCount = ($Links.GPO.LinksTo | Measure-Object).Count
8    if ($LinkCount -eq 0) {
9        Write-Output "[NO LINKS] $($GPO.DisplayName) | Created: $($GPO.CreationTime) | Modified: $($GPO.ModificationTime)"
10    }
11}

Group Policy Analytics: a decision-support tool, not a magic wand

Group Policy Analytics is natively integrated into Microsoft Intune (accessible from Devices > Configuration > Group Policy Analytics). It imports your GPOs exported in XML format and generates a matching report with Intune's Settings Catalog (MDM).

What the tool concretely produces

• List of GPO settings with a documented MDM equivalent.
• Highlighting of obsolete or cloud-native context-inappropriate settings.
• Identification of GPOs better retired than migrated.
• Working basis for discussion with security and business teams.

Use this report as one input source among others, complementing your manual audit and validation on pilot devices.

Rebuild, don't copy: the cloud-first logic

A successful GPO → Intune migration is not a line-by-line transposition. For each setting or group of settings identified in the audit, apply the following decision grid:

Start with security baselines as foundation

Security baselines in Intune are collections of settings recommended by Microsoft for Windows, Microsoft Edge, and Microsoft Defender for Endpoint. They provide the most consistent starting point for replacing security GPOs.

Recommended deployment sequence:

1. Identify overlaps with existing GPOs before any deployment.
2. Pilot on a representative group (IT + volunteer business users).
3. Monitor conflict reports in Intune (Devices > Monitor > Policy Conflicts).
4. Complete with configuration profiles only for documented requirements not covered by the baseline.

Implementation

Prerequisites

• Module: Microsoft.Graph.DeviceManagement (Microsoft Graph PowerShell SDK)
• Installation: Install-Module Microsoft.Graph -Scope CurrentUser
• Minimum Permission: DeviceManagementConfiguration.ReadWrite.All
• Minimum Intune Role: Intune Policy and Profile Manager

The script below imports a GPO XML file exported from GPMC to Group Policy Analytics in Intune, then retrieves the compatibility report:

1# Connect to Microsoft Graph with required scope
2Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All" -NoWelcome
3 
4# Path to XML file exported from GPMC
5$GPOXmlPath = "C:\GPO_Export\MyGPO.xml"
6 
7if (-not (Test-Path $GPOXmlPath)) {
8    Write-Error "XML file not found: $GPOXmlPath"
9    exit 1
10}
11 
12# Read and encode XML file in Base64 (format expected by API)
13$GPOContent = Get-Content -Path $GPOXmlPath -Raw -Encoding UTF8
14$GPOBase64  = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($GPOContent))
15 
16# Build request body
17$Body = @{
18    displayName = [System.IO.Path]::GetFileNameWithoutExtension($GPOXmlPath)
19    groupPolicyObjectFile = @{
20        ouDistinguishedName = ""
21        content             = $GPOBase64
22    }
23} | ConvertTo-Json -Depth 5
24 
25# Upload to Group Policy Analytics
26$UploadUri = "https://graph.microsoft.com/beta/deviceManagement/groupPolicyMigrationReports/createMigrationReport"
27$Response  = Invoke-MgGraphRequest -Method POST -Uri $UploadUri -Body $Body -ContentType "application/json"
28 
29Write-Host "Import launched. Report ID: $($Response.id)"
30 
31# Wait for report generation (typical delay: 30 to 90 seconds)
32Start-Sleep -Seconds 60
33 
34# Retrieve migration report
35$ReportUri    = "https://graph.microsoft.com/beta/deviceManagement/groupPolicyMigrationReports"
36$MigReports   = Invoke-MgGraphRequest -Method GET -Uri $ReportUri
37$LatestReport = $MigReports.value | Sort-Object createdDateTime -Descending | Select-Object -First 1
38 
39Write-Host "Report: $($LatestReport.displayName)"
40Write-Host "Migratable settings: $($LatestReport.migrationReadiness)"

To list existing configuration profiles in Intune and check for conflicts:

1# Retrieves all configuration profiles and their deployment status
2$ProfilesUri = "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations"
3$Profiles    = Invoke-MgGraphRequest -Method GET -Uri $ProfilesUri
4 
5$Profiles.value | ForEach-Object {
6    $Profile = $_
7    $AssignUri   = "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/$($Profile.id)/deviceStatuses"
8    $Statuses    = Invoke-MgGraphRequest -Method GET -Uri $AssignUri
9    $ConflictCount = ($Statuses.value | Where-Object { $_.status -eq 'conflict' }).Count
10 
11    [PSCustomObject]@{
12        Name          = $Profile.displayName
13        Type         = $Profile.'@odata.type'
14        Conflicts     = $ConflictCount
15        LastModified = $Profile.lastModifiedDateTime
16    }
17} | Format-Table -AutoSize

Coordinate GPO and Intune during the hybrid period

A frequently misunderstood point: GPOWinsOverMDM is not a universal priority switch. This setting (defined via the MDMWinsOverGP CSP or its inverse) applies only to settings exposed by the Windows Policy CSP with a corresponding Group Policy mapping. It doesn't govern settings delivered via other CSPs like Defender or Windows Update — which have their own precedence or merge behaviors.

Targeting strategy to avoid conflicts

On Group Policy side:

• Use security group filtering to exclude Intune pilot devices from relevant GPOs.
• Validate with WMI filters if necessary (with caution — they impact GPO processing performance).
• Document each GPO with its owner, target population, and planned review date.

On Intune side:

• Target via dynamic Microsoft Entra groups (e.g., device.managementType -eq "MDM").
• Use assignment filters for granular targeting without multiplying groups.
• Document the authoritative management plan for each policy area (security, updates, restrictions).

Concrete example: keep Windows Update GPOs in place for most hybrid devices, exclude a pilot group from this GPO, and assign them the equivalent Intune profile. After validation, gradually expand the scope.

Decommission GPOs progressively: the retirement checklist

For each GPO to be retired:

• Exclude the pilot population from the GPO and assign them the equivalent Intune configuration.
• Verify effective configuration with Gpresult /H report.html /F and Intune deployment reports.
• Extend targeting in controlled stages (10% → 30% → 100%).
• Disable the GPO (don't delete) after full validation.
• Archive the exported XML file before final deletion.
• Keep GPOs still needed for hybrid devices with an identified owner and planned review date.

1# Disabling a GPO (reversible operation, recommended before deletion)
2# Minimum role: Group Policy Creator Owner or Domain Admin
3# Module: GroupPolicy (RSAT)
4 
5$GPOName = "Your-GPO-Name"
6 
7# Preliminary verification
8$GPO = Get-GPO -Name $GPOName -ErrorAction Stop
9Write-Host "GPO found: $($GPO.DisplayName) | Current status: $($GPO.GpoStatus)"
10 
11# Disable both user and computer settings
12$GPO | Set-GPO -Status AllSettingsDisabled
13Write-Host "GPO '$GPOName' disabled. Verify impact before deletion."
14 
15# Archive export
16$ArchivePath = "C:\GPO_Archive\$($GPOName -replace '[\\/:*?"<>|]', '_')_$(Get-Date -Format 'yyyyMMdd').xml"
17Get-GPOReport -Name $GPOName -ReportType Xml -Path $ArchivePath
18Write-Host "XML archive: $ArchivePath"

Troubleshooting common errors

What you do Monday morning

GPO → Intune migration is not a switchover project but a process of progressive rationalization. Here are the first concrete actions:

1. Launch GPO audit: export all your GPOs via GPMC and run the script identifying GPOs with no active links.
2. Import into Group Policy Analytics the GPOs from the most active areas (security, updates) to get an initial MDM compatibility snapshot.
3. Identify your first cloud-native population (new devices, replacement devices) and build their Intune configuration based on security baselines.
4. Define an owner and authoritative policy zone for each major category (security, updates, restrictions) before touching targeting.
5. Assemble a pilot group of about ten representative devices and validate each profile before any broad deployment.

If your organization maintains hybrid devices for several more years, GPO + Intune coexistence is an operational reality — the issue isn't getting out fast, but getting out cleanly, zone by zone, with clear documentation of responsibilities.