Infrastructure
Migrating from GCPW to Intune and Entra ID
In short
Moving Windows sign-in off Google Credential Provider for Windows onto Microsoft identity and endpoint management is usually driven by three things at once: conditional access policies that GCPW cannot express, device compliance enforcement, and a licensing structure that often costs less than what it replaces. The migration itself is not technically hard. It goes wrong in two predictable places, and both are omissions from the plan rather than failures during execution.
This is written from a completed migration covering 65 users and 27 managed devices.
What you are actually gaining#
GCPW does one job well, which is letting people sign in to Windows with Google Workspace credentials. What it does not give you is a policy engine that can reason about device state, location, risk and application sensitivity before granting access, and it does not enforce device compliance as a condition of that access.
That is the real deliverable. It is worth stating plainly at the start of the project, because the cost case is what gets the migration approved and the access model is what makes it worth doing. Projects framed purely on cost tend to complete as a lift and shift that saves money and changes nothing about the security posture.
The licensing arithmetic#
A meaningful share of the cost difference is licensing structure rather than technology. Bundled licensing that combines endpoint management with identity protection is frequently cheaper than buying the equivalent capabilities separately, and most comparisons are run on per-product list prices and reach the wrong answer.
On a 65 user estate the difference came to several hundred dollars a month against the previous arrangement. Work the bundle economics before you accept anyone's comparison, including your own.
The two things migration plans always omit#
A plan that covers phasing and group-based licensing looks complete. It usually is not, and the same two gaps appear repeatedly.
Federated sign-on back to Google Workspace. If you are keeping Google Workspace as the productivity platform while moving identity to Microsoft, the SAML configuration between them is the piece that makes the whole arrangement coherent. It gets treated as configuration detail and it is not: it determines whether users get one sign-in or two, and whether your conditional access policies actually apply to Workspace access or only to Windows sign-in.
Detailed conditional access policy specifications. Not the intent, the specifications. Which policies, applying to which groups, under which conditions, with which controls, and what happens on failure. Plans routinely say conditional access will be implemented and leave the design to execution, at which point it gets built by whoever is on the keyboard.
Both gaps have the same cause. Licensing and rollout sequence are visible and easy to plan. Federation and access policy feel like configuration, and they are the parts that decide whether the migration improves security or just relocates it.
Sequence#
1. Design the conditional access policies before touching anything. Written specifications, group scoping, failure behaviour.
2. Configure federated sign-on to Google Workspace. Test it thoroughly with a small group while the old path still exists.
3. Establish administrative roles. Covered below, and it is a prerequisite rather than a task.
4. Unenrol GCPW. Complete this rather than running both paths indefinitely. Identity migrations tempt you into a long dual-running period, which doubles the surface area and means neither path is ever fully trusted. Removing the old dependency forces the new one to be complete.
5. Enrol devices and apply compliance policies. Group-based, phased.
6. Remove elevated access. See below.
Administrative roles are a prerequisite, not a task#
Executing this spans two vendors' administration consoles, and the role assignments needed are specific: endpoint management administration, security administration and conditional access administration on the Microsoft side, plus super administrator on the Google Workspace side.
Establish those before work starts, because discovering a missing role mid-migration stalls it for however long the approval takes.
Plan the removal at the same time as the grant. Elevated access granted for a project reliably outlives the project, and deciding the cleanup at the point of granting is the only version of this that actually happens. Write it into the project close criteria rather than leaving it as an intention.
What to watch during execution#
Do not let the pilot group be the easy users. Compliance policies fail on the awkward devices, and those are the ones you want to find early.
Check what breaks when a device falls out of compliance. The policy is only as good as its failure behaviour, and users discovering it for the first time in production is avoidable.
Confirm which sign-in the conditional access policy is actually evaluating. Windows sign-in and Workspace access are different events, and a policy applied to one does not necessarily cover the other.
Common questions#
Can we run GCPW and Intune in parallel during the migration? Briefly, for testing. Not as an extended state. Dual-running doubles the surface area and neither path ends up fully trusted or fully documented.
Do we have to leave Google Workspace? No. Keeping Workspace as the productivity platform while moving identity and device management to Microsoft is a normal end state. The federated sign-on configuration is what makes it work.
How long does a migration of this size take? For 65 users and around 30 devices, several weeks of elapsed time, most of it in policy design and phased enrolment rather than in technical work.
What is the biggest risk? Conditional access policies designed during execution rather than before it. That is how you end up with policies that are either too permissive to be useful or restrictive enough to generate a support incident on day one.
Is the cost saving real? It was on the estate described here, driven by the licensing bundle rather than by the products. Check your own bundle economics rather than assuming either direction.