# Promote Intune policies to production | TenuVault

Promote Intune policies to production with a reviewed change set. Choose target policies, map dependencies and verify backup, approval and rollback steps.

Canonical: https://www.tenuvault.com/guides/promote-intune-policies-to-production

Practical guide

# Promote Intune policies to production

Promote Intune policies to production with Changes, then Dev to Prod, after selecting the production tenant. Review the planned difference against live production, approve it and apply with a pre-change backup. Promotion copies the reviewed source version once; later development edits need a new operation.

[Start with Community](https://www.tenuvault.com/download)[Plans and features](https://www.tenuvault.com/pricing)

## Can I move a tested policy using native Intune tools?

Settings Catalog JSON export and import can carry a configuration between environments. The release procedure still needs to establish which production policy should change, what dependencies mean in production and whether the tested configuration is the version approved for release.

This guide covers that release handoff. Use the existing testing guide to plan the test itself, including representative devices and assignments. A successful configuration write is evidence about the policy operation; assess device behavior separately before calling the production release complete.

-   [Microsoft Learn: Settings Catalog policy export and import](https://learn.microsoft.com/en-us/intune/intune-service/configuration/settings-catalog)

## How do I promote Intune policies to production?

1\. Connect the development and production tenants and confirm the license scope. Pro includes two tenants and Dev to Prod promotion of supported Settings Catalog settings; MSP includes Pro features. On Pro, the source must be the other tenant of the same license. Use Settings Catalog for the first release exercise.

2\. Select production in the tenant switcher, open Changes and choose Dev to Prod. The selected tenant is the destination. Choose the development source and policy type, then tick Promote for the policies in this release. A promotion holds at most 25 policies, so plan larger releases as reviewed batches.

3\. For each source policy, choose Create a new policy or explicitly select Update for an existing destination policy. A same-name suggestion needs confirmation and never chooses the destination automatically. Record the intended production identity so reviewers can distinguish a replacement from an additional policy.

## How do I review production dependencies and assignments?

4\. Leave assignment promotion off for the first controlled release. New policies are then unassigned and existing assignments stay untouched. If your release needs assignments, use the documented opt-in and review the mapped groups and filters. Development group identities should never be assumed to represent the production audience.

5\. Acknowledge any secret values, which are not promoted and must be entered again in the destination. Enter a title and, if used, a ticket reference. Select Plan promotion. Planning reads both tenants and writes nothing, giving the reviewer a chance to resolve dependencies before applying.

Open the planned promotion and inspect ready and blocked results. Use Dependency mappings for tenant-specific references such as groups, filters and scope tags. Confirm each mapping and select Plan again. Do not approve a plan while the meaning of a production reference is unresolved.

## What happens when production changes after approval?

6\. Select Review against the live tenant, enter the Reviewer and Decision note, and approve the content and target state. Apply to tenant reads the destination again. A change since approval stops application and requires a fresh review. Current affected state is captured and production is backed up before writes.

Inspect each result, including failed, uncertain and not-attempted operations. Reconcile and retry checks uncertain operations against live state before another write; verified operations are not repeated. If reversal is needed, preview the rollback and review, approve and apply its new change set. Masked values that were not saved cannot be rolled back automatically.

## When should I use Sync instead?

Use Dev to Prod for a particular reviewed release with explicit choices about the production destination. Use Sync when distributing selected policies to several tenants or repeatedly updating linked target policies. The docs distinguish them directly: Sync remembers source-to-target links, while promotion copies a reviewed version once.

Try it on your tenant with one unassigned Settings Catalog policy. Record the chosen production target, keep assignment promotion off, inspect the applied result and practice rollback. Download the app and check the pricing table before expanding the exercise to a release batch.

-   [Manage changes across customer tenants](https://www.tenuvault.com/solutions/msps)
-   [Test Intune changes before production](https://www.tenuvault.com/guides/test-intune-changes-before-production)
-   [Copy policies between tenants](https://www.tenuvault.com/guides/copy-intune-policies-between-tenants)
-   [Download TenuVault](https://www.tenuvault.com/download)
-   [Compare plans and features](https://www.tenuvault.com/pricing)

## Read the technical guides

-   [Promote Intune policies to production documentation](https://docs.tenuvault.com/changes/)

Product scope reviewed 11 November 2026. Check your installed release and the current plan table before using a workflow.

## Frequently asked questions

### Q: Does promotion keep production synchronized?

A: 

No. It copies the reviewed version on demand. Use Sync for later reviewed updates to remembered target policies.

### Q: Does a matching name choose the target?

A: 

No. Confirm whether to create a new policy or update a particular existing production policy.

### Q: Can I approve before resolving blockers?

A: 

Blocking findings stop application. Resolve mappings and other findings, plan again and review the resulting live difference.

## Related guides

-   [Intune backup and baselines for MSPs](https://www.tenuvault.com/solutions/msps)
-   [Roll out Intune policies to customer tenants](https://www.tenuvault.com/guides/roll-out-intune-policies-to-customer-tenants)
-   [How to test Intune changes before production](https://www.tenuvault.com/guides/test-intune-changes-before-production)
-   [Many Intune tenants, one at a time or side by side](https://www.tenuvault.com/compare/manage-intune-tenants-one-by-one-vs-cross-tenant)

## Review your setup before the first change

Community is free for one tenant. Try Pro free by connecting a new tenant in the app, no email or card needed. Tenant access, supported restore types and scheduling requirements still apply.

[Start free trial](https://www.tenuvault.com/trial?src=cta)[Book a 30-minute demo](https://cal.com/ugur-koc/tenuvault-demo)[Permissions and data flows](https://www.tenuvault.com/trust)
