Blog
Intune vs Group Policy in 2026: migrate the intent, not the sprawl
Years after Microsoft shipped tooling for the journey, most enterprise Windows estates still run Group Policy and Intune side by side. The tooling is better than ever; it is still not a migration button. Here is what actually gets estates across.
Where estates actually stand
The picture in most large organisations is neither Group Policy nor Intune; it is both. Devices are co-managed or hybrid-joined, Intune owns compliance, updates and some configuration, and hundreds of GPOs remain authoritative for the rest. That is not laziness. It reflects a real gap: a wholesale move is risky, the mapping between the two worlds is imperfect, and nobody can say with confidence what a decade of accumulated policy is actually doing. So the hybrid state persists, and every year it persists it gets harder to unwind.
What Group Policy Analytics will and won't do
Microsoft's Group Policy Analytics is genuinely useful, and it is honest about its limits if you read the report properly. You export your GPOs, import them into Intune, and get a per-setting verdict: supported with an MDM equivalent, deprecated, or not supported at all. Supported settings can be migrated into a Settings Catalog profile in a few clicks.
Then the caveats start. The translation is best effort: some settings land on an alternate setting with a similar but not identical effect. Group Policy Preferences, which is where estates keep their drive mappings, printers, shortcuts and scheduled tasks, are not analysed at all. Settings marked not supported need rebuilding by hand, typically as PowerShell scripts, remediation packs or custom policy. And the tool only reports on what you feed it: miss a domain, a sub-OU or a forgotten GPO in the export and the omission looks exactly like success. A green percentage on a partial capture is the most dangerous number in the programme.
A migration button would only be worth pressing if you wanted the last decade shipped to the cloud intact.
Every setting was for something
The deeper problem is not tooling; it is intent. A GPO estate is an archaeological record: settings for applications retired years ago, workarounds for Windows 7 bugs, duplicated controls layered by different teams, and a hard core of configuration that genuinely keeps the business secure and working. Analytics can tell you whether a setting has an Intune equivalent. It cannot tell you whether the setting deserves one.
So before asking “does this map?”, ask “what was this for?”. Every setting then lands in one of four places. It is still needed and maps natively: migrate it through the Settings Catalog. It is still needed but has no native path: engineer the alternative deliberately, as scripted configuration or a detect-and-remediate pack, piloted before production. It has been superseded by modern defaults or a security baseline: retire it and record why. Or nobody can say what it is for: gather the evidence, retire it deliberately with rollback available, and watch. What you should never do is port it wholesale and hope, because sprawl migrated is still sprawl, only now it is sprawl nobody remembers moving.
The sequence that works
The estates that get across cleanly follow the same order. Capture everything first, as evidence rather than recollection: every GPO, its scope, its links and its filtering, with anything skipped recorded rather than silently absent. This is exactly what Scout, Meridian's capture tool, does: a read-only walk of the estate with zero network egress, producing discovery you can hand to an auditor. Then decide, setting by setting. Meridian maps thousands of captured settings against Microsoft's own Settings Catalog, flags conflicts and duplicates, and records an engineering decision for each one: keep, migrate, re-engineer or retire, approved by your team in the platform rather than in a spreadsheet. Then deploy the rationalised result in staged, approval-gated releases with rollback, and keep drift detection watching afterwards so the clean estate stays clean.
Done this way, the question stops being Intune versus Group Policy. Group Policy was how your organisation expressed its intent for twenty years; Intune is how it will express that intent next. The migration is simply the moment you find out what that intent really was, and choose it again on purpose. For more on how estates end up needing this in the first place, read our earlier piece, Group Policy: the good, the bad and the modern.
Planning the move from Group Policy to Intune?
Our Group Policy analysis captures your estate as evidence and puts a defensible decision behind every setting, per domain, at any scale.