Azure Blueprints Ends 31 January 2027: A Migration Plan to Deployment Stacks and Template Specs

The Blueprints retirement moved from July 2026 to 31 January 2027, which sounds like a reprieve. It is not. It is a phased lockdown that is already running — and some of the doors have been shut since July.

This article is not news, it is a migration plan: what exactly stops working and when, how to map each artifact type, and how to get your data out before Microsoft deletes it.

The timeline that is already running

Two items deserve highlighting.

Unexported data will be permanently deleted. Not archived, not made read-only. If your blueprints contain definitions that exist nowhere else — and in many organisations blueprints are the only place that governance logic lives — after 31 January 2027 you do not have them.

Blueprint locks stop working. Operationally this is the sharpest item of the whole wind-down. If you applied Do Not Delete or Read Only to production resources through a blueprint, those locks simply cease to apply. The resources are not deleted, but they stop being protected — and nobody sends you a notice about it.

The resources themselves survive the migration. Nothing is deleted and nothing is redeployed.

The replacement is a pair, not one service

A blueprint did two jobs at once, which is why two tools replace it:

Azure Blueprint
   │
   ├─→ Template spec (or Git)   ← storing and versioning the template
   │                               "what gets deployed"
   │
   └─→ Deployment Stack         ← assignment, lifecycle, denySettings
                                   "where, with which parameters, and what is forbidden"

At first glance that looks like added complexity. In practice it is a simplification, because you stop operating a separate governance technology and use the same tool as the rest of your infrastructure. I covered Deployment Stacks on their own in the Deployment Stacks article — this piece is just the mapping.

Artifact mapping

This is the bulk of the work. Go through each blueprint artifact by artifact:

Do not leave those last two rows until the end. Migrate the locks first, because they are the only item where delay has a real security consequence.

The resulting stack looks like this:

targetScope = 'managementGroup'
 
// What a blueprint called "artifacts" is simply a handful of
// modules here. Bicep works out ordering from the references.
module policies 'modules/policy-assignments.bicep' = {
  name: 'lz-policies'
  params: { mgScope: managementGroupId }
}
 
module rbac 'modules/role-assignments.bicep' = {
  name: 'lz-rbac'
  params: { platformTeamObjectId: platformTeamObjectId }
}
 
param managementGroupId string
param platformTeamObjectId string

And deploying it as a stack, including the replacement for the blueprint lock:

az stack mg create \
  --name 'lz-governance-baseline' \
  --management-group-id 'mg-platform' \
  --location westeurope \
  --template-file main.bicep \
  --parameters main.bicepparam \
  --deny-settings-mode denyDelete \
  --deny-settings-excluded-principals "$BREAKGLASS_OBJECT_ID" \
  --action-on-unmanage detachAll

Two options in that command deserve a comment:

• --deny-settings-excluded-principals — always exclude your break-glass identity. Blueprint locks could be worked around through the Owner role; denySettings is stricter, and without an exclusion you can lock yourself out.
• --action-on-unmanage detachAll on the first deployment. Once you have verified the stack manages exactly what it should, you can move to deleteResources. Do not do it the other way round — deleteResources on a wrongly scoped stack is irreversible.

Export: do it now, not in January

Unexported data gets deleted. The az blueprint extension is not installed everywhere, so the most reliable route is REST — it works from any environment with az:

MG='mg-platform'
API='2018-11-01-preview'
BASE="https://management.azure.com/providers/Microsoft.Management/managementGroups/$MG/providers/Microsoft.Blueprint"
 
mkdir -p blueprint-export
 
# 1. List the definitions
az rest --method get --url "$BASE/blueprints?api-version=$API" \
  > blueprint-export/_definitions.json
 
# 2. For each definition, its artifacts and versions
for BP in $(jq -r '.value[].name' blueprint-export/_definitions.json); do
  az rest --method get --url "$BASE/blueprints/$BP?api-version=$API" \
    > "blueprint-export/${BP}.json"
  az rest --method get --url "$BASE/blueprints/$BP/artifacts?api-version=$API" \
    > "blueprint-export/${BP}.artifacts.json"
  az rest --method get --url "$BASE/blueprints/$BP/versions?api-version=$API" \
    > "blueprint-export/${BP}.versions.json"
done

Assignments live on subscriptions, not on the management group, so list those separately:

for SUB in $(az account list --query "[?state=='Enabled'].id" -o tsv); do
  az rest --method get \
    --url "https://management.azure.com/subscriptions/$SUB/providers/Microsoft.Blueprint/blueprintAssignments?api-version=$API" \
    > "blueprint-export/assignments-${SUB}.json"
done

Commit that directory to Git. Even if you never replay a single line of it, it is the only record of what your governance looked like — and after January 2027 it will not exist anywhere else.

What you lose and what you gain

Plainly, because a migration that promises only upside is usually hiding something.

You lose:

• Artifact bundling into one published, versioned object. This was the main reason people used Blueprints, and there is no direct equivalent — a template spec holds the template, a stack holds the assignment, but the "box" around them is gone.
• The portal UX. A blueprint could be clicked together. A deployment stack is a tool for people who write IaC.

You gain:

• Real lifecycle. The stack knows what it manages. Remove a resource from the template and the stack can remove it — a blueprint never could, and left orphans behind.
• More granular locking. denySettings can exclude specific principals and specific actions, which a blueprint lock could not.
• One tool instead of two. Your landing zone almost certainly already uses Bicep. Governance stops being the exception with its own deployment model.

A plan for the rest of the year

You have a little over two months until 31 October, when new assignments stop being possible. That is the real deadline, not January.

1. This week: export. The script above, output into Git. The cheapest step with the highest cost of delay.
2. By end of September: lock inventory. List every resource protected by a blueprint lock. That is the list that must be covered by denySettings before the API disappears.
3. October: pilot. One blueprint rewritten in Bicep and deployed as a stack, in a non-production environment. Verify denySettings and the break-glass exclusion above all.
4. November–December: the rest. Blueprint by blueprint, production last.
5. January 2027: verify that no assignments remain, and remove the old definitions.

The worst option is waiting until January. At that point new assignments are no longer possible, so you have no way to run the replacement in parallel and confirm it does the same thing.

If you are building or reviewing a landing zone and this migration falls inside it, I laid out the structure in the Azure Landing Zone in Bicep article. Happy to help with a specific environment — see cloud architecture services.

Sources

• Azure update 564806 — announcement, 25 June 2026
• Blueprint retirement — docs, ms.date 26 June 2026