Free tool
CSP Management Advisor
How many policies, and how do you cut them?
Migrating GPOs to CSPs is not only a setting-by-setting mapping exercise. The expensive question comes afterwards: how do you cut the settings into policies so the tenant stays manageable, with no silent conflicts. This tool compares the three possible structures using your own numbers, writes the tracking file that goes with it, and searches your existing policies for settings carried twice.
No sign-up, no cookie: what you enter stays in your browser and is gone when you close the tab — none of it leaves. Only the visit itself is counted, by a cookieless audience measurement that does not identify you, described in the legal notice. The setting names you paste below do not leave the page.
Your policy estate
Four numbers and five answers. The numbers need not be exact: it is the orders of magnitude that tip a structure one way or the other, not the last digit.
The volume to migrate
What differs
The governance in place
The recommended structure
The tool reasons on volumes, not on your settings. It does not say which CSP replaces which GPO: that mapping is done setting by setting, and Group Policy Analytics is where to start. What it does say is how to arrange the result so the tenant stays manageable in two years' time.
The conflict detector compares setting NAMES, not values, and only the ones you pasted. Two policies carrying the same setting with the same value are not a conflict; two carrying it with different values are, and neither is applied. The policy status report in the console remains the only source that confirms it.
Conflict detector
Declare your target policies: a name, the population aimed at, and their list of settings — one per line, as a settings-catalog export or a Group Policy Analytics report gives it to you. Any setting carried by two policies aiming at the same population is flagged. Leave the population empty, or write "all", for a policy assigned to everybody.
The strategy
Three structures, and the real subject: conflicts
The question is not "how do we avoid every conflict" — that cannot be guaranteed. It is "which structure makes conflicts rare, visible and easy to fix".
The decisive point: Intune does not arbitrate conflicts
Two profiles that set the same value on the same setting, for the same device or the same user, conflict. In a direct conflict NEITHER setting is applied — not one, not the other — and NO alert is visible to the end user. Only the policy status report shows it, if somebody goes and looks.
Which is why the question is not "how do we avoid every conflict", which cannot be guaranteed, but "which structure makes conflicts rare, visible and easy to fix". Three structures answer it differently.
Five steps, in order
- Inventory — extract every GPO and the exhaustive list of settings — one line per setting, not per GPO.
- Qualify every setting — viable as is, viable with a deviation, not applicable, or to be dropped.
- Group by function — BitLocker, Delivery Optimization, firewall — one or more target policies per function.
- Build the target policies — this is where the structural question is settled: single baseline, or baseline plus variants?
- Follow the POC → PILOT → Production cycle — every target policy, common or differential, follows the same promotion cycle.
A — Full duplication per population
One whole policy per population, each carrying ALL the settings — identical ones included.
Advantages
- Total isolation: changing one population cannot affect another.
- Easy to understand: one policy, one population.
- Consistent with a POC/PILOT/Production promotion cycle.
Drawbacks
- The number of objects explodes with the number of populations.
- A shared update has to be repeated in every copy — a missed one is undetectable without an audit.
- The risk does not disappear, it moves: drift between copies becomes the new potential conflict.
B — Common baseline + differential policies
A "Common" policy carries everything identical. A setting that must differ is REMOVED from the baseline and lives alone in a targeted differential policy.
Example: a Delivery Optimization baseline keeps the 119 settings that are identical everywhere; the one that has to change for a site leaves the baseline and lives alone in a "Site X" policy, assigned to that site only.
Advantages
- No mass duplication: a single source for what is common.
- The number of differential policies follows the real exceptions, not the number of populations.
- Makes visible, by construction, what is genuinely specific.
Drawbacks
- Strict discipline required: putting a differential setting back into the baseline recreates a conflict.
- The "which setting lives where" mapping has to be documented continuously.
- Requires a clean exclusion from the baseline for every population concerned.
C — Global policy + exclusion + site policy
The global policy stays unchanged for everybody; the population concerned is excluded from it; a complete policy covers it instead.
Advantages
- Defensible for a single exception, on a restricted and stable scope.
- Little drift risk with one object to watch.
Drawbacks
- From a second exception it accumulates A's drawback — duplication — without B's benefit — the single source.
- It is a transitional state towards A or B, not a lasting choice.
What you inventory and convert with
| Tool / approach | What it brings | Cost | When to use it |
|---|---|---|---|
| Group Policy Analytics | Imports a GPO report and flags the known CSP equivalent, setting by setting. | Included in the Intune licence | Always first |
| Tracking file | Records the human decisions: viability, owner, status, phase. | Internal time | Continuously — it is the organisational pivot |
| Third-party GPO migration tools | Speed up bulk conversion on large heterogeneous volumes. | On quotation — no reliable public price | If the volume exceeds what a manual inventory absorbs |
| Pilot on a reduced scope | Validates the mapping and the structure before generalising. | Internal time | Before any move to production |
The tracking file: one line per setting
Not per GPO, not per policy. It is the granularity that answers both dimensions of the subject, technical and organisational — and the only one that answers "where does this setting live" on the day of a conflict. The "Tracking file (CSV)" button above exports its skeleton.
| Column | Content |
|---|---|
| Source GPO | GPO name and setting path |
| Setting | The setting's exact label |
| Target CSP | OMA-URI or equivalent Intune catalogue setting, if known |
| Viability status | Viable / Viable with deviation / Not applicable / To be dropped |
| Carrying policy | Common, or the population's name for a differential |
| Phase | POC / PILOT / Production |
| Business owner | Who validates this setting |
| Last test / Comment | Traceability and observed deviations |
Three governance rules that prevent most of the incidents
Test a baseline setting by EXCLUDING it from the baseline for the test group — never by duplicating it without an exclusion: a duplicate with no exclusion is the very definition of a direct conflict.
The fallback is still removing the assignment; an export of the policy contents is the only reliable source for rebuilding. And every new differential policy is referenced in the tracking file when it is created, not afterwards.
What is left to decide on your side
- The threshold for moving from A to B — number of populations and number of varying settings — the tool above offers a reading, your governance decides.
- Who confirms a setting is "not applicable" — it is a business decision, not a technical one, and it has to be recorded.
- The scope the tracking file covers first — opening everything at once is the surest way to keep nothing up to date.
- Whether the volume justifies a third-party tool — on a real quotation, never on a list price.