Azure Blueprints Retirement: What Replaces It?

Quick answer. As of October 2026, the step in Microsoft’s Azure Blueprints retirement that matters most to a regulated estate is the last one: on January 31, 2027 Microsoft removes all remaining blueprint locks automatically, and while the resources those blueprints deployed stay in place, Microsoft’s Azure Blueprints retirement FAQ says “any policy/permission enforcement that depended on Deny Assignments is gone,” so export every blueprint definition now and rebuild each assignment as a template spec deployed through a deployment stack with deny settings before the locks go. The earlier dates set the order of work, according to Microsoft’s Azure Blueprints retirement page: from October 31, 2026 no new blueprint assignment can be created, from December 31, 2026 existing assignments can no longer be modified, and on January 31, 2027 blueprint definitions, versions and assignments that are not exported are automatically deleted. Azure Automation State Configuration retires on September 30, 2027, according to Microsoft’s Azure Automation state configuration to machine configuration migration planning page; Azure Machine Configuration replaces it, Azure Automation exports configuration scripts only, not compiled MOF files, and hybrid servers are onboarded to Azure Arc before they leave State Configuration.

The platform team is asked for a new subscription for a regulated workload, and for years the answer has been the same: assign the blueprint. From October 31, 2026 that stops working, because Microsoft’s Azure Blueprints retirement page says no new blueprint assignment can be created from that date, and the next subscription has to come from something else. That is the visible problem. The quieter one is the question no one has asked yet: which of the controls in the organization’s control narrative rest on the blueprint’s locks, and what enforces them once Microsoft removes those locks automatically at retirement. Go wrong one way and the team waits, the locks disappear on January 31, 2027, a resource that was protected against deletion or change silently is not, and the next assessment finds a control whose documented enforcement points at a mechanism that no longer exists. Go wrong the other way and the team rushes a like-for-like rebuild, assumes deny settings behave exactly like locks, and learns about the differences after an incident rather than before. The server side has its own clock: baselines applied through Azure Automation State Configuration have to reach Azure Machine Configuration by September 30, 2027, and not everything in State Configuration can be exported. This guide takes each part in Microsoft’s own words and ends with an order of work against the dates.

The dates, and what each one takes away

A retirement remembered as one date is easy to plan badly, because Azure Blueprints loses its abilities in stages and the stage that stops new work comes months before the service ends. Microsoft’s Azure Blueprints retirement page states: “That timeline has been extended to January 31, 2027, with a phased retirement beginning July 31, 2026.”

The same Azure Blueprints retirement page gives each phase in plain dates:

• July 31, 2026, already passed: “New blueprint definitions and versions can no longer be created.”
• October 31, 2026: “Existing blueprint definitions can no longer be modified. New blueprint assignments can no longer be created.”
• December 31, 2026: “Existing blueprint assignments can no longer be modified.”
• January 31, 2027: “Blueprint definitions, versions, and assignments that aren’t exported are automatically deleted.” On the same date the blueprint locks, Do Not Delete and Read Only, stop functioning, and “Resources created through blueprints remain and aren’t deleted.”

Microsoft’s Azure Blueprints retirement FAQ adds a narrowing before the end: “Before retirement, the service phases down to read + delete only (30 days before retirement).” The retirement page’s own comparison lists Azure Blueprints as a preview service that is retiring, and both of its replacements, deployment stacks and template specs, as generally available.

The server baselines run on a separate clock. Microsoft’s Azure Automation State Configuration overview page states: “Azure Automation State Configuration will be retired on September 30, 2027, please transition to Azure Machine Configuration by that date.”

Treat October 31, 2026, the date from which Microsoft Learn says no new blueprint assignment can be created, as the day the old way of standing up a regulated subscription ends, and plan the rest of the move from there rather than from January 31, 2027.

The locks are the compliance event, not the deletion

If a control narrative says a production resource cannot be deleted or changed because a blueprint lock protects it, that sentence stops being true at retirement, whether or not anyone touches the blueprint. Microsoft’s Azure Blueprints retirement FAQ states: “At retirement, Microsoft removes all remaining Blueprint Locks (Deny Assignments) automatically.”

The same Azure Blueprints retirement FAQ is precise about what survives and what does not: “Resources previously deployed by Blueprints remain in place and inherit parent RBAC, but any policy/permission enforcement that depended on Deny Assignments is gone.”

Microsoft states the cost of waiting in the same FAQ: “Customers without a migration plan effectively lose the management and lock-enforcement layer Blueprints provided.” It also names the service it points customers to: “Deployment Stacks provide the equivalent management-plane protection, including deny settings, in a supported, forward-going service.” That is Microsoft’s description of the replacement; the section on where a deployment stack is not a blueprint lock shows where its protection works differently in detail, according to Microsoft’s own known-issues page.

For every blueprint assignment, list the controls in the control narrative that cite its locks, its policy assignments or its role assignments, and name the replacement mechanism for each one before the lock goes. Whether moving a control from one Azure mechanism to another has to be reported or re-assessed is for the organization’s assessor and authorizing official to determine, not this guide.

Find everything, then export it before it can be deleted

An inventory built from memory misses the assignment an engineer made years ago and then left behind, and on January 31, 2027 an unexported definition is deleted. Microsoft’s Azure Blueprints retirement page states: “Azure Advisor surfaces a recommendation highlighting subscriptions and management groups where Blueprints is in use.” The same page names the Azure Blueprints blade in the Azure portal as the second place to list existing definitions and assignments.

The deletion is automatic. Microsoft’s Azure Blueprints retirement page states: “Blueprint definitions, versions, and assignments that aren’t exported are automatically deleted.” Microsoft documents the export itself in Import and export blueprint definitions with PowerShell, and its Migrate Azure Blueprints to template specs page makes the export the first migration step: each blueprint definition, with its policy assignments, role assignments and ARM templates, exported to JSON.

Microsoft allows one shortcut, narrowly. Its Azure Blueprints retirement FAQ accepts a limited approach of exporting the definitions and applying standard Azure resource locks only where the tenant itself is on a near-term decommissioning timeline, and recommends Deployment Stacks for any workload that outlives the retirement.

Export every definition and every version, including ones no longer assigned, into source control now, because the evidence file may later need to show what an assignment enforced at a given time.

What replaces each part

When a team looks for one replacement for Azure Blueprints, it finds two, because Microsoft split the service’s two jobs between two features. Microsoft’s Migrate Azure Blueprints to template specs page states: “Template specs replace the artifact storage and versioning role that blueprint definitions provided.” The same page states: “Deployment stacks replace the assignment, lifecycle, and locking role that blueprint assignments provided.”

The two are meant to work together, but only one is required. Microsoft’s Azure Blueprints retirement page states: “You typically use deployment stacks and template specs together: store your template as a template spec, then deploy and govern it with a deployment stack.” The same page offers a template folder in Git as the other place to keep versioned definitions, and Microsoft’s Migrate blueprints to deployment stacks page states: “Template Specs aren’t required to use deployment stacks.” That page also states: “Blueprint artifacts are converted to ARM JSON templates or Bicep files used to define deployment stacks.”

Microsoft’s Migrate Azure Blueprints to template specs page maps each blueprint artifact to its Azure Resource Manager equivalent in the converted template:

• A policy assignment becomes Microsoft.Authorization/policyAssignments.
• A role assignment becomes Microsoft.Authorization/roleAssignments.
• An ARM template artifact becomes a module, a nested template or a linked template.
• A resource group becomes Microsoft.Resources/resourceGroups.

The locks map to deny settings on the stack, and the word Microsoft uses for the match is similar. Microsoft’s Migrate blueprints to deployment stacks page states: “Deployment stack DenySettingsMode gives you the ability to block unwanted changes via DenySettingsMode (similar to Blueprint locks).” Microsoft’s Migrate Azure Blueprints to template specs page describes the denyDelete setting as similar to the Do Not Delete lock and the denyWriteAndDelete setting as similar to the Read Only lock.

Setting a deny setting takes more than the right to deploy. Microsoft’s Migrate Azure Blueprints to template specs page lists this prerequisite: “Owner or User Access Administrator on the target scope if you need to configure deny settings.” Microsoft’s Create and deploy Azure deployment stacks in Bicep page describes a built-in role that stops short of that: “Azure Deployment Stack Contributor: Users can manage deployment stacks, but can’t create or delete deny-assignments within the deployment stacks.”

Keep each definition in version control with review, publish it as a template spec where other teams need to deploy it, and deploy it only through a stack whose deny setting was chosen deliberately for that assignment.

Where a deployment stack is not a blueprint lock

The lock that protected a resource group from deletion, or kept a policy assignment from being changed, is exactly where a like-for-like rebuild can leave a gap. Microsoft’s Known issues for deployment stacks page lists the differences that matter most for a former lock:

• Management group scope. “Deny-assignments aren’t supported at the management group scope.” Microsoft adds that they are supported in a management group stack when the deployment is pointed at the subscription scope.
• Resource group deletion. “Deleting a resource group bypasses deny-assignments.” Microsoft’s recommended guidance is to deploy to the subscription scope and include the resource group in the template, and it notes that the delete fails if a lock is active on any resource in the group.
• Moves. “Moving a managed resource removes its stack protection.” Microsoft’s interim mitigation is a read-only lock on the resource group to block move operations, removed for the duration of a stack update and reapplied afterward.
• Scale. “You can create up to 800 deployment stacks within a single scope.” The same page allows up to 2,000 deny assignments at any given scope.

Exclusions have limits of their own. Microsoft’s Create and deploy Azure deployment stacks in Bicep page states, of the principals excluded from a deny setting: “Up to five principals are permitted.” The same page allows up to 200 excluded actions, and recommends managing exclusions through group membership, so that who is excluded changes by updating the group rather than the stack. Template size has a ceiling too: Microsoft’s Azure Resource Manager template specs page states: “The size of a template spec is limited to approximately 2 MB.”

Where the management group hierarchy itself is being redesigned, that is a separate design decision from this migration.

Test each scenario a lock used to cover, deletion, change, resource group deletion and a move, against the stack in a non-production subscription, and write down every excluded principal and excluded action with its reason.

The regulated baseline can live in Azure Policy

When a blueprint carried a regulatory baseline, the policy and initiative assignments inside it are what have to be re-created in the replacement template, with their parameters and exemptions. Microsoft’s Azure Blueprints samples index no longer lists a FedRAMP, NIST SP 800-53, CMMC or DoD impact level sample, and Microsoft Learn now sends the old addresses of those samples to Azure Policy regulatory compliance pages. Azure Government editions of those initiatives are published, among them Details of the FedRAMP High (Azure Government) Regulatory Compliance built-in initiative, Details of the NIST SP 800-53 Rev. 5 (Azure Government) Regulatory Compliance built-in initiative and Details of the CMMC Level 3 (Azure Government) Regulatory Compliance built-in initiative.

That routing has a limit, and this guide keeps to it. A redirect shows where Microsoft sends an old address; it says nothing about what any retired sample contained. This guide does not treat a policy initiative as the same thing as a blueprint, and it does not map the title of Microsoft’s CMMC Level 3 initiative to the levels of the current CMMC program.

Re-create each policy and initiative assignment, with its parameters and exemptions, inside the stack template as a Microsoft.Authorization/policyAssignments resource, as Microsoft’s Migrate Azure Blueprints to template specs page maps it, and compare the Azure Policy compliance state before and after cutover.

State Configuration to Machine Configuration: the export will not carry everything

When a server’s hardening baseline lives in State Configuration only as a compiled configuration, it is a reauthoring job with a deadline, and the export is where that surfaces. Microsoft’s Azure Automation state configuration to machine configuration migration planning page states: “You can only export configuration scripts from Azure Automation.” The same page states: “It isn’t possible to export node configurations, or compiled MOF files.” And it states the consequence: “If you can’t find the original configuration, you must reauthor it.”

Microsoft sets the order of the move on the same Azure Automation state configuration to machine configuration migration planning page: “The best approach to migration is to redeploy content first, and then migrate machines.” Its expected steps are these:

• Export configurations from Azure Automation.
• Discover module requirements and load them in the environment.
• Compile configurations.
• Create and publish machine configuration packages.
• Test machine configuration packages.
• Onboard hybrid machines to Azure Arc.
• Unregister servers from Azure Automation State Configuration.
• Assign configurations to servers using machine configuration.

Other conditions on that page shape the plan. Microsoft’s Azure Automation state configuration to machine configuration migration planning page states: “Machine configuration uses DSC version 2 with PowerShell version 7.” It warns: “Some modules might have compatibility issues with machine configuration.” For servers outside Azure it states: “Before removing a machine from Azure Automation State Configuration, onboard each node as an Azure Arc-enabled server.” And it leaves room for a staged cutover: “If you decide to have machines in both services for some period of time, there are no technical barriers.”

The destination works through Azure Policy. Microsoft’s What is Azure Machine Configuration? page states: “Machine configuration uses Azure Policy to dynamically assign configurations to machines.” The same page states: “Machine Configuration currently supports the creation of up to 50 guest assignments per machine.” It offers each policy assignment one of three enforcement modes: Audit, which only reports the machine’s state; Apply and Monitor, which applies the configuration and monitors it for changes; and Apply and Autocorrect, which applies it and brings the machine back into conformance if drift occurs.

A configuration may carry a hardening baseline such as a STIG, which is the content most worth confirming before any node leaves State Configuration.

Find the source script for every compiled configuration now; any node whose baseline exists only as a compiled MOF file is a reauthoring job, and it belongs at the front of the plan, not the back.

Azure Government: what Microsoft’s pages say, and what to confirm

When an Azure Government tenant owner plans this move, the first finding is that Microsoft’s Azure Blueprints retirement page names no cloud at all, so it does not say whether Azure Government follows the same dates, and each replacement has to be confirmed in the tenant rather than assumed.

Microsoft’s Azure, Dynamics 365, Microsoft 365, and Power Platform services compliance scope page lists Azure Government services by audit scope. For the services this migration touches, the table reads:

• Azure Resource Manager and Azure Policy: FedRAMP High, DoD IL2, IL4, IL5 (the column Microsoft labels IL5WI) and IL6.
• Azure Policy’s guest configuration, the earlier name for Machine Configuration, and Azure Arc-enabled servers: FedRAMP High, DoD IL2, IL4 and IL5, but not IL6.

An audit-scope row is not a statement that a feature is available in a given region. For deployment stacks, the one Azure Government sentence on Microsoft’s Create and deploy Azure deployment stacks in Bicep page is about a permission check, not availability: “Enforcement of the RBAC permission Microsoft.Resources/deploymentStacks/manageDenySetting/action is rolling out across regions, including Government Clouds.” No Microsoft page read for this guide states that deployment stacks or template specs are generally available in Azure Government.

Machine Configuration’s Azure Machine Configuration network requirements page lists service endpoints for US Gov Arizona, US Gov Texas and US Gov Virginia, and none for the US DoD regions. The newer customizable security baselines are narrower still. Microsoft’s Security Baselines Overview page states: “All public Azure regions are supported.” It then states: “Support for Azure Government and Sovereign Clouds is not supported for Public Preview.”

If the estate is also moving from Azure commercial to Azure Government, that is its own project, covered in Azure Government Migration: What Moving from Azure Commercial Actually Takes.

Prove each replacement, a template spec, a deployment stack with deny settings, a policy assignment and a Machine Configuration assignment, in your own Azure Government subscription before the first new subscription has to be stood up without a blueprint, and file the result as evidence.

An order of work against the dates

A migration run team by team finishes when the slowest team does, and in this migration the dates do not wait. This is this guide’s recommended sequence, not Microsoft’s wording; the dates come from Microsoft’s Azure Blueprints retirement and Azure Automation State Configuration overview pages:

• Now: take the Azure Advisor recommendation and the portal blade as the inventory, export every definition and version, and find the source script for every State Configuration configuration.
• Before October 31, 2026: have the template, template spec and deployment stack path ready for any new subscription.
• Before December 31, 2026: stop changing existing blueprint assignments, and move them.
• Before January 31, 2027: cut over, then verify each protection and the Azure Policy compliance state against the control narrative.
• Before September 30, 2027: move the server baselines to Machine Configuration, content first and machines second.

Sequence the work by date, not by team, and give each date an owner.

When this guide is the wrong starting point

Not every Blueprints estate needs a control-evidence project, and treating a small one as if it did spends the months before the dates on the wrong work. Test the situation against Microsoft’s Azure Blueprints retirement FAQ and Azure Automation State Configuration overview pages:

• The subscription or tenant is being decommissioned before the retirement: Microsoft’s FAQ accepts export plus standard Azure resource locks for a tenant on a near-term decommissioning timeline.
• The assignments carry no locks and the policy assignments were made directly in Azure Policy: the work is export and template housekeeping, not a control-evidence project.
• The estate is standardizing on a non-Microsoft infrastructure-as-code tool: that is a platform choice this guide does not make.
• The question is whether the change has to be reported to an authorizing official or re-assessed: that is the assessor’s and the authorizing official’s determination.
• Linux configurations are still on State Configuration: Microsoft’s overview states: “Azure Automation DSC for Linux has retired on 30 September 2023.” That makes them a separate, overdue problem.

What to ask of whoever moves it, and how i3solutions answers

A migration that cannot be shown control by control is one the next assessment will question, so hold whoever does the work to criteria drawn from Microsoft’s Azure Blueprints retirement FAQ and Known issues for deployment stacks pages:

• Show every blueprint assignment and State Configuration node, with what each one enforces.
• Show the export in your own source control before anything changes.
• Show, for each control, which mechanism enforced it before and which enforces it after.
• Show each deny setting, and every excluded principal and excluded action with its reason.
• Show the tests of resource group deletion and of moves.
• Show every DSC configuration with its source script, or a plan to reauthor it.
• Show the Azure Government proofs from your own tenant, where the estate runs there.
• Hand the templates, stacks and Machine Configuration packages to your own team to run.

i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and evidences it continuously rather than reconstructing it at audit. The work in this guide is delivered as a project, with specialists embedded in your team where it needs them: inventorying and exporting the blueprint assignments and State Configuration configurations, rebuilding them as templates, template specs, deployment stacks, Azure Policy assignments and Machine Configuration packages, onboarding hybrid servers to Azure Arc, and evidencing each control against the organization’s control families for its own team to run. i3solutions plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based engineers. i3solutions is an SBA certified small business providing technical and professional services to US Federal Agencies, the DoD and the private sector. i3solutions installs and helps configure applications inside IL4 and IL6 government cloud environments and other government networks. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences. An i3solutions project engagement does not by itself include ongoing support of what it delivers, which i3solutions scopes separately as Application Managed Services, and it is not a replacement for the internal team, open-ended scope expansion, or vendor lock-in. For the wider Azure practice, see Azure Development Services for Regulated Enterprise Workloads.

Key Takeaways

• At retirement Microsoft removes the remaining blueprint locks automatically; the resources stay, and the enforcement that depended on the locks’ deny assignments ends.
• New blueprint assignments stop on October 31, 2026, existing assignments freeze on December 31, 2026, and unexported definitions, versions and assignments are deleted on January 31, 2027.
• Template specs take over the definitions’ storage and versioning, and deployment stacks take over the assignments, their lifecycle and their locking.
• Deny settings are similar to blueprint locks, not identical: management group scope, resource group deletion, moves and the five-principal exclusion limit all differ.
• Azure Automation State Configuration retires on September 30, 2027, and its export carries configuration scripts only, not compiled MOF files.
• In Azure Government, confirm each replacement in the tenant; Microsoft’s audit-scope table is not a statement of feature availability.

Frequently Asked Questions

When does Azure Blueprints stop working?

According to Microsoft Learn, Azure Blueprints retires on January 31, 2027, in stages that began on July 31, 2026. According to Microsoft Learn, new blueprint assignments can no longer be created from October 31, 2026, existing assignments can no longer be modified from December 31, 2026, and on January 31, 2027 unexported definitions, versions and assignments are deleted and the blueprint locks stop functioning.

What happens to resources deployed by Azure Blueprints after January 31, 2027?

According to Microsoft Learn, the resources remain in place and are not deleted, and they inherit parent RBAC. According to Microsoft Learn, Microsoft removes all remaining blueprint locks automatically at retirement, and any policy or permission enforcement that depended on their deny assignments is gone.

What replaces Azure Blueprints?

According to Microsoft Learn, template specs replace the storage and versioning role of blueprint definitions, and deployment stacks replace the assignment, lifecycle and locking role of blueprint assignments. According to Microsoft Learn, the two can be used together, with the template stored as a template spec and deployed and governed through a deployment stack.

Do deployment stack deny settings work exactly like blueprint locks?

No. According to Microsoft Learn, deny settings are similar to blueprint locks, but deny assignments are not supported at the management group scope, deleting a resource group bypasses them, and moving a managed resource removes its stack protection. According to Microsoft Learn, up to five principals can be excluded from a deny setting.

Can I export compiled MOF files from Azure Automation State Configuration?

No. According to Microsoft Learn, only configuration scripts can be exported from Azure Automation, not node configurations or compiled MOF files, and a configuration whose original cannot be found must be reauthored.

When does Azure Automation State Configuration retire?

According to Microsoft Learn, Azure Automation State Configuration will be retired on September 30, 2027, and Microsoft asks customers to transition to Azure Machine Configuration by that date.