|

How to Migrate from Co-Management to Full Intune Management Without Wiping Devices

ByTechieGeek

Migrating from Co-Management to Full Intune Management (Without Wiping Devices)

A lot of environments are now at the same crossroads:

  • You started with ConfigMgr (SCCM) + Intune co-management to ease into the cloud.
  • Over time, you’ve moved more workloads into Intune.
  • Now you want to get rid of the ConfigMgr client and run devices as Intune-only—without wiping and redeploying everything with Autopilot.

You can do this without a full reset, but the exact approach depends on:

  • How the device is joined (Hybrid Azure AD joined vs Entra ID joined).
  • How you’re enrolling into Intune.
  • How you want to stage the cutover to avoid breaking users.

This guide breaks the process down, based on what admins are doing in the field plus the key points from the thread you summarized.

1. Know Your Starting Point

Before you touch anything, get clarity on three things:

  1. Join type
    • Hybrid Azure AD joined
      Joined to on-prem AD + registered in Entra ID.
    • Entra ID joined (Azure AD joined)
      Cloud only, no on-prem domain join.
  2. Enrollment method
    • GPO-based auto enrollment (for hybrid).
    • Autopilot.
    • Manual enrollment / Company Portal.
  3. Where workloads live now
    In the co-management properties (in ConfigMgr), workloads like:
    • Compliance policies
    • Windows Update
    • Endpoint Protection
    • Device configuration
      may still be set to ConfigMgr, Pilot Intune, or Intune.

This tells you how “modern” each device already is and how painful the final switch will be.

2. Strategy for Hybrid Azure AD Joined Devices

Hybrid devices are usually the easiest to move off co-management without a wipe.

Step 2.1 – Make sure Intune enrollment via GPO is solid

If you’re not already doing this, configure MDM auto-enrollment with Group Policy:

  1. In Group Policy Management, create a GPO linked to the OU that contains your hybrid devices.
  2. Configure the “Enable automatic MDM enrollment using default Azure AD credentials” policy.
  3. Make sure the devices are Hybrid Azure AD joined and licensed for Intune.

This ensures that every hybrid device has:

  • A valid MDM enrollment in Intune.
  • A consistent way to stay enrolled even after the ConfigMgr client goes away.

Tip: Use separate OUs to stage migration
For example:

  • OU “Workstations-CoManaged” – full GPO set + ConfigMgr client
  • OU “Workstations-IntuneOnly” – minimal GPO + MDM auto-enrollment GPO
    Moving a computer between OUs gives you a clean, controlled transition path.

Step 2.2 – Gradually shift workloads from ConfigMgr to Intune

In ConfigMgr’s co-management settings:

  1. Move workloads one by one to Intune or Pilot Intune:
    • Compliance
    • Resource access
    • Device configuration
    • Office Click-to-Run
    • Windows Update, etc.
  2. Validate each step:
    • Are policies from Intune applying as expected?
    • Are updates coming via WUfB / Intune instead of WSUS/ConfigMgr?
    • Are there any conflicting settings (GPO vs Intune vs ConfigMgr baselines)?

The goal is that by the time you remove the SCCM client, Intune is already doing the real work.

Step 2.3 – Remove the ConfigMgr client (the key step)

Once you’re comfortable that workloads are living in Intune:

  • Use the standard uninstall command:
ccmsetup.exe /uninstall

You can deploy this:

  • As a ConfigMgr package / app (ironically, one of its last jobs).
  • As a Win32 app or remediation script from Intune (for pilot or cleanup devices).
  • Via any other deployment tool you trust.

When that command completes and the client is removed:

  • The device is no longer co-managed.
  • Intune becomes the sole management authority (plus any remaining GPOs you keep).

There’s no special custom script required beyond this; the key is timing and preparation:

  • Intune enrollment must already be in place.
  • Workloads should already be pointing to Intune.
  • You should know what GPOs you’ll keep vs retire.

3. Strategy for Entra ID Joined Devices

Entra joined (Azure AD joined) devices behave differently:

  • They are not domain joined, so Group Policy is not an option.
  • Co-management here typically comes from:
    • A ConfigMgr client installed post-build (CMG, VPN, or on-prem during imaging).
    • Intune enrollment via Autopilot / Company Portal.

You technically have two options.

Option A – Just remove the ConfigMgr client

This is the fastest, lowest-effort path:

  1. Confirm the device is:
    • Entra joined.
    • Enrolled into Intune and receiving policies/apps successfully.
  2. Deploy the uninstall command:
ccmsetup.exe /uninstall

After that:

  • The ConfigMgr agent is gone.
  • Intune continues managing the device as before.

Pros:

  • No wipe, no user data loss.
  • Minimal user disruption.

Cons:

  • Any old ConfigMgr-era configuration (registry changes, local scripts, scheduled tasks, legacy agents) may still exist.
  • If the device was originally built with a “thick image,” you might keep a lot of historical cruft.

If your environment is relatively clean and modern already, this is often acceptable.

Option B – Autopilot reset / re-provision for a truly “modern” state

If your goal is to be fully cloud native and you suspect years of legacy config, the more robust path is:

  1. Register devices in Autopilot (if not already).
  2. Use Autopilot Reset or a full re-provision:
    • Device is wiped / reset.
    • It comes back Entra joined + Intune enrolled using your latest deployment profile.
    • Users sign in and get apps/policies from Intune only.

Pros:

  • Clean, repeatable state across all devices.
  • Legacy registry hacks, scripts, and old software are removed.
  • Great for long-term manageability.

Cons:

  • It is a reprovisioning operation:
    • Users may need to re-download apps and sync data (OneDrive, etc.).
    • You must communicate downtime and expectations.

That’s why many admins in the field say:

  • Quick, pragmatic cleanup: uninstall ConfigMgr on Entra-joined devices.
  • Strategic modernization project: design an Autopilot-based migration.

4. Handling Policy Order, GPOs, and Conflicts

While you’re moving off co-management, you’ll likely have overlapping policies:

  • GPOs
  • ConfigMgr configuration baselines
  • Intune configuration / security baselines

To avoid chaos:

  1. Define your end-state
    • What should be GPO-only (if anything)?
    • What should be Intune-only?
    • What can be retired entirely?
  2. Use OUs to stage GPO removal (for hybrid)
    • Keep co-managed devices in an OU with the “old” GPO set.
    • Move pilot devices into an OU with a reduced GPO set and MDM-enrollment GPO.
    • Validate that Intune baselines fill the gap.
  3. Document which workloads moved when
    • E.g., “On date X, Windows Update workload moved to Intune; WSUS/ConfigMgr updates disabled.”

That way, when something breaks, you can quickly see which knob you just turned.

5. User Impact and Communication

Even though you’re not wiping machines (in the non-Autopilot path), users can still see changes:

  • New update behaviour (WUfB instead of ConfigMgr).
  • Different restart prompts.
  • New apps or baselines coming from Intune.

Good practices:

  • Run a small pilot first (a few IT machines, then friendly users).
  • Communicate:
    • What you’re doing (“moving PCs from SCCM to Intune”).
    • What might look different (updates, self-service, Company Portal).
    • Who to contact if things break.

This keeps the transition from feeling like a surprise.

6. High-Level Migration Blueprint

Here’s how you can structure the whole project.

Phase 1 – Assessment

  • Inventory:
    • Join types (Hybrid vs Entra).
    • Co-management workloads.
  • Decide:
    • Which devices will be in-place cleanup.
    • Which will be Autopilot reprovision.

Phase 2 – Preparation

  • Ensure Intune enrollment is solid (GPO, Autopilot, etc.).
  • Move key workloads to Intune and validate.
  • Design OUs and GPOs for staged migration (hybrid).

Phase 3 – Pilot

  • For Hybrid:
    • Move a small OU to “Intune-first” posture.
    • Remove ConfigMgr client on a pilot group.
  • For Entra:
    • Pilot the ccmsetup.exe /uninstall path on a few devices.
    • Or pilot Autopilot reset on a test group.

Phase 4 – Broad Rollout

  • Gradually expand:
    • More OUs (hybrid).
    • More collections / groups (Entra).
  • Monitor:
    • Intune reporting (compliance, failures, deployment errors).
    • User support tickets.

Phase 5 – Cleanup

  • Remove:
    • Old ConfigMgr collections, deployments, and co-management configuration.
    • Legacy GPOs that are no longer needed.
  • Update documentation:
    • “Source of truth” for each setting is now Intune.

Key Takeaways

  • You can move from co-management to full Intune management without wiping every device.
  • For Hybrid-joined devices, the common, low-impact pattern is:
    • Use GPO to auto-enroll into Intune.
    • Shift workloads to Intune.
    • Uninstall the ConfigMgr client with ccmsetup.exe /uninstall.
  • For Entra-joined devices, you can:
    • Simply uninstall the ConfigMgr client, or
    • Use Autopilot reset / redeploy for a clean, fully modern state.
  • The success of the project depends less on a fancy script and more on:
    • Clear staging (OUs, workloads, pilots).
    • Good communication.
    • Knowing exactly what your end-state management model should look like.
LinkedInCopyPinterestRedditTelegramChatGPTSMS

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *