After a few weeks off blogging, and work, and life… I figured it’s time to get back to it. Whilst sunning myself alongside the family, Microsoft published new Intune Customer Success guidance addressing the transition from Group Policy to Microsoft Intune (“From GPO to Microsoft Intune: a practical guide to cloud-first policy management,” by Per Larsen, Senior Product Manager on the Intune team and well renowned within the community). It’s a short read, but it’s making a point I don’t think gets said often enough, and it’s one worth unpacking, more so because it shows Microsoft’s take on this – which carries weight!

Again, like with most of my recent articles, the timing is fitting. I’ve had a few conversations recently about modernisation and transformation. During these conversations one question gets asked or discussed repeatedly: How do we migrate our Group Policies into Intune?

It’s an understandable question, but increasingly I think it’s the wrong one. A better question is: Which of our existing Group Policies do we actually still need, and what is the correct modern management approach for those requirements?

Microsoft’s position is this: organisations should not simply reproduce their existing GPO estate inside Intune. Rather than one migration path, they describe three, and it’s the three I’d recommend, and in this exact order also:

• Start clean for genuinely cloud-native devices – build the policy set you need today, rather than importing what you needed a decade ago.
• Selectively migrate the settings that remain necessary – assess first, migrate second. Bring in only the necessary.
• Coordinate GPO and Intune during a hybrid transition – for the (very common) period where both are managing the same estate.

When starting clean, the included baselines within Intune (and those such as CIS, NCSC etc) offer a landing zone that’s almost certainly leaner, cleaner and more modern than where you’re at today, or where you’d get to if bringing in GPO. That said, most environments will likely need some additional policies bringing across, but this should be minimal. One or two (give or take). Not “all of them” – examples would be business specific requirements, I guess Print Queues and Drive Mappings, although there are better|different|modern ways of achieving this kind of configuration also…

Why the “lift and shift” instinct is so strong

Damn Intune and it’s pesky “Group Policy Analytics” functionality. To lift and shift is an understandable instinct. So many environments have Group Policy Objects spanning back to prehistoric ages, staff turnover has occurred, and those prehistoric objects exist for a business decision or reason, and likely remain purely because no one knows what they do, or are too afraid to touch them. Step forward Group Policy Analytics, Intune’s tool for importing and assessing GPO backups against the Settings Catalog. Great, a tool which will automatically assess our posture and instantly modernise us – well, not quite, the use of Group Policy Analytics only reinforces this framing if you let it: it produces a tidy MDM support percentage, and a high number feels like permission to just crack on and migrate everything it says is compatible.

However I’d treat that number with a healthy dose of scepticism. A GPO that drops a registry value directly, or fires a logon script, can show as “supported” without there being any clean, native Intune equivalent behind it – the analyser isn’t judging fitness for purpose, it’s judging whether the setting exists somewhere in the CSP space. Compatible doesn’t mean necessary, and it definitely doesn’t mean well-designed for a cloud-first world.

Ultimately, lift and shift is never the answer, and everyone knows this and agrees – but knowing it, agreeing to it and sticking to it isn’t always the case. There’s always the “but we really really really need it” and the “can we just” and before you know it, we’ve got legacy inside Modern – yay! (boo!). Moving (any of) this directly into Intune risks carrying years of technical debt into a brand-new management platform and then you haven’t modernised endpoint management. You’ve simply changed where the technical debt lives.

Assess and rationalise before you touch a single policy

Microsoft’s recommendation to assess and rationalise existing policies, lean on modern security baselines where appropriate, pilot changes, and carefully coordinate targeting to avoid GPO/MDM conflicts is really just good architecture discipline, applied to a job that too often gets treated as a mechanical export/import exercise. In practice, that means:

Inventory first, with intent. Pull every actively assigned GPO, but go in expecting to leave things behind. Anything scoped to an OS version you no longer run, a line-of-business app you’ve retired, or a security posture that predates Conditional Access, is a candidate for the bin not Settings Catalog.

Ask “why” before you ask “how.” For each setting that survives the cull, the question isn’t “what’s the Intune equivalent?” It’s “what outcome is this actually trying to achieve, and is there a better way to achieve it today?” A password complexity GPO from 2014 and a modern Windows security baseline are often solving the same problem with very different assumptions about the threat model.

Use the baselines as a starting point. Microsoft’s Windows security baselines give you a curated, Microsoft-maintained set of recommended configuration a sensible floor to build from rather than a policy-by-policy negotiation with fifteen years of institutional memory. These are a great starting point, but cannot really be used 1:1 in real world. My experience across MSPs and with clients is that nine out of ten times, the odd setting needs tweaking here or there to accommodate the client environment – and that’s ok. Deviation is allowed, and expected. The good news is 95% of the baseline fits just fine, so not only is it time and effort saved, it’s standardisation using native modern approaches.

Pilot, and phase deployments – don’t just cut over. This one shouldn’t need saying, but it does. Ring-based deployment, starting small, watching compliance and helpdesk load before expanding exactly the same discipline you’d apply to any other kind of rollout.

Design for coexistence, deliberately. For the hybrid period, where GPO and Intune are both live against the same devices, targeting has to be intentional. Overlapping settings from both channels are a well-known source of unpredictable device state, and MDMWinsOverGP is not a substitute for good scoping. It has enough caveats and edge cases that Microsoft itself recommends avoiding it where you can. The safer route is to make sure GPO and Intune are never fighting over the same setting in the first place, and to have a clear, documented cutover point for each policy area rather than an indefinite “both are running” state.

Naming conventions… don’t leave it too late

One thing I’d add, which doesn’t get enough airtime in migration guidance generally: decide your Intune profile naming convention before you build the first pilot policy, not after you’ve got forty of them live. I’ve inherited more than one tenant where every profile is called “New Policy” or “Test – delete later” (it was not, in fact, deleted later). A pattern that encodes platform, purpose, and scope – something like WIN-Sec-BitLocker-PilotRing – means an admin two years from now can understand a profile’s intent without having to open it first. It’s a small thing, but on a rationalisation project it’s exactly the kind of discipline that stops today’s clean estate becoming tomorrow’s attic full of unlabelled boxes.

and one more thing… whilst it can be tempting to add lots of short abbreviations to the naming convention, keep it short. Resizing and adjusting the columns within the Intune UI isn’t great, and you can quickly end up with a bunch of policies that get truncated at the good stuff! Just an abundance of policies displayed only as GLB-WIN-SEC-EPM-V1-RING1-Truncated Useful Descriptive Wording. As Intune has matured, there’s more and more arguments to forgo the needs of the targeted OS (WIN) and the Policy Type (SEC/EPM) in this example, because Windows Policies are only visible within the Windows section, and likewise, the Policy Type is often shown in a separate column.

That said, the counter argument to that, depends entirely on whether or not you’re working inside, or outside of the Intune console. If you’re automating bits and bobs via Graph, then the argument could be nulled.

Ultimately, spend some time on your naming convention, and define it, before going gung ho!

So which of the approaches is right for you?

Choose start clean when the devices in question are genuinely cloud-native, so that’s Autopilot-provisioned, Entra-joined, no dependency on the on-premises estate. In an ideal world, this is what most people want – and for what its worth, this can be achieved alongside todays production environment. It just requires a little more testing and evaluation, from your users more than anything!

Choose selectively migrate when there’s real, specific value locked up in your GPO estate. Examples could be regulatory requirements, hardened configuration you’ve validated over years – configuration that you want to rebuild in Settings Catalog, but on your terms and not wholesale.

Choose to coordinate GPO and Intune when you’re mid-transition and domain-joined devices still need Group Policy for now, accepting that this is a temporary, carefully scoped state, not a permanent architecture – a valid approach, but a stepping stone. Not the final destination!

How might you proceed?

Discover > Analyse > Rationalise > Redesign > Test > Deploy > Retire, not simply Import > Select all > Migrate > Deploy.

Discover: Export the existing GPO estate and build an inventory before changing anything: policy name, owner, purpose, scope, settings, security/WMI filtering, dependencies, affected devices or users, last modification date, and business justification.

Analyse: Import the GPOs into Group Policy Analytics (Intune admin center > Devices > Manage devices > Group Policy Analytics) to get a technical read on which settings have modern equivalents. Treat this as an initial signal, not a verdict. Just because it has compatibility doesn’t mean a setting should be migrated.

Rationalise: For every setting, classify it as Required, Redundant (another config already covers it), Obsolete (no longer relevant), Replaced (a modern capability does it better), or Unknown. Anything nobody can explain shouldn’t be carried forward until investigated first.

Decide where it belongs: Don’t treat Settings Catalog as the destination for everything. Match the requirement to the right modern surface: Windows config > Settings Catalog; Defender, BitLocker, Firewall > Endpoint Security; AppLocker/app control > App Control for Business; security hardening > Security Baselines/Settings Catalog; scripted config > Remediations. Ask how the requirement should be implemented in a modern architecture, not where the old GPO setting maps to.

Redesign: Rebuild the surviving requirements as properly structured modern policy. Sensibly named, scoped, and documented – rather than a like-for-like recreation of the old GPO.

Test: Pilot on a small ring before wider rollout. Validate against real devices, with real users, your friendly users and watch for GPO/MDM targeting conflicts if both are still live during a hybrid period.

Deploy and retire: Roll out in phases, monitor compliance and helpdesk load, then formally decommission the GPO once its replacement is confirmed working. This ensures you close the loop rather than leaving both running indefinitely.

Final thoughts

None of this is a new idea. “Assess, don’t lift-and-shift” is advice that’s been floating around the Intune community for a while now. What’s notable is that it’s now coming directly from Microsoft, in a Customer Success guidance article, rather than being something us consultants have had to argue amongst ourselves. As a consultant, we strive to deliver “Best Practice”. That often means Microsoft’s recommended way, tweaked with real world experience. Quite often, there’s little to back us up, so this is why Microsoft’s publication matters, because it gives you/me/us something concrete to point at the next time someone on a migration project asks for a GPO-to-Intune mapping spreadsheet before anyone’s asked whether half of those GPOs should exist at all.

The tooling, Group Policy Analytics, Settings Catalog and security baselines have matured to the point where the “how” of GPO to Intune is largely solved. The harder, more valuable work was always the “which,” and it’s good to see Microsoft say this so plainly!