Export Tenant Config Before You Change It
How to capture a Microsoft 365 tenant’s configuration baseline before you make a change — what to export, where to store it, and how to diff what moved.
How do I capture a Microsoft 365 tenant’s configuration before making changes?
Capturing a Microsoft 365 tenant’s configuration baseline means exporting Conditional Access, Intune, Entra ID and SharePoint settings before a change ships, then diffing a second export against it afterward. Blueprint produces this snapshot as deterministic JSON through a UI, with no PowerShell scripting required. Restoring a prior state stays a manual step performed through PowerShell or Microsoft365DSC.
A Conditional Access policy gets tightened on a Friday afternoon, a retention label gets reassigned during a SharePoint cleanup, an Intune profile gets pushed to a pilot group — and by Monday nobody can say with certainty what the tenant looked like the week before. The change itself is rarely the problem. The problem is that nobody captured a baseline first, so there is nothing to compare against when a user reports broken access, or when the change needs to be explained six months later during an audit. What breaks when you change a tenant with no baseline Part of the reason this keeps happening is structural: Microsoft documents directly that Microsoft 365 has no built-in export of tenant configuration, so unless a team deliberately adds a step to capture one, no baseline exists by default. Most tenant-configuration incidents are not caused by the change being wrong — they are caused by nobody being able to say what changed, when, or from what starting point. The failure modes below account for most of the support tickets that follow an unrecorded configuration change. No way to prove what a Conditional Access policy, Intune profile, or Entra role assignment looked like before a change, so a rollback becomes a guess rather than a reversal A retention label gets reassigned and nobody notices until a legal hold or eDiscovery request needs data the new label no longer covers A SharePoint permissions change ships alongside a dozen unrelated tweaks, and isolating which one caused a reported access problem takes hours of manual checking An auditor asks what the tenant’s Conditional Access posture looked like on a specific date, and the honest answer is “we don’t know” Step 1 — Decide which workloads the change actually touches Start narrower than “export everything.” A Conditional Access change touches Conditional Access policies; an Intune profile push touches Intune device configurations; a role reassignment touches Entra ID role assignments. Naming the workloads up front keeps the baseline export focused on what the change can actually affect, rather than a generic full-tenant dump nobody reads before the change ships. Step 2 — Capture a baseline export before you touch anything Run the export before the change window opens, not after. The alternative many teams reach for is Microsoft365DSC — a free, open-source Infrastructure-as-Code tool, but one that requires PowerShell scripting, an Azure DevOps or GitHub Actions pipeline, and typically weeks of initial setup before it produces a usable baseline. Blueprint’s snapshot covers the same nine workloads Microsoft Graph exposes — Conditional Access, Intune (26 categories), the M365DSC bridge, SharePoint permissions, Power Platform, Entra ID, Exchange, Teams Voice, and Security & Compliance — as deterministic JSON and PowerShell artifacts, captured through a UI rather than a pipeline, so a baseline exists before the change window opens rather than after weeks of tooling setup. The Graph API output is encrypted client-side before it leaves the machine running the export; the server stores ciphertext only, and on Desktop the snapshot never touches a third-party server at all. Step 3 — Store the export somewhere the change plan can reference The export only helps if the person making the change — or the person reviewing it — can find it. Deterministic JSON output drops straight into a Git repository, so the baseline sits next to the change ticket or the pull request describing what is about to happen, rather than in a folder nobody checks until something breaks. Step 4 — Make the change, then diff the export against the baseline After the change ships, run the export again and compare it against the baseline from Step 2. Per-export history and delta reports surface exactly what moved between the two snapshots, so confirming a Conditional Access change did what it was supposed to — and nothing else — is a diff, not a manual re-check of every policy. Confirm the workload you intended to change actually changed Confirm every other workload in the snapshot did not Keep the delta report as the record that answers “what changed and when” the next time someone asks Step 5 — Know what a restore actually requires If the change needs to be reversed, the export is the reference an administrator works from — not a rollback button. Applying a prior state back to the tenant is a manual operation, done through PowerShell, the Microsoft Graph SDK, or Microsoft365DSC, with the export as the source of truth for what the earlier state was. Planning the restore path before you need it, while the change is still fresh, is faster than reconstructing it under pressure. What a configuration export does not do A configuration export is a documentation and version-control tool, not a drift-detection-and-remediation engine — it will not detect or reverse a change on its own. Applying an exported state back to the tenant is always a manual step; the tool never writes back to the tenant automatically. Coverage is limited to what Microsoft Graph exposes — Conditional Access policies, Intune device configurations, Entra ID role assignments, retention labels, and SharePoint site templates; settings that live outside Graph, such as legacy Exchange admin center policies or classic SharePoint farm settings, fall outside the export envelope. For MSPs, each client tenant is its own session, vault, OAuth consent, and export envelope — there is no multi-tenant dashboard aggregating configuration changes across customer tenants, and the toolkit runs alongside your RMM and PSA rather than replacing them.
Frequently asked questions
Does a configuration export let me restore or apply changes back to the tenant automatically?
No. A configuration export is a documentation and version-control tool, not a drift-detection-and-remediation engine. Blueprint never writes back to the tenant — applying an exported state is always a manual step an administrator performs through PowerShell, the Microsoft Graph SDK, or Microsoft365DSC, using the export as the reference for what the earlier state was.
Do I need to already run Microsoft365DSC to get a usable baseline?
No. Microsoft365DSC is free but requires PowerShell scripting and an Azure DevOps or GitHub Actions pipeline, with setup typically measured in weeks. Blueprint captures the same nine Graph-exposed workloads — Conditional Access, Intune, Entra ID, SharePoint, Exchange, Teams Voice, Power Platform, Security & Compliance, and the M365DSC bridge — through a UI, with no PowerShell scripting required to produce the first snapshot.
How do I know exactly what changed after I made a tenant-configuration edit?
Run the export again after the change and compare it against the baseline captured beforehand. Every export is timestamped, and per-export delta reports surface exactly what changed between any two snapshots, so confirming a change did what it was supposed to — and nothing else — is a diff rather than a manual policy-by-policy re-check.
Related topics
- microsoft 365 configuration export
- tenant configuration baseline
- conditional access backup
- microsoft365dsc alternative
- blueprint config export