From Group Policy to Intune — A Device-Management Migration Guide for Small and Medium Businesses

“The server’s support window is up, so we are planning a replacement. But we have lost confidence that we should buy another AD server and run the domain and Group Policy for another cycle (five years).” “The Group Policy we decided on in the office never applies to the laptops used for remote work. If it only applies when they connect to the VPN, can we really say we are managing them?” — Over the last few years, this kind of consultation from small and medium business customers has steadily increased.

The background is a change in how people work. On-premises Active Directory (AD) and Group Policy (GPO) are a mechanism that assumes “the PC is on the corporate LAN and can always reach a domain controller”. Now that take-home PCs and remote work are the norm, it is that assumption that has broken. On top of that, WSUS — long the default for update management — was deprecated in September 2024,¹ and the centre of gravity of Microsoft’s device management has moved to Entra ID plus Intune (MDM).

flowchart TB
    accTitle: The broken assumption and the shift in the centre of gravity
    accDescr: AD and GPO assume the PC is on the corporate LAN and can always reach a domain controller, but take-home PCs and remote work as the norm have broken that assumption, and with WSUS deprecated the centre of gravity of management has moved to Entra ID and Intune
    adgpo["On-prem AD and GPO"] -.-> premise["Assumption: the DC is always reachable"]
    work["Take-home PCs and remote work as the norm"] --> broken["It is the assumption that broke"]
    premise --> broken
    wsus["WSUS is deprecated"] --> shift["Centre of gravity moves to Entra ID+Intune"]
    broken --> shift

Figure 1: The AD+GPO assumption that “the PC is on the corporate LAN” broke as ways of working changed, and the centre of gravity of management moved to Entra ID+Intune.

That said, migration is not all-or-nothing. PCs managed with Entra join plus Intune and PCs that are AD domain-joined plus GPO can coexist in the same company,² and a staged migration is possible: leave AD in place for the file server, and switch new PCs over to Intune management. Aimed at IT staff and business owners in small and medium businesses, this article organises — grounded in primary sources such as Microsoft Learn as of August 2026 — the differences in how GPO and MDM work, the prerequisite configurations, licensing, how to inventory current GPOs, a staged-migration scenario, and the pitfalls.

1. The Bottom Line First

• GPO is applied when the PC is connected to the domain network; Intune (MDM) syncs over the internet. The problem of “settings never reach a home PC” does not arise structurally with MDM. Steady-state sync is roughly every 8 hours, and a notification-driven sync also runs when policy changes.³
• Migration is not all-or-nothing; a staged migration that assumes coexistence is the realistic answer. Microsoft itself recommends Entra-joining new PCs, and leaving existing domain-joined PCs as hybrid join and replacing them on the hardware-refresh cycle.²
• You can subscribe to Intune on its own, but for small and medium businesses the realistic path is to use the Intune Plan 1 included in Microsoft 365 Business Premium (as of August 2026). Plan composition keeps changing, so always confirm primary sources before you sign.⁴⁵
• To inventory current GPOs, use Intune’s built-in Group Policy analytics. Import a GPO XML export and each setting is classified by whether it can migrate; settings that have a counterpart can be converted into a Settings catalog policy.⁶
• The main jobs of the GPO era almost all have an Intune counterpart. Administrative Templates map to the Settings catalog,⁷ WSUS to Windows Update for Business, BitLocker recovery keys to storage in Entra ID,⁸ local administrator passwords to Windows LAPS,⁹ and app deployment to Win32 apps (.intunewin)¹⁰ and Microsoft Store apps (winget-based).¹¹
• The classic things that do not move as-is are logon scripts, drive maps, and printer deployment. You replace them with PowerShell script deployment,¹² Remediations (formerly Proactive remediations),¹³ turning the work into an app, or “stopping that practice”.
• Do not deploy the same setting from both GPO and MDM. By default GPO wins a conflict. Setting MDMWinsOverGP to 1 makes MDM win, but it only applies to Policy CSP settings.¹⁴
• Domain-joined machines and Entra-joined machines can coexist, and an Entra-joined machine can access an on-premises file server. Immediate retirement of AD is not a condition of migration.²

In one sentence: the question “should we replace the AD server for another cycle” should be recast as “for the next five years, what will we use to manage PCs that sit outside the office” and decided on that basis.

flowchart LR
    accTitle: Recasting the question you should be deciding
    accDescr: The question of whether to replace the AD server for another cycle should be recast as the question of what you will use to manage off-site PCs for the next five years
    q1["Replace the AD server for another cycle?"] -->|Recast| q2["For the next 5 years, what manages off-site PCs?"]

Figure 2: Recast the server-replacement question as “for the next five years, what will we use to manage PCs that sit outside the office” and decide on that basis.

2. How GPO and MDM Differ — Comparing the Application Mechanisms

First, compare the two on the same field. The GPO mechanism itself (the LSDOU order of application, how to confirm with gpupdate/gpresult) is covered in depth in “A Practical Guide to Group Policy (GPO)”, so here we narrow to the differences that matter for the migration decision.

The most important rows for the migration decision are the first and the third. GPO not reaching a home PC is not a bug — it is that the design assumption “the PC sits where it can reach a domain controller” no longer matches how people work today. You can keep GPO alive by forcing always-on VPN on every employee, but that is also a choice to take on maintaining a separate piece of infrastructure: the VPN platform.

flowchart TB
    accTitle: The choice between keeping GPO alive and migrating to MDM
    accDescr: GPO not reaching a home PC is because the design assumption no longer matches how people work today, and the path of forcing always-on VPN to keep GPO alive is a choice to take on maintaining a separate piece of infrastructure, the VPN platform
    gap["The design assumption no longer matches how people work"] --> sel{"How do you respond?"}
    sel -->|Keep it alive with always-on VPN| vpn["Continue GPO"]
    sel -->|Migrate to MDM| mdm["Manage over the internet"]
    vpn --> cost["You take on maintaining other infrastructure"]

Figure 3: The path of keeping GPO alive with always-on VPN is also a choice to take on maintaining a separate piece of infrastructure: the VPN platform.

On the other hand, the MDM sync interval (about 8 hours) is coarser than GPO’s periodic refresh (about 90 minutes), and the feeling of “deploy it and it applies immediately” does not carry over. When you assign or change a policy a notification is sent to the device and it syncs relatively promptly,³ but controls that require immediacy (an emergency block, and the like) need to be designed around the sync interval.

flowchart TB
    accTitle: How GPO and MDM apply policy
    accDescr: GPO applies only when the PC can connect to an in-house domain controller, so a home PC depends on VPN; Intune syncs over the internet roughly every 8 hours and also syncs on a notification when policy changes, so it reaches a PC wherever it is
    officepc["An in-house PC"] --> dc["Domain controller"]
    officepc -.-> when["Startup and sign-in"]
    when -.-> when2["plus periodic refresh"]
    homepc["A home PC"] --> vpn{"Reach DC over VPN?"}
    vpn -->|Yes| dc
    vpn -->|No| miss["Policy never arrives"]
    anypc["A PC wherever it is"] --> intune["Intune service"]
    anypc -.-> every["Sync about every 8h"]
    intune -.-> notify["Notify-driven change"]
    dc ~~~ homepc
    miss ~~~ anypc

Figure 4: GPO applies only when the PC can reach a domain controller; Intune syncs over the internet regardless of location.

3. Sorting Out the Prerequisites — The Three Forms: Domain Join, Hybrid Join, and Entra Join

There are three forms of “how a Windows PC joins the company”, and which you choose determines which management tools you can use.²

Hybrid join is a form for “giving an existing domain-joined PC a cloud identity”, and it lets you start using Intune and Conditional Access while keeping existing assets. Microsoft, however, recommends not making hybrid join the final goal, and Entra-joining new and replacement PCs.²

There is one constraint to take on board here. There is no Microsoft-supported way to convert an existing domain-joined PC (including hybrid join) to Entra join; a Windows reset (wipe) is required. That is why Microsoft also recommends moving to Entra join at hardware-refresh or OS-reinstall time.²

flowchart TB
    accTitle: The three join forms and the migration paths
    accDescr: An AD-domain-join-only PC can be registered in Entra ID as well and become hybrid join, but there is no way to convert it directly to Entra join and a wipe is required, so Entra-joining new and replacement PCs is recommended
    adonly["AD domain join only (GPO)"] -->|Also register in Entra ID| hybrid["hybrid join (GPO and Intune)"]
    hybrid -.->|No direct conversion path| wipe["A wipe (reset) is required"]
    wipe --> entra["Entra join (Intune)"]
    newpc["New and replacement PCs"] -->|Recommended| entra

Figure 5: There is no supported way to convert an existing domain-joined machine to Entra join; the established pattern is to switch from new and replacement PCs.

From the above, a realistic goal for a small or medium business can be put this way.

1. Manage new and replacement PCs with Entra join plus Intune
2. Leave existing domain-joined PCs alone and let them be replaced naturally on the hardware-refresh cycle
3. Leave AD in place for the time being for remaining roles such as file-server authentication, and empty the contents of GPO in stages

flowchart TB
    accTitle: A coexistence configuration during staged migration
    accDescr: Entra-joined machines and domain-joined machines can coexist in the same corporate environment; the former are managed with Intune and the latter with GPO, while AD is left in place for remaining roles and only the contents of GPO are emptied in stages
    env["The same corporate environment"] --> ejoin["Entra-joined machines"]
    env --> djoin["Domain-joined machines"]
    ejoin --> intune["Managed with Intune"]
    djoin --> gpo["Managed with GPO"]
    gpo -.-> shrink["Empty the contents in stages"]
    env -.-> ad["Leave AD for remaining roles"]

Figure 6: Entra-joined machines and domain-joined machines can coexist in the same corporate environment, and AD is left in place for the time being for remaining roles.

Entra-joined machines and domain-joined machines can coexist in the same environment, and an Entra-joined machine can access in-house assets such as an on-premises file server.² That single sign-on, however, has two prerequisites. (1) The user is a hybrid identity synchronised from on-prem AD with Entra Connect (or Cloud Sync) (a user that exists only in the cloud cannot obtain AD Kerberos/NTLM credentials), and (2) the PC has network reachability to a domain controller (from off-site, a VPN or similar is required).¹⁵ In the migration plan, confirm first that there are no users or usage scenarios that fail these two points.

flowchart TB
    accTitle: Prerequisites for SSO from an Entra-joined machine to on-premises assets
    accDescr: To access an on-premises file server from an Entra-joined machine, two prerequisites must be met: a hybrid identity synchronised with Entra Connect or similar, and reachability to a domain controller
    pc["Entra-joined machine"] --> cond1{"Hybrid identity?"}
    cond1 -->|Yes| cond2{"Can it reach a DC?"}
    cond1 -->|No| ng1["Cannot obtain AD credentials"]
    cond2 -->|Yes| ok["SSO to the file server"]
    cond2 -->|No| ng2["From off-site, a VPN or similar is required"]

Figure 7: SSO from an Entra-joined machine to on-premises assets has two prerequisites: a hybrid identity and reachability to a domain controller.

4. Licensing and Cost — Which Plans Include Intune (as of August 2026)

The base Intune licence is Microsoft Intune Plan 1, offered both as a standalone subscription and bundled into various Microsoft 365 plans.⁴

What matters for small and medium businesses is that Microsoft 365 Business Premium, for up to 300 users, includes Intune Plan 1.⁵ Business Premium also includes Microsoft Entra ID P1 and Microsoft Defender for Business, so the compliance-policy plus Conditional Access configuration described later can be completed inside this plan. Business Standard/Basic, on the other hand, do not include Intune. When you step from a mail-and-Office-only contract into device management, the upgrade cost to Business Premium is the effective cost of introducing Intune.

flowchart TB
    accTitle: How SME plans relate to Intune
    accDescr: Business Premium for up to 300 users includes Intune Plan 1, Entra ID P1, and Defender for Business and completes through Conditional Access, but Business Standard/Basic do not include Intune
    bp["Business Premium"] -.-> cap["Up to 300 users"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["Completes through Conditional Access"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["Does not include Intune"]

Figure 8: Business Premium includes Intune Plan 1 and Entra ID P1; Business Standard/Basic do not include Intune.

There are two caveats.

• Plan composition changes frequently. Even into 2026, changes that redistribute Intune Suite features into higher Microsoft 365 plans (E3/E5 and the like) have been in progress, and reviews of what is bundled continue.⁴ Treat this section as of August 2026, and before you sign always confirm the latest information on Microsoft’s licensing and pricing pages.
• Some features that you can open from the Intune UI require a separate licence. The representative example is Remediations, described later: it requires a Windows Enterprise E3/E5-class licence (bundled in Microsoft 365 E3/E5 and the like) and is not available within the scope of Business Premium.¹³

The cost comparison is not “Intune subscription cost” versus “zero”. On the GPO side you are already paying for AD-server hardware replacement, Windows Server licences and CALs, build cost, five years of maintenance, backup, and incident response. The correct comparison is to put the server-replacement quote next to five years of Business Premium, and then factor in the capability difference of “does management reach off-site PCs”.

flowchart TB
    accTitle: The right way to think about the cost comparison
    accDescr: The GPO side also incurs costs such as AD-server replacement, licences, and five years of maintenance, so put the server-replacement quote next to five years of Business Premium and then decide with the capability difference of whether management reaches off-site PCs factored in
    gpocost["Cost of continuing GPO"] --> hw["Server replacement, licences, CALs"]
    gpocost --> ops["Build, maintenance, backup"]
    bpcost["Cost of migrating to Intune"] --> sub["Five years of Business Premium"]
    hw --> diff["Put the five-year difference side by side"]
    ops --> diff
    sub --> diff
    diff --> ability["Factor in whether management reaches off-site PCs"]

Figure 9: Put the server-replacement quote next to five years of Business Premium, and decide with the capability difference of managing off-site PCs factored in.

5. How to Do in Intune What You Used to Do with GPO

For each of the main jobs of GPO operations, the Intune counterpart is shown in a mapping table.

A few notes.

• The Settings catalog is a screen that corresponds to “the cloud edition of the GPO editor”, and Microsoft itself positions it as “the natural migration destination when you want to configure in the same fine-grained way as an on-premises GPO”. It includes ADMX-backed policies (the MDM edition of settings defined in ADMX), and there is also a (preview) feature for importing third-party ADMX.⁷
• Compliance policy plus Conditional Access is an idea GPO did not have. You define compliance conditions such as “BitLocker on, OS current, Defender running” and can block Microsoft 365 access from devices that do not meet them. Conditional Access is an Entra ID P1 feature and is included in Business Premium.¹⁶
• Remediations has been renamed from Proactive remediations. It is a mechanism that periodically runs a detect-script plus remediate-script pair, and it can replace the kind of GPO operations that “fix something at every logon”, but as noted it requires a Windows Enterprise E3/E5-class licence.¹³ Within the scope of Business Premium, the realistic substitute is to combine platform scripts (run when the script or assignment changes, and retried on failure)¹² with Win32-app detection rules.
• The detailed choices for update management (deciding among WUfB, Autopatch, and continuing WSUS) are covered in “Windows Update Management After WSUS Deprecation”, and the design of BitLocker and LAPS in “BitLocker Practical Guide” and “A Practical Guide to Windows LAPS” respectively.

flowchart TB
    accTitle: The flow of a compliance policy and Conditional Access
    accDescr: A compliance policy only judges a device's compliance state against the compliance conditions; only when a Conditional Access policy requires a compliant device are compliant devices allowed and non-compliant devices blocked
    policy["Define compliance conditions"] -.-> cond["BitLocker on, OS current, and the like"]
    policy --> state["Judge the device's compliance state"]
    state --> ca["Conditional Access requires compliance"]
    ca -->|Compliant| allow["Microsoft 365 access allowed"]
    ca -->|Non-compliant| block["Access blocked"]

Figure 10: Judging compliance state is the job of a compliance policy; blocking is the job of Conditional Access. Only in combination does the block take effect.

6. Inventorying Current GPOs — Sorting with Group Policy Analytics

The first real work of a migration plan is inventorying current GPOs. Intune has a dedicated feature, Group Policy analytics, that can classify, per setting, “can MDM replace this” without you having to read GPOs by hand.⁶

The steps are as follows.⁶

1. Open the Group Policy Management Console (GPMC.msc) on a domain controller or similar, right-click the target GPO → Save Report and export it as an XML file (4 MB or less per file)
2. In the Intune admin centre, go to Devices → Group Policy analytics and import the XML (multiple selection is allowed)
3. After automatic analysis, each GPO shows an MDM support percentage (the share of settings that have an equivalent in Intune)
4. In the Group policy migration readiness report, confirm the per-setting classification: Ready for migration / Not supported / Deprecated
5. Ready for migration settings can be converted as-is into a Settings catalog policy and deployed

flowchart TB
    accTitle: The inventory flow with Group Policy analytics
    accDescr: Export GPOs as XML from GPMC and import them into Intune; the MDM support percentage and per-setting migration readiness are displayed, and Ready for migration settings can be converted into a Settings catalog policy
    export["Export GPOs as XML from GPMC"] --> import["Import into Intune"]
    import --> rate["MDM support percentage is displayed"]
    rate --> report["Migration readiness report"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["Convert into a Settings catalog policy"]

Figure 11: From XML export through import, per-setting classification, and conversion to the Settings catalog — that is the Group Policy analytics flow.

There is an important caveat in Japanese environments. Analysis of non-ADMX settings in Group Policy analytics is English-only; importing a GPO that contains settings in a language other than English can make the MDM support percentage inaccurate.⁶ Treat the support percentage as a rough reference value, and make the final judgment from the per-setting list.

flowchart TB
    accTitle: A caveat when analysing a Japanese GPO
    accDescr: Analysis of non-ADMX settings in Group Policy analytics is English-only, so a GPO that contains Japanese settings can make the MDM support percentage inaccurate; treat the percentage as a rough reference and make the final judgment from the per-setting list
    jgpo["A GPO that contains Japanese settings"] --> limit["Non-ADMX analysis is English-only"]
    limit --> rate["The support percentage can be inaccurate"]
    rate --> use1["Treat the percentage as a rough reference"]
    rate --> use2["Make the final judgment from the per-setting list"]

Figure 12: In a Japanese GPO the MDM support percentage can be inaccurate, so make the final judgment from the per-setting list.

In practice, split the classification results into three piles.

1. Settings to discard — Internet Explorer-era settings, settings for retired systems, settings nobody can explain the reason for. The biggest payoff of the inventory is, in fact, being able to throw this pile away. A GPO that has been run for ten years has a considerable amount of legacy piled up.
2. Settings to move to Intune — those among Ready for migration that you will still need. Convert them to the Settings catalog and validate with a pilot group.
3. Settings for which you design a substitute — those among Not supported that you will still need. Representative examples and directions for substitution are as follows.

flowchart TB
    accTitle: The three piles of inventory results
    accDescr: Inventory results are handled as three piles: settings to discard, settings to move to Intune and validate, and settings that have no counterpart and for which you design a substitute
    result["Classification results"] --> discard["Settings to discard"]
    result --> more{"Move or substitute?"}
    more --> move["Move to Intune"]
    more --> alt["Design a substitute"]
    discard -.-> legacy["Dispose of the legacy"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["then validate"]
    alt --> design["Script or make an app"]

Figure 13: Split inventory results into the three piles “discard”, “move to Intune”, and “design a substitute”.

7. A Staged Migration Scenario — Five Stages and Exit Criteria

Split the whole into five stages and put an exit criterion on each. Deciding in advance “when can we say this is done” is the trick that keeps a one-person IT migration from stalling.

flowchart TB
    accTitle: A five-stage migration scenario
    accDescr: Progress in stages from the pilot through baseline policy, app deployment, replacing existing PCs on the hardware-refresh cycle, and shrinking AD's role, and finally bring settings deployed via GPO to zero
    s1["(1) Pilot"] --> s2["(2) Baseline policy"]
    s2 --> s3["(3) App deployment"]
    s3 --> s4["(4) Natural replacement of existing PCs"]
    s4 --> s5["(5) Shrinking AD's role"]
    s5 -.-> goal["Settings deployed via GPO are zero"]

Figure 14: Advance the migration in five stages from the pilot through shrinking AD’s role, and decide each stage’s exit criterion in advance.

The key points of each stage.

• (1) Pilot starts with a PC you were going to buy anyway — the next new-hire PC, a break/fix replacement, and the like. Starting from a new machine has the advantage that you can begin with zero extra investment, and if it fails you can wipe and start over. Once the count grows, consider using Windows Autopilot to automate from OOBE (initial setup) through Entra join plus Intune enrolment.²
• In (2) Baseline policy, do not aim to reproduce every GPO setting. First narrow to the five of update, encryption, Defender, screen lock, and LAPS, and visualise compliance state with a compliance policy. Enabling “compliant devices only” in Conditional Access comes after you have confirmed there are no false positives in the pilot.¹⁶
• (3) App deployment is continuous with automating provisioning. If you already have a winget-based procedure in place (“Automating PC Provisioning With winget + PowerShell”), that asset can be reused almost as-is as a Store app (new) or a Win32-app wrapper.¹¹
• (4) Existing PCs, as Chapter 3 said, have no conversion path to Entra join, so the principle is natural replacement. Organisations that still have a Windows 10 replacement plan (“Practical Options After Windows 10 End of Support”) can avoid doing the work twice by advancing that replacement at the same time as (4).
• In (5) Shrinking AD’s role, emptying GPO does not necessarily mean AD is immediately unnecessary. If file-server authentication, LDAP lookups from legacy apps, and the like remain, AD continues in a shrunk form as an “authentication server”. Inventorying those and setting deadlines is this stage’s job.

flowchart TB
    accTitle: What to do with AD after GPO is empty
    accDescr: Even after GPO is empty, if file-server authentication or LDAP lookups from legacy apps remain, AD continues in a shrunk form as an authentication server, and inventorying remaining roles and setting deadlines is the job of the final stage
    gpoempty["GPO is empty"] --> remain{"What remaining roles are there?"}
    remain -->|File-server authentication| keep["Continue in a shrunk form as an authentication server"]
    remain -->|Legacy LDAP lookups| keep
    remain -->|No remaining roles| retire["Consider retiring AD itself"]
    keep --> task["Carry through inventory and deadline-setting"]

Figure 15: Even after GPO is empty, if remaining roles exist, AD continues in a shrunk form as an authentication server.

8. The Pitfalls

8.1. Dual Application of GPO and MDM — By Default GPO Wins

During the migration period, both GPO and Intune will deploy settings to the same PC (a hybrid-joined machine). Here, when the same setting conflicts, Group Policy wins by default. Setting Policy CSP’s MDMWinsOverGP to 1 makes the MDM-side setting win and blocks the corresponding GPO setting, but that mechanism applies only to settings under Policy CSP and does not apply to settings defined in other CSPs such as Defender CSP. Microsoft itself states that if you configure a setting that is not under MDMWinsOverGP from both GPO and MDM, you enter a conflict state and there is no guarantee which wins.¹⁴

flowchart TB
    accTitle: Precedence when GPO and MDM conflict
    accDescr: If you deploy the same setting from both GPO and MDM, GPO wins by default; setting MDMWinsOverGP to 1 makes MDM win only for settings under Policy CSP, and for settings in other CSPs there is no guarantee which wins
    both["Deploy the same setting from both GPO and MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|No| gpowin["GPO wins (default)"]
    flag -->|Yes| csp{"A setting under Policy CSP?"}
    csp -->|Yes| mdmwin["MDM wins"]
    csp -->|No| unknown["No guarantee which wins"]
    both -.-> avoid["The principle is not to deploy from both"]

Figure 16: By default GPO wins, and MDMWinsOverGP applies only under Policy CSP. The principle is to avoid dual deployment.

The practical principle is simple. Do not rely on precedence control; do not deploy the same setting from both. For a setting you have moved to Intune, put the corresponding GPO-side configuration back to “Not configured”, or unlink the GPO altogether. Chapter 6’s migrated list is also the ledger for this.

8.2. Dependence on On-Premises Assets — Network Drives and Printers

Many of the places a migration stalls are not Intune features but connectivity to on-premises assets. Access itself from an Entra-joined machine to an on-premises file server is possible,² but if drive maps and printer deployment depended on a GPO logon script, that deployment means disappears first. Decide during the pilot whether to fold a share migration to OneDrive/SharePoint or a replacement with Universal Print into stage (3), or to bridge for the time being with script deployment.¹²

flowchart TB
    accTitle: Replacing deployments that depend on on-premises assets
    accDescr: If drive maps and printer deployment depend on a GPO logon script, that deployment means disappears first in the migration, so decide during the pilot whether to respond with a share migration to OneDrive or SharePoint, a replacement with Universal Print, or script deployment for the time being
    dep["Dependence on a logon script"] --> lost["The deployment means disappears in the migration"]
    lost --> share["Migrate to OneDrive/SharePoint"]
    lost --> print["Replace with Universal Print or similar"]
    lost --> script["Bridge with script deployment"]
    share --> decide["Decide the approach during the pilot"]
    print --> decide
    script --> decide

Figure 17: Deployments that depend on a logon script lose their means first in the migration, so decide the replacement during the pilot.

8.3. Redesigning Provisioning — Autopilot Is Not “Required”

You will sometimes be advised to introduce Windows Autopilot as a set with an Intune migration, but at a procurement scale of a few to a dozen machines a year, signing in with a work account at OOBE and Entra-joining by hand does no real harm. Autopilot starts to pay off when the procurement count grows and unattended setup from unboxing has value, or when you can use device registration on the reseller side. Adding it after (2) and (3) are in place is fine; it is not a prerequisite of the migration.

flowchart TB
    accTitle: The Autopilot introduction decision
    accDescr: At a procurement scale of a few to a dozen machines a year, Entra-joining by hand at OOBE does no real harm; add Autopilot later, when the procurement count has grown and unattended setup has value
    scale{"What is the annual procurement scale?"} -->|A few to a dozen| manual["Manual Entra join at OOBE"]
    scale -->|Once the count grows| ap["Unattended with Autopilot"]
    ap -.-> later["Add it after (2) and (3) are in place"]

Figure 18: While the procurement scale is small, manual Entra join is enough; Autopilot can be added later.

8.4. The Misconception That “It Is No Good Unless Everything Is in Intune”

The last is not a technical problem but a problem of assumption. Coexistence of Entra-joined machines and domain-joined machines is a formally supported configuration,² and “AD is still there = the migration failed” is not true. Companies that run for years with a few settings still left in GPO are not rare, and even then there is great value in the state “every new PC is cloud-managed, and control works off-site too”. Prefer small, reversible advances over the beauty of a complete migration.

flowchart TB
    accTitle: The value of running in parallel without insisting on a complete migration
    accDescr: AD remaining is not a failed migration; even if you run in parallel for years with settings still in GPO, there is great value in the state where every new PC is cloud-managed and control works off-site
    miscon["AD remaining means the migration failed?"] -->|It does not| run["Run in parallel for years with GPO still there"]
    run --> value["New PCs are under control even off-site"]
    value -.-> forward["Prefer small advances"]

Figure 19: Even running in parallel with AD still there, the state where every new PC is cloud-managed has great value.

9. A Realistic Answer for One-Person IT

Finally, a summary of operational design in a company where the person in charge is one (or has the role as a side job).

• Narrow the management items from the start. If you try to bring in every GPO-era setting, you will exhaust yourself on the inventory alone. Start from the five in Chapter 7 (2) (update, encryption, Defender, screen lock, LAPS) and make it a “subtraction design” that adds a setting only when the need arises. The Settings catalog offers thousands of settings,⁷ but you are under no obligation to use them.
• Decide on one standard PC image. Maintain only one standard: “a PC in this company is this set of policies and this set of apps”. Departmental exceptions can be expressed with groups and filters, but the more exceptions grow, the less one person can keep up.
• Ask an external partner for the design and for making templates; keep day-to-day operations in-house. The Intune-migration outsourcing that fails easily is the case where you throw the build over the wall and end up in a state where “nobody understands what the admin screens mean”. Ask the outside for the initial design, templating of policies, and a sounding board for migration decisions, and make the goal a state where you can add a PC and tweak a policy yourself day to day. Put the other way, you should choose a partner that will hand over that far.
• Change one thing at a time. Make policy changes one at a time, and move on only after you have confirmed the result in Intune reports (policy application state and assignment failures). MDM sync is on an about-8-hour cycle,³ and most “it hasn’t applied” is a matter of time, not a fault.

flowchart TB
    accTitle: The operational cycle of a policy change
    accDescr: Make policy changes one at a time, and move on to the next change only after confirming application state in Intune reports. Most cases of it not applying are resolved by waiting for the roughly 8-hour sync cycle
    change["Make only one policy change"] --> report["Confirm application state in reports"]
    report --> next["If there is no problem, on to the next change"]
    next --> change
    report -.-> wait["Most non-application is waiting for sync"]

Figure 20: Make policy changes one at a time, and move on only after confirming the result in reports.

10. Summary

• GPO is a mechanism that assumes reachability to a domain controller, and it structurally does not reach off-site PCs. Intune (MDM) syncs over the internet, so it resolves this problem at the root.
• Migration is not all-or-nothing. Entra-joined machines and domain-joined machines can coexist, and a staged migration that switches new PCs to Entra join plus Intune is the realistic answer for small and medium businesses. There is no conversion path for existing machines, so replacement on the hardware-refresh cycle is the established pattern.
• For small and medium businesses, starting Intune with Microsoft 365 Business Premium (Intune Plan 1 plus Entra ID P1) is realistic. Plan composition keeps changing, though, and some features such as Remediations require a higher licence, so do not take this August 2026 article as gospel; confirm primary sources.
• Inventory of current GPOs can be automated with Group Policy analytics. Convert Ready for migration settings to the Settings catalog, and replace logon scripts and printer deployment that have no counterpart with script deployment, turning the work into an app, or stopping the practice. Note that in a Japanese GPO the support percentage can be inaccurate.
• Advance the migration in the five stages “pilot → baseline policy → app deployment → natural replacement of existing PCs → shrinking AD’s role”, and decide each stage’s exit criterion first.
• A dual-application conflict is won by GPO by default. MDMWinsOverGP is a Policy CSP-only mechanism, so the principle is “do not deploy the same setting from both”.
• When a server-replacement quote lands is the best time to consider this migration. Before “another cycle of AD”, think about where the next five years of PCs will be used.

Related Articles

• A Practical Guide to Group Policy (GPO) — How It Works, Confirming Application, and Choosing Between GPO and Intune
• Windows Update Management After WSUS Deprecation — How to Choose Between WUfB, Autopatch, and Intune
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• Automating PC Provisioning With winget + PowerShell — Making the Runbook Executable
• BitLocker Practical Guide — Drive Encryption Starting With Recovery Key Management
• A Practical Guide to Windows LAPS — Retiring the Shared Local Administrator Password Across All PCs

Related Consulting Areas

KomuraSoft LLC handles design of a staged migration from an AD+GPO environment to Entra ID+Intune (inventorying current GPOs, a policy for reproducing settings, a pilot plan), comparative review of server replacement versus a cloud move, and consultations that reuse existing line-of-business apps and provisioning assets. Starting from considering together “should we buy another AD server” is fine.

• Technical Consulting & Design Review
• Legacy Asset Migration
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

If we migrate from GPO to Intune, can we reproduce every Group Policy setting we use today?

You cannot reproduce all of them. The Intune Settings catalog has thousands of Windows settings, including ones that come from ADMX, and most security settings and restrictions can be moved, but some things — drive maps via logon scripts, bulk printer deployment — have no corresponding MDM setting. If you import an XML export of your current GPOs into Intune's Group Policy analytics, each setting is classified as Ready for migration, Not supported, or Deprecated. For settings that have no counterpart, you cover them by deploying a PowerShell script, turning the work into an app, or simply stopping that setting.

Which licence do we need to use Intune?

The base is Microsoft Intune Plan 1. You can subscribe to it on its own, but in small and medium businesses it is common to use it as part of Microsoft 365 Business Premium (up to 300 users). Business Premium also includes Entra ID P1, so you can go as far as combining compliance policies with Conditional Access. Some features, such as Remediations, separately require a Windows Enterprise E3/E5-class licence. Plan composition changes frequently, so confirm the latest details on Microsoft's official licensing pages before you sign (this article is as of August 2026).

Do we have to retire the AD server immediately?

No. PCs managed with Entra join plus Intune and PCs managed with AD domain join plus GPO can coexist on the same corporate network. A staged migration — leaving AD in place for file-server authentication and existing line-of-business systems, and Entra-joining only new PCs — is realistic. Conversely, there is no supported way to "convert" an existing domain-joined PC to Entra join; a wipe (reset) is required, so the established pattern is to replace existing machines on the hardware-refresh cycle. It is enough to consider retiring AD after the GPOs are empty and you have inventoried the remaining roles.

Why does Group Policy not apply to PCs used for remote work?

Because GPO is retrieved and applied when the PC can reach a domain controller. A PC outside the office can receive the latest policy only when it can reach a domain controller over a VPN or similar, and a home PC that does not use VPN essentially never gets it. Intune (MDM) syncs policy over the internet, so you can manage a PC wherever it is; the problem of managing off-site PCs is resolved by the structure of MDM. In addition to a periodic sync of roughly every 8 hours, a notification-driven sync also runs when policy changes.

If we deploy the same setting from both GPO and Intune, which one wins?

By default, a conflicting setting is won by Group Policy. Setting the MDMWinsOverGP policy to 1 makes the MDM (Intune) side win, but that mechanism applies only to settings under Policy CSP; it does not apply to settings defined in other CSPs such as Defender CSP. Relying on precedence control makes behaviour hard to predict, so in practice the principle is "do not deploy the same setting from both channels", and once a setting has moved to Intune you delete it from the original GPO to avoid dual management.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.