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

“The AD server’s maintenance window has run out. Should we replace it as planned and keep running Group Policy for another five years?” “Settings reach our remote-work PCs only when they connect to the VPN.” Small and medium businesses bring us these questions more and more often.

The axis of this article is not whether to buy a new AD server, but what you will use to manage PCs outside the office for the next five years. Migration is not all-or-nothing. There is a way to keep AD while switching to Entra join plus Intune starting with new PCs.¹

Start by picking the section that matches what you want to decide right now.

Scope of This Article

The audience is IT staff and business owners at small and medium businesses. The article lays out the differences between GPO and MDM, the required configuration and licensing, the inventory, the staged migration, and the pitfalls, based on primary sources such as Microsoft Learn as of August 2026. Plan composition in particular changes, so confirm the latest contents in official information before signing a contract.

On-premises Active Directory (AD) and Group Policy (GPO) are mechanisms that assume “the PC is on the corporate LAN and can reach a domain controller at any time.” With take-home PCs and remote work now the norm, that assumption has collapsed. WSUS, long the standard for update management, was also deprecated in September 2024, and the center 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 center of management
    accDescr: AD and GPO are mechanisms that assume the PC is on the corporate LAN and can reach a domain controller at any time, but with take-home PCs and remote work now the norm that assumption has collapsed, and with WSUS deprecated as well the center of management has moved to Entra ID and Intune
    adgpo["On-premises 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 collapsed"]
    premise --> broken
    wsus["WSUS deprecated"] --> shift["Center of management moves to Entra ID+Intune"]
    broken --> shift

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

1. The Bottom Line First

The migration policy is built from the following three points.

1. Change how management reaches off-site PCs. GPO requires a connection to a domain controller, whereas Intune syncs over the internet. Note, however, that the steady-state sync runs roughly every 8 hours and is not a mechanism that guarantees immediate application. A notification-driven sync also runs when a policy changes.³
2. Switch starting with new PCs, and coexist with the existing environment. Realistically, new and replacement machines get Entra join plus Intune, and existing domain-joined machines stay hybrid-joined and are replaced on the hardware-refresh cycle. Retiring AD immediately is not a condition of the migration.¹
3. Do not reproduce GPO wholesale; sort it setting by setting. Take an inventory with Group Policy analytics, discard the settings you no longer need, and for the ones you do need either move them to Intune or design a substitute. The principle is never to deploy the same setting from both GPO and MDM.⁴⁵

The main jobs, such as Administrative Templates, update management, BitLocker, LAPS, and app deployment, have counterparts on the Intune side. Logon scripts, drive maps, and printer deployment, on the other hand, are the classic examples that cannot be moved as they are. Chapters 5 and 6 lay out where each one goes.

For small and medium businesses, Microsoft 365 Business Premium, which includes Intune Plan 1 and Entra ID P1, is the realistic starting point. It does not, however, include every Intune feature. Chapter 4 covers licensing and cost.⁶⁷

Recast the question from “should we replace the AD server for another cycle” to “what will we use to manage PCs outside the office for the next five years,” and what needs to be compared comes into view.

flowchart LR
    accTitle: Recasting the question to decide
    accDescr: The question of whether to replace the AD server for another cycle is recast as the question of what you will use to manage PCs outside the office for the next five years, and decided on that basis
    q1["Replace the AD server for another cycle?"] -->|Recast| q2["Next 5 years: what manages off-site PCs?"]

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

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (20 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

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

What Differs Is Not Only the Settings but How They Are Delivered

Start by comparing GPO and Intune from the same viewpoints. The LSDOU order of GPO application and how to check with gpupdate / gpresult are covered in “A Practical Guide to Group Policy (GPO)”, so this section narrows to the differences that matter for the migration decision.

What matters most for the migration decision is where policy comes from and how it reaches off-site PCs. GPO fails to reach a home PC because the design assumption that “the PC sits where it can reach a domain controller” no longer matches how people work today.

There is also the path of requiring always-on VPN from every employee to keep GPO alive. That, however, is a choice to take on maintaining another piece of infrastructure: the VPN platform.

flowchart TB
    accTitle: The choice between keeping GPO alive and migrating to MDM
    accDescr: GPO fails to reach a home PC 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 another 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["Take on maintaining another piece of infrastructure"]

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

“Reaching Off-Site PCs” and “Taking Effect Immediately” Are Different Things

With Intune, management reaches any PC connected to the internet, wherever it is. The steady-state sync, however, runs about every 8 hours, coarser than GPO’s periodic refresh of about 90 minutes. Do not migrate while still assuming that “once deployed, it applies immediately.”

When a policy is assigned or changed, a notification is sent to the device and it syncs relatively promptly. A manual sync from the admin center or the device is also possible, but controls that require immediacy, such as an emergency block, must be designed around the sync interval.³

flowchart TB
    accTitle: How GPO and MDM deliver policy
    accDescr: GPO applies only when the PC can connect to an in-house domain controller, so a home PC depends on VPN, whereas Intune syncs over the internet roughly every 8 hours and also syncs on a notification when a policy changes, so it reaches a PC wherever it is
    officepc["An in-house PC"] -->|At startup, sign-in, and periodic refresh| dc["Domain controller"]
    homepc["A home PC"] --> vpn{"Reaches the DC over VPN?"}
    vpn -->|Yes| dc
    vpn -->|No| miss["The latest policy never arrives"]
    anypc["A PC wherever it is"] -->|Sync about every 8 hours| intune["Intune service"]
    intune -.-> notify["Syncs on notification when a policy changes"]

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

The PC’s Join Type Determines Which Management Tools You Can Use

There are three forms in which a Windows PC “joins the company.”¹

Hybrid join is the form in which an existing domain-joined PC is also registered in Entra ID. It lets you start using Intune and Conditional Access while keeping existing assets. Microsoft, however, recommends not treating hybrid join as the final goal and Entra-joining new and replacement PCs.¹

Existing PCs Need a Wipe, So Switch at Replacement Time

There is no Microsoft-supported way to convert a domain-joined PC (including hybrid join) to Entra join. A Windows reset (wipe) is required. That is why moving to Entra join at hardware-refresh or OS-reinstall time is recommended.¹

flowchart TB
    accTitle: The three join types and the migration paths
    accDescr: An AD-domain-join-only PC can also be registered in Entra ID to 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 official way to convert an existing domain-joined machine to Entra join; the established pattern is to switch starting with new and replacement PCs.

A migration policy for a small or medium business is easier to lay out if you treat PCs and AD separately.

Entra-joined machines and domain-joined machines can coexist in the same corporate environment. You do not have to retire existing PCs or AD all at once to start the new management model.¹

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 kept for the time being 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["Keep AD for remaining roles"]

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

SSO to On-Premises Assets Has Two Separate Prerequisites

An Entra-joined machine can also access on-premises resources such as a file server. However, being Entra-joined alone does not satisfy the prerequisites for single sign-on (SSO) to on-premises assets. Check the following two points.¹⁸

In the migration plan, first identify any users or usage scenarios that fail these two points. In other words, check managing off-site PCs with Intune and connecting to in-house assets as two separate matters.

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 synchronized by 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)

Confirm What You Can Start With on Business Premium

The base license is Microsoft Intune Plan 1. It is offered both as a standalone subscription and bundled into various Microsoft 365 plans.⁶

For small and medium businesses, the important point 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 you can configure everything up to compliance policies plus Conditional Access.⁷

Business Standard and Basic do not include Intune. If you move from a mail-and-Office-only contract into device management, the price difference of upgrading to Business Premium is the effective cost of adopting Intune.

flowchart TB
    accTitle: How SMB plans relate to Intune
    accDescr: Business Premium for up to 300 users includes Intune Plan 1, Entra ID P1, and Defender for Business and goes all the way to 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["Goes all the way to 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.

Some Features Visible in the Console Require a Separate License

Two points deserve particular attention.

Plan composition is not fixed. Even in 2026, revisions of what is bundled have continued, such as changes that redistribute Intune Suite features into higher Microsoft 365 plans (E3/E5 and the like). Treat this section as information as of August 2026, and confirm the official licensing and pricing pages before signing a contract.⁶

Being able to use a feature from the Intune admin center and being entitled to use it under your contract are different things. The representative example is Remediations. It requires a Windows Enterprise E3/E5-class license (bundled in Microsoft 365 E3/E5 and the like) and is not available within the scope of Business Premium. Chapter 5 lays out the alternatives.⁹

What You Compare Is Not “a Subscription Versus Zero” but Five Years of Cost

The GPO side also has costs: replacing the AD server hardware, Windows Server licenses and CALs, the build, five years of maintenance, backups, and incident response.

Put the server-replacement quote next to five years of Business Premium and look at the difference. Then factor in the capability difference: whether management reaches off-site PCs. That is the axis of the cost comparison.

flowchart TB
    accTitle: The right way to think about the cost comparison
    accDescr: The GPO side also incurs costs such as AD-server replacement, licenses, 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, licenses, CALs"]
    gpocost --> ops["Build, maintenance, backups"]
    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 Did with GPO

The Main Jobs Have Intune Counterparts

Before carrying GPO names and settings over as they are, map the job each one did to its destination.

The Settings Catalog Is Where Administrative Templates Go

The Settings catalog is the screen that corresponds to a “cloud edition of the Group Policy editor.” Microsoft also positions it as the natural migration destination when you want the same fine-grained configuration as with on-premises GPO.

It includes ADMX-backed policies, the MDM versions of settings defined in ADMX, and there is also a feature (in preview) for importing third-party ADMX.¹⁰

Choose the Script Mechanism by When You Want It to Run

Remediations, renamed from Proactive remediations, runs a pair of detection and remediation scripts on a schedule. It replaces the kind of operation that “fixes something at every logon,” but it requires the Windows Enterprise E3/E5-class license described in Chapter 4.⁹

Within the scope of Business Premium, the realistic approach is to combine platform scripts with Win32 app detection rules. A platform script runs after assignment, reruns when the script or the assignment changes, and retries on failure; keep it distinct from Remediations, which runs on a schedule.¹⁶

Separate “Judging Compliance” from “Blocking Access”

Compliance policies plus Conditional Access is an idea GPO never had. You define compliance conditions such as “BitLocker on, OS up to date, Defender running” and can block access to Microsoft 365 from devices that do not meet them.¹¹

The roles split in two. A compliance policy judges compliance state; Conditional Access controls access. The block takes effect only when a Conditional Access policy requires a compliant device. Conditional Access is an Entra ID P1 feature and is included in Business Premium.¹¹

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 up to date, 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.

Update-management options (deciding among WUfB, Autopatch, and continuing WSUS) are covered in detail in “Windows Update Management After WSUS Deprecation”, and BitLocker and LAPS design in “BitLocker Practical Guide” and “A Practical Guide to Windows LAPS”.

6. Inventorying the Current GPOs — Sorting with Group Policy Analytics

The First Hands-On Work Is Analyzing GPOs Setting by Setting

The first hands-on work in a migration plan is inventorying the current GPOs. With Group Policy analytics, built into Intune, you can sort settings by whether they can migrate to MDM, setting by setting, without reading through the GPOs by hand.⁴

Through this flow you can move the supported settings to the Intune side.⁴

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 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 sorting, and conversion to the Settings catalog: that is the Group Policy analytics flow.

With Japanese GPOs, Do Not Decide on the Support Percentage Alone

Analysis of non-ADMX settings is supported in English only. Importing a GPO that contains settings in a language other than English can make the MDM support percentage inaccurate. Be especially careful in Japanese environments.⁴

The support percentage is a rough reference figure. Make the final decision from the per-setting list.

flowchart TB
    accTitle: A caveat when analyzing a Japanese GPO
    accDescr: Analysis of non-ADMX settings in Group Policy analytics is supported in English only, and a GPO that contains Japanese settings can make the MDM support percentage inaccurate, so treat the percentage as a rough reference and make the final decision 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 decision from the per-setting list"]

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

Split the Analysis Results into “Discard,” “Move,” and “Substitute”

Whether the tool says a setting can migrate and whether you will still need that setting are separate decisions.

A GPO that has been run for ten years holds a considerable amount of old settings. Being able to discard unneeded settings is itself a major outcome of the inventory. You do not have to move every setting that can be moved.

Representative examples that have no corresponding setting, and the direction for a substitute, are as follows.

flowchart TB
    accTitle: The three categories 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 corresponding setting and for which a substitute is designed
    result["Sorting results"] --> discard["Settings to discard"]
    result --> move["Settings to move to Intune"]
    result --> alt["Settings that need a substitute"]
    discard -.-> legacy["Dispose of the accumulated legacy"]
    move --> pilot["Convert to the Settings catalog and validate"]
    alt --> design["Script deployment or packaging as an app"]

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

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

Settle “What to Do” and “When It Is Done” Up Front

Split the rollout into five stages and put an exit criterion on each. So that the migration does not stall even with a one-person IT department, decide “when we can say it is done” before starting the work.

flowchart TB
    accTitle: The 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 the 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.

(1) Pilot: Start with the PCs You Are Buying Anyway

Start with newly procured PCs, such as the next new hire’s PC or a replacement for a failed machine. The advantages are that you can try it without buying extra PCs, and if it fails you can wipe and start over.

Once the number grows, consider Windows Autopilot, which automates everything from OOBE (initial setup) through Entra join and Intune enrollment. It is not required from the outset.¹

(2) Baseline Policy: Narrow It to Five Items at First

Do not try to reproduce every GPO setting; start with five items: updates, encryption, Defender, screen lock, and LAPS. Make compliance state visible with a compliance policy.

Enable “compliant devices only” in Conditional Access only after you have confirmed in the pilot that there are no false positives.¹¹

(3) App Deployment: Cut Manual Work Out of Provisioning

App deployment leads directly to automating provisioning. If you already have winget-based procedures in place, that asset can be reused almost as it is as Store apps (new) or as wrappers for Win32 apps.¹⁵

For how to move from a runbook to automation, see “Automating PC Provisioning With winget + PowerShell”.

(4) Existing PCs: Follow the Hardware-Refresh Cycle

As Chapter 3 explained, there is no official path to convert an existing domain-joined PC to Entra join without a wipe. The principle is replacement on the hardware-refresh cycle; wipe and switch only the PCs you want to bring forward.

Organizations that still have a Windows 10 replacement plan can avoid doing the work twice by running it at the same time as that plan. The options are laid out in “Practical Options After Windows 10 End of Support”.

(5) Shrinking AD’s Role: Even with GPO Empty, the Authentication Role Can Remain

GPO being empty is not the same as AD being unnecessary. If file-server authentication or LDAP lookups from legacy apps remain, AD continues in a reduced role as an authentication server.

This stage’s work runs through inventorying the remaining roles and setting a deadline. When no role remains, consider retiring AD itself.

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 reduced role as an authentication server, and inventorying the remaining roles and setting a deadline is the job of the final stage
    gpoempty["GPO is empty"] --> remain{"What roles remain?"}
    remain -->|File-server authentication| keep["Continue in a reduced role as an authentication server"]
    remain -->|Legacy LDAP lookups| keep
    remain -->|No roles| retire["Consider retiring AD itself"]
    keep --> task["Carry through the inventory and deadline-setting"]

Figure 15: Even after GPO is empty, if roles remain, AD continues in a reduced role as an authentication server.

8. Pitfalls

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

During the migration period there will be situations where both GPO and Intune deploy settings to hybrid-joined machines. If the same setting conflicts there, the GPO side wins by default.

Setting MDMWinsOverGP in Policy CSP to 1 makes the MDM-side setting win and blocks the corresponding GPO setting. However, it covers only settings under Policy CSP. It does not apply to settings defined in other CSPs such as Defender CSP. Microsoft also states explicitly that if you configure a setting outside its control from both GPO and MDM, there is no guarantee which one 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 one 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 one wins"]
    both -.-> avoid["Principle: do not deploy from both"]

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

The practical principle is not to rely on precedence control and not to deploy the same setting from both sides. Once a setting has moved to Intune, set the corresponding GPO setting back to “Not Configured” or unlink the whole GPO. Recording inventoried settings on the migrated list from stage (2) in Chapter 7 is also a way of avoiding dual management.

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

Most of the sticking points are not Intune features but connections to on-premises assets. Even if an Entra-joined machine can access the file server, if drive maps and printer deployment rely on GPO logon scripts, that delivery mechanism alone disappears first.¹

Decide during the pilot whether to move shares to OneDrive / SharePoint, replace them with Universal Print, or bridge the gap with script deployment for the time being. If you replace them, build that into the app deployment stage, (3) in Chapter 7.¹⁶

flowchart TB
    accTitle: Replacing deployments that depend on on-premises assets
    accDescr: If drive maps and printer deployment depend on GPO logon scripts, that delivery mechanism disappears first during the migration, so decide during the pilot whether to handle it by moving shares to OneDrive or SharePoint, replacing with Universal Print, or bridging with script deployment for the time being
    dep["Dependence on logon scripts"] --> lost["The delivery mechanism disappears in the migration"]
    lost --> share["Move 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 logon scripts lose their delivery mechanism first in the migration, so decide on the replacement during the pilot.

8.3. Redesigning Provisioning — Autopilot Is Not “Required”

Autopilot is sometimes recommended as a package deal with an Intune migration, but if you procure a few to a dozen or so PCs a year, signing in with a work account during OOBE and Entra-joining by hand does no real harm.

Autopilot pays off when procurement volume grows and unattended setup straight out of the box becomes worthwhile, or when you can use device registration by the reseller. Add it once stages (2) and (3) in Chapter 7 are in place; it is not a prerequisite for the migration.

flowchart TB
    accTitle: Deciding whether to adopt Autopilot
    accDescr: At a procurement scale of a few to a dozen or so PCs a year, Entra-joining by hand during OOBE does no real harm, and Autopilot can be added later once procurement volume grows and unattended setup becomes worthwhile
    scale{"Annual procurement scale?"} -->|A few to a dozen or so| manual["Entra-join by hand during OOBE"]
    scale -->|Once the volume grows| ap["Unattended setup with Autopilot"]
    ap -.-> later["Add it once (2) and (3) are in place"]

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

8.4. The Misconception That “Everything Must Be on Intune”

Coexistence of Entra-joined and domain-joined machines is an officially supported configuration. AD still being there does not mean the migration has failed.¹

It is not unusual for a company to run both side by side for several years with a handful of settings still in GPO. Even so, a state in which every new PC is managed from the cloud and stays under control off-site has great value. Rather than insisting on the shape of a complete migration, prioritize small, reversible steps forward.

flowchart TB
    accTitle: The value of running side by side without insisting on a complete migration
    accDescr: AD still being there does not mean the migration failed, and even running side by side for several years with settings still in GPO, a state in which every new PC is cloud-managed and under control off-site has great value
    miscon["AD still there, so the migration failed?"] -->|Not so| run["Run side by side for years with GPO still there"]
    run --> value["New PCs stay under control off-site"]
    value -.-> forward["Prioritize small steps forward"]

Figure 19: Even running side by side with AD still there, a state in which every new PC is cloud-managed has great value.

9. The Realistic Approach for a One-Person IT Department

In a company where IT is one person or a part-time role, decide up front how much you can keep maintaining after adoption.

Narrow the Managed Items and the Standard PC Profile

Narrow the initial managed items to the five from stage (2) in Chapter 7 (updates, encryption, Defender, screen lock, LAPS). The idea is to add only the settings for which a need has arisen. Even though the Settings catalog has thousands of settings, you are under no obligation to use them all.¹⁰

Also settle on a single standard PC profile: “a PC at this company gets this set of policies and this set of apps.” Per-department exceptions can be expressed with groups and filters, but the more exceptions there are, the harder it becomes for one person to maintain.

Have Outsiders Do the Design, and Be Able to Run Daily Operations Yourself

Ask an external partner for the initial design, policy templates, and advice on migration decisions. Make it the goal that you can do the day-to-day work, adding PCs and fine-tuning policies, yourself.

It is important not to hand over the entire build and end up in a state where “nobody understands what the admin center means.” Choose a partner who will hand over daily operations as well.

One Change at a Time, Confirmed in the Reports Before the Next

Make policy changes one at a time, and check the application status and assignment failures in Intune’s reports before moving on to the next.

MDM’s steady-state sync runs on a cycle of about 8 hours. Most cases of “it is not applying” are a matter of time, not a fault, so check results with the sync interval in mind.³

flowchart TB
    accTitle: The operating cycle for policy changes
    accDescr: Make policy changes one at a time, and check the application status in Intune's reports before moving on to the next change. Most cases of a change not applying resolve once the roughly 8-hour sync has run
    change["Make one policy change only"] --> report["Check the application status in the reports"]
    report --> next["If there is no problem, move to the next change"]
    next --> change
    report -.-> wait["Most unapplied cases are waiting for sync"]

Figure 20: Make policy changes one at a time, and check the results in the reports before moving on.

10. Summary

Migrating from GPO to Intune is an effort to change how management reaches off-site PCs and to reduce unneeded settings. GPO assumes reachability to a domain controller, whereas Intune syncs over the internet. You do, however, need to operate with the roughly 8-hour steady-state sync interval and the notification on change in mind.

The basic approach is a staged migration: switch new PCs to Entra join plus Intune and replace existing PCs on the hardware-refresh cycle. Check the prerequisites for SSO to on-premises assets, and keep coexisting if AD retains roles such as authentication.

Inventory the current GPOs with Group Policy analytics and sort them into “discard, move, substitute.” Treat the support percentage of a Japanese GPO as a reference figure and decide setting by setting. Then advance through the five stages, pilot, baseline policy, app deployment, replacing existing PCs, and shrinking AD’s role, each with an exit criterion.

During the migration the principle is not to deploy the same setting from both GPO and MDM. Because MDMWinsOverGP can give MDM precedence only under Policy CSP, build a configuration that does not depend on precedence control.

Business Premium can be the licensing starting point, but confirm the coverage of features such as Remediations and the latest contract contents in official information. For cost, compare the server replacement with the five-year difference, and factor in the capability difference of managing off-site PCs as well.

When the server-replacement quote arrives is a good moment to consider this migration. Before “another cycle of AD,” start by thinking about where the PCs of the next five years 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 the design of staged migrations from AD plus GPO environments to Entra ID plus Intune (inventorying current GPOs, the policy reproduction strategy, pilot planning), comparative studies of server replacement versus cloud migration, and migrations that make use of existing business apps and provisioning assets. Starting from “should we buy an AD server again?” and working through it together is perfectly fine.

• Technical Consulting & Design Review
• Legacy Asset Reuse & Migration Support
• Contact

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?

Not all of them. The Intune Settings catalog has thousands of Windows settings, including ones derived from ADMX, and most security settings and restrictions can be moved, but some things, such as drive maps via logon scripts or 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 by migration readiness (Ready for migration / Not supported / Deprecated). Settings with no substitute are handled by deploying a PowerShell script, packaging the work as an app, or simply dropping that setting.

Which license do we need to use Intune?

The base is Microsoft Intune Plan 1. It can be subscribed to on its own, but small and medium businesses commonly 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. On the other hand, some features, such as Remediations, separately require a Windows Enterprise E3/E5-class license. Plan composition changes frequently, so confirm the latest contents on Microsoft's official licensing pages before signing a contract (this article is as of August 2026).

Do we have to retire the AD server right away?

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 that leaves AD in place for file-server authentication and existing line-of-business systems and Entra-joins only new PCs is realistic. Conversely, there is no official 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 once GPO is empty and the remaining roles have been identified.

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

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

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

By default, a conflicting setting is won by the Group Policy side. Setting the MDMWinsOverGP policy to 1 makes the MDM (Intune) side win, but that mechanism works only for settings under Policy CSP; it does not apply to settings defined in other CSPs such as Defender CSP. Relying on precedence control makes behavior hard to predict, so in practice the principle is "do not deploy the same setting from both channels," and the safe approach is to delete a setting from the original GPO once it has moved to Intune, avoiding 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.