Why ConfigMgr co-management stalls—and how to make the next decision

“Co-management is enabled” is not a migration plan

Co-management gives an organization a way to use Configuration Manager and Intune together for Windows devices, but enabling the capability does not settle ownership, workload boundaries, or rollout readiness. A program can remain stuck for months when the team treats the feature state as the outcome. A useful outcome is a tested decision about which management service is authoritative for a defined workload and device population, with evidence that users and support are ready for the change.

Begin by documenting the current state: which devices are eligible and enrolled, which workloads are assigned to which authority, what exceptions exist, and how the team confirms the state on a device. Do not assume that all devices share one path. Collections, enrollment conditions, network constraints, licensing, or special use cases may mean the visible dashboard represents only part of the estate.

Then ask what “stalled” means. Is there a technical prerequisite, a policy conflict, an unclear owner, a failed pilot, a support concern, or simply no decision about the desired end state? These are different problems. A technical retry cannot solve an unowned decision, and another strategy presentation cannot repair a workload that has not been validated on representative devices.

Find the actual blocker by workload

Break the transition into workloads and dependencies. For each one, record its intended authority, current deployment method, target population, prerequisites, operational owner, and evidence of success. Check relevant Configuration Manager site and client health, Intune enrollment, policy assignments, licensing, and network dependencies. Verify product-specific requirements in current Microsoft guidance rather than relying on remembered prerequisites from a previous release or environment.

Look for overlapping intent. A workload may be moved while a legacy policy, application deployment, or collection-based process continues to shape the result. The issue is not always a direct conflict: it may be that the team cannot tell which system caused the observed state. Build a small device-level trace for representative examples, including assignment, reporting, check-in, and recent changes. Preserve evidence before altering both sides.

Dependencies outside endpoint engineering often explain delays. Security may need to approve policy parity; service desk may need new triage guidance; application owners may not have validated delivery; identity may have enrollment constraints. Bring each owner a specific decision and evidence request. “Please support co-management” is not actionable. “Confirm whether this device group can receive the intended update policy and what evidence the security team needs before moving authority” is.

• Inventory authority and target population per workload, not only per device.
• Check prerequisites and current product documentation for the actual environment.
• Trace assignments and observed state across both management systems.
• Name cross-team decisions that block a change and request specific evidence.

Pilot a decision, not a feature toggle

Pick one bounded workload and a cohort that represents its real support conditions. Define a success measure, observation window, stop condition, and accountable approver. For example, a pilot should determine whether the intended policy reaches the target devices, whether the observed state is correct, whether users notice an unacceptable impact, and whether support can identify the right management owner. A console status alone is not enough.

Avoid moving several workloads at once to accelerate the calendar. If a device changes update behavior, compliance, application delivery, and configuration together, failures become difficult to attribute and rollback becomes less clear. Make one planned change at a time where practical, record the previous state, and confirm how the organization will restore or contain the change. A rollback does not necessarily reverse actions already taken by a policy or application.

Use a cohort small enough for the team to respond, but broad enough to include meaningful variation. Include a known-good comparison and avoid selecting only cooperative test devices if production will include remote or constrained devices. If the test discovers a gap, pause and decide whether to correct the design, change the target population, or defer that workload. A deliberate no-go is a valid pilot result.

Unstick the program with a decision log

Co-management programs often accumulate “temporary” assignments and unresolved assumptions. Maintain a short decision log with the choice, alternatives considered, evidence, owner, date, affected population, and review trigger. Record the reason a workload remains with Configuration Manager just as carefully as the reason it moves. The point is not to enforce a cloud-first slogan; it is to make each state intentional and revisitable.

Schedule regular review of blockers with the right owners present. Close questions that have evidence, assign an owner and due date to open prerequisites, and identify decisions that require leadership. Use a visible dependency map so teams understand why a seemingly small move depends on identity, networking, application packaging, or service operations.

The exit from co-management may be different by workload or population. Retire old assignments only after proving they are no longer needed and confirming that records, support procedures, and change control are updated. Keep an overlap only when it has a documented purpose and a way to detect conflicting intent. An intentional hybrid state can be supportable; an accidental one is expensive to diagnose.

Next-step checklist

Co-management behavior and prerequisites depend on the organization’s Configuration Manager and Intune configuration. Validate current Microsoft Learn documentation, licensing, administrative permissions, and client state before implementation. Changes to update, security, application, or compliance authority can materially affect production devices and should pass local change approval and a representative pilot.

The most useful next step is the smallest one that resolves a real uncertainty. It may be a health check, a workload decision workshop, a pilot, or a support runbook—not necessarily another broad migration phase. Make the evidence visible, then let the next decision follow from it.

• A named workload and target cohort define the next test.
• Success, stop, support, and rollback criteria are agreed before assignment changes.
• Cross-team dependencies have owners and evidence requests.
• Old authority is removed only after a verified replacement and support handoff.