Copy Intune policies between tenants

Choose copying or promotion deliberately

Cross-tenant restore starts from a saved backup and creates separate copies in the target tenants. It fits the task of distributing selected configuration while leaving the source unchanged. Connect the participating tenants, keep their licenses active and check that your account can create the selected types in each destination.

Dev to Prod reads a connected source tenant and the selected production tenant. It plans either new policies or explicit updates to existing ones, then uses a reviewed change set. Choose it when a tested change needs deliberate promotion into production, rather than sending another independent copy.

• Plan a one-time Intune tenant migration

Prepare a repeatable source set

Keep a named list of the policies you intend to reuse and record the backup that contains the approved version. Confirm that each destination needs those settings; a standard set is still a change to the destination environment. Run a destination backup before starting work and keep target-specific exceptions with the change record.

Include dependencies that can be copied in the same restore, such as app categories, reusable settings or assignment filters. Group identities belong to the destination and should not be assumed portable. A policy name shared between tenants is a useful search aid, not proof that two objects have the same purpose.

Copy from a backup with MSP

In Backup & Restore, select the source tenant and open Restore. Choose the backup, then the items. On How to restore, select the target tenants under Copy to other tenants instead. Read Review: each selected item says it will be copied or explains why it cannot be restored.

Copies keep their original names, receive the Default scope tag and remain unassigned. Replace in place and Restore assignments are unavailable for cross-tenant copies. Tenant-wide compliance policy settings cannot be copied; set the required values in the target through its own Intune configuration.

After confirming, read the result for every target. Retry failed items retries the failed item only in the tenant where it failed. If you repeat the workflow later, review the destination first: creating another copy is not an update of the previous copy and does not establish ongoing synchronization.

Resolve dependencies before writing

TenuVault restores selected dependencies before the objects that reference them and rewrites references to the newly created IDs. An item whose remaining target dependencies cannot be resolved is not created. Resolve the reported paths rather than repeatedly trying the same unresolved selection.

For exactly one target tenant, Reviewed target dependencies accepts mappings for Apps and AppCategories. Enter the source and target IDs only after checking the actual destination objects. The wizard requires confirmation, and it reads mapped targets before any restore write. A missing or unreadable mapped object stops the operation.

These mappings do not upload installers or rewrite arbitrary configuration text. Other dependency types cannot be mapped through that field. Reconcile them through the supported copy or manual target workflow, then review the plan again instead of copying source IDs into destination references.

Promote a tested policy into production

Select the destination tenant, open Changes and choose Dev to Prod. Pick Source (development) tenant and the policy type, then select Promote on each source policy. Choose Create a new policy or an explicit existing destination policy to update. A matching name never selects the update target for you.

Supported types are Settings Catalog, compliance, endpoint security and device configuration policies, with at most 25 policies per promotion. Assignments stay out by default: new policies are unassigned and existing assignments stay untouched. Include assignments only after reviewing mapped groups and filters; secret values must be set again in the destination.

Choose Plan promotion, resolve blocking dependency findings and plan again as needed. Review against the live tenant, enter the reviewer and decision note, then approve and apply. Apply reads the destination again and stops if it changed after approval. The workflow captures the affected state and runs its pre-change backup before writes; rollback is another reviewed change set.

• Test Intune changes before production

Check each destination before assignment

Inspect the actual result in the target tenant and keep its object identities with the source version. Check settings and target-specific references before a pilot. The repeated-copy record should tell the next admin which version each tenant received and which local exceptions were intentional.

• Confirm source and target licenses and permissions before planning.
• Review dependencies, secrets, scope tags and the intended update or copy behavior.
• Pilot assignment separately from copying configuration.
• Treat later source edits as a new reviewed change, not an automatic update.