Migration & co-existence

Most Intune projects inherit an estate that already works — Group Policy, a domain, years of local decisions. This section is how Decolla brings that estate in without breaking it, and without pretending co-existence is the destination.

Why this matters

The riskiest phase of an Intune adoption is not provisioning new devices. It is the window where Group Policy and MDM both believe they own the same machine. Settings fight, and the loser is usually a user's mapped drive, proxy configuration or sign-in experience. MDMWinsOverGP looks like the switch that resolves this — but flipped fleet-wide without a conflict map, it turns a quiet estate into a ticket generator.

Meanwhile the AD side rots quietly: computer objects sitting in the wrong OUs, device policies still targeted at user groups that stopped being accurate years ago, local admin passwords that have never been rotated. And underneath all of it sits user data — one lost desktop folder during a refresh costs more goodwill than the rest of the project earns.

What a good build does

Discovery happens before the build, not partway through it. The evidence-gathering is read-only, so it runs in Assessment & posture readiness — migration decisions rest on a conflict map, not hope.

Decolla then treats co-existence as a ladder of commitment rather than a leap: tenant attach first (visibility only, the lowest-risk step), co-management with guidance for each workload slider, and hybrid join strictly as a bridge for domain-bound fleets. MDMWinsOverGP ships default OFF and is applied only where Policy-CSP conflicts have actually been identified.

User data gets the same staging: a verified backup before provisioning touches anything, and a single in-use machine converted to a managed pilot before the estate follows. Every step lands in the written, itemised plan with a delivery and reversibility class, irreversible steps flagged, and per-item rollback of Decolla's own changes — which, stated honestly, covers what Decolla changed, not what your domain did before it arrived. One item here, WhatsApp encrypted backup provisioning, carries single-client provenance and is flagged client-SOP tier rather than dressed up as core catalogue. The doctrine underneath is blunt: rebuild bottom-up from a clean baseline. Co-existence is a bridge, not a place to live.

Where it bites people

Two gotchas recur in almost every co-existence project.

• MDMWinsOverGP over-promises in most admins' mental model. It arbitrates only ADMX-backed settings in the Policy CSP — Group Policy Preferences, scripts and anything without a CSP equivalent keep applying from the domain regardless. Enable it fleet-wide expecting "MDM now wins" and you get partial, asymmetric behaviour that is harder to debug than the original conflicts were. Default off, scoped to identified conflicts, evidence first.
• Stale user-group assignments on device policies. A device carries configuration because a user who signed in years ago happened to be in a group. During co-management workload moves, targeting turns unpredictable and nobody can answer "why did that laptop get that policy". Pruning those assignments before any workload shifts is dull work — and it is the difference between a migration and an archaeology project.

What's in this section (24 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.