Azure Blueprints : migrer vers Deployment Stacks avant le blocage du 31 octobre 2026

Azure Blueprints est entré dans sa phase de retrait. Pour une équipe qui utilise encore des Blueprint definitions ou assignments, la question n’est plus de savoir s’il faut migrer, mais comment le faire sans perdre le versioning, les Policy et RBAC assignments ou les protections apportées par les Blueprint locks.

Depuis le 31 juillet 2026, Microsoft empêche déjà la création de nouvelles Blueprint definitions et versions. Le 31 octobre 2026 constitue la prochaine échéance importante : les definitions existantes ne pourront plus être modifiées et aucune nouvelle Blueprint assignment ne pourra être créée. Le retrait complet est prévu le 31 janvier 2027.

L’objectif de cet article est de construire une migration contrôlée vers Bicep ou ARM templates, Template Specs ou Git, puis Azure Deployment Stacks, sans retirer l’ancien mécanisme avant d’avoir validé son remplacement.

Contexte et problème

Azure Blueprints regroupe historiquement plusieurs fonctions : définition d’un ensemble d’éléments de gouvernance, versioning, assignment sur un scope Azure et protection de ressources avec des deny assignments.

Le retrait est progressif :

Date	Changement
31 juillet 2026	création de nouvelles Blueprint definitions et versions bloquée
31 octobre 2026	modification des definitions et création de nouvelles assignments bloquées
31 décembre 2026	modification des assignments existantes bloquée
31 janvier 2027	retrait d’Azure Blueprints et suppression des definitions, versions et assignments non exportées

Les ressources Azure créées par Blueprints ne sont pas supprimées lors du retrait. En revanche, Microsoft indique que les objets Blueprints non exportés sont perdus et que les Blueprint locks cessent de fonctionner.

Cela crée deux risques distincts.

Le premier est un risque de récupération : attendre trop longtemps peut empêcher de modifier puis de récupérer correctement une définition historique.

Le second est un risque de gouvernance : retirer un Blueprint ou attendre la disparition de ses locks sans avoir établi les deny settings équivalents peut créer une période pendant laquelle des ressources auparavant protégées peuvent être modifiées ou supprimées.

Concept ou architecture

La migration n’impose pas de remplacer Blueprints par un produit unique.

Microsoft répartit ses fonctions entre plusieurs composants :

Fonction Azure Blueprints	Cible
définition de l’infrastructure	ARM template ou Bicep
stockage/versioning dans Azure	Template Specs
source control et Pull Requests	Git
assignment et lifecycle des ressources	Azure Deployment Stacks
`Do Not Delete`	`denyDelete`
`Read Only`	`denyWriteAndDelete`

Microsoft recommande Azure Deployment Stacks pour le grouping, le lifecycle management et l’application de deny assignments. Les definitions peuvent être publiées comme Template Specs ou conservées dans Git.

Une Deployment Stack est une ressource Microsoft.Resources/deploymentStacks. Elle permet de gérer comme un ensemble les ressources décrites par un template Bicep, ARM ou un Template Spec. Les stacks peuvent être créées aux scopes resource group, subscription et management group.

Pour une organisation utilisant déjà Git comme source de vérité, stocker les fichiers Bicep dans le repository permet de conserver les revues de code et Pull Requests. Template Specs reste pertinent lorsqu’on souhaite publier et partager des versions de templates directement dans Azure. Microsoft documente explicitement les deux approches.

Prérequis

Avant toute migration, prévoyez :

un inventaire des subscriptions et management groups utilisant Blueprints ;
un export des definitions, versions et assignments à conserver ;
une subscription de laboratoire ou un scope non critique ;
Azure CLI 2.61.0 ou ultérieur si vous utilisez les commandes Deployment Stacks présentées ici ;
des permissions suffisantes sur le scope cible ;
des permissions supplémentaires si des deny settings doivent être créés.

Microsoft fournit deux rôles intégrés spécifiques :

Azure Deployment Stack Contributor, qui permet de gérer les stacks sans créer ou supprimer leurs deny assignments ;
Azure Deployment Stack Owner, qui permet également leur gestion avec deny assignments.

La documentation Microsoft signale toutefois que l’enforcement de la permission Microsoft.Resources/deploymentStacks/manageDenySetting/action continue d’être déployé selon les régions. Les permissions doivent donc être contrôlées dans l’environnement cible plutôt que supposées.

Mise en pratique

1. Inventorier avant de convertir

Commencez par identifier où Blueprints est réellement utilisé.

Microsoft propose notamment :

les recommandations Azure Advisor, qui peuvent signaler les subscriptions et management groups utilisant Blueprints ;
le blade Azure Blueprints du portail, qui liste les definitions et assignments existantes.

L’objectif est d’obtenir, pour chaque Blueprint :

son scope ;
ses versions ;
ses assignments ;
ses Policy assignments ;
ses role assignments ;
ses ARM template artifacts ;
ses resource group artifacts ;
ses éventuels locks.

N’effectuez pas encore de suppression.

2. Exporter les Blueprints existants

Microsoft demande d’exporter avant le 31 janvier 2027 tout ce qui doit être conservé.

L’export doit inclure les definitions et leurs artifacts. Ces données servent ensuite de base à la conversion vers un template ARM ou Bicep.

Conservez également une copie de l’export hors du processus de transformation. Elle constitue votre référence lors des contrôles de migration.

3. Convertir les artifacts

Microsoft fournit les correspondances principales :

Blueprint Policy assignment
    → Microsoft.Authorization/policyAssignments

Blueprint Role assignment
    → Microsoft.Authorization/roleAssignments

Blueprint ARM template artifact
    → module, nested template ou linked template

Blueprint Resource group artifact
    → Microsoft.Resources/resourceGroups

Le targetScope Bicep doit correspondre au scope auquel le Blueprint était assigné. Pour un Blueprint appliqué au niveau subscription :

targetScope = 'subscription'

param location string = 'francecentral'
param resourceGroupName string = 'rg-blueprint-migration-lab'

resource labResourceGroup 'Microsoft.Resources/resourceGroups@2024-03-01' = {
  name: resourceGroupName
  location: location
}

Cet exemple reste volontairement minimal : il permet de valider le fonctionnement de la stack sans déployer de VM, database ou autre service payant.

Un Blueprint réel comportant des Policy ou RBAC assignments demandera de traduire également ces artifacts dans le template. Microsoft documente cette conversion comme une étape explicite de la migration.

4. Choisir entre Template Specs et Git

Deux modèles sont possibles.

Template Specs convient lorsque vous souhaitez stocker dans Azure une version identifiable et partageable du template.

Git est généralement plus naturel lorsque les templates sont déjà gérés comme du code avec branches, revue et Pull Requests.

Il n’est pas nécessaire d’utiliser les deux pour résoudre le même problème. Le choix dépend principalement de votre méthode de gestion des sources et de distribution des templates.

5. Créer une Deployment Stack sans suppression automatique

Pour un premier lab, nous privilégions detachAll.

Cette valeur indique qu’une ressource qui sort du périmètre géré doit être détachée plutôt que supprimée. À l’inverse, deleteResources et deleteAll peuvent entraîner des suppressions. Microsoft avertit notamment que deleteAll peut supprimer les resource groups gérés et leur contenu.

Après authentification Azure CLI et sélection explicite de la subscription de laboratoire :

az account set --subscription "<SUBSCRIPTION_ID>"

az stack sub create \
  --name "blueprint-migration-lab" \
  --location "francecentral" \
  --template-file "./main.bicep" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none"

Ce premier passage vérifie uniquement que le template est correctement pris en charge par une Deployment Stack.

Il ne reproduit pas encore un Blueprint lock.

Résultat attendu

La subscription doit contenir :

une Deployment Stack nommée blueprint-migration-lab ;
le resource group rg-blueprint-migration-lab ;
une relation de gestion entre la stack et la ressource créée par son template.

La présence du resource group seule n’est donc pas suffisante : la stack doit elle-même être visible et son état de déploiement doit être contrôlé.

Vérification

Une première vérification CLI peut être réalisée avec :

az stack sub show \
  --name "blueprint-migration-lab"

Vérifiez également dans le portail Azure, au niveau de la subscription, la section Deployment stacks et la liste des managed resources associées à la stack.

Pour une migration réelle comportant Policy et RBAC assignments, vérifiez séparément leur présence au scope prévu avant de toucher au Blueprint historique.

6. Ajouter la protection après validation fonctionnelle

Une fois le fonctionnement de la stack confirmé dans un environnement non critique, le comportement Do Not Delete d’un Blueprint peut être rapproché de :

--deny-settings-mode "denyDelete"

Microsoft associe denyDelete à une protection similaire à Do Not Delete, et denyWriteAndDelete à une protection similaire à Read Only.

Une stack de démonstration peut par exemple être recréée ou mise à jour avec :

az stack sub create \
  --name "blueprint-migration-lab" \
  --location "francecentral" \
  --template-file "./main.bicep" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "denyDelete"

Ne généralisez pas cette configuration directement sur un environnement de production. Un deny assignment est justement conçu pour empêcher certaines opérations et peut donc également bloquer des actions d’administration attendues.

Bonnes pratiques

Traitez la migration comme un changement de gouvernance plutôt que comme une simple conversion de fichier.

Conservez l’export original. Il doit rester disponible même après création du Bicep.

Migrez par scope. Une subscription pilote est plus simple à valider qu’une migration simultanée de l’ensemble d’un tenant.

Séparez conversion et protection. Vérifiez d’abord que les ressources, Policy et RBAC assignments sont corrects ; ajoutez ensuite les deny settings.

Utilisez detachAll pendant les premiers essais. C’est ici une recommandation de prudence : elle réduit le risque qu’une erreur de template se transforme en suppression de ressources.

Ne retirez pas le Blueprint trop tôt. Le décommissionnement ne doit intervenir qu’après validation du remplacement.

Sécurité

Les deny settings constituent le principal point de vigilance.

Une migration réussie doit éviter deux situations :

perdre involontairement une protection existante ;
créer une nouvelle protection tellement large qu’elle empêche les opérations d’administration nécessaires.

Appliquez le principe du moindre privilège aux comptes humains et aux pipelines utilisés pour gérer les stacks.

Si des exclusions de principals ou d’actions sont nécessaires dans les deny settings, documentez leur justification et limitez-les au strict besoin.

Enfin, vérifiez explicitement les Azure Policy et Azure RBAC assignments après conversion. Une ressource effectivement créée n’est pas une preuve que toute la gouvernance du Blueprint original a été reproduite.

Coûts

Azure Deployment Stacks, Bicep et les artifacts de gouvernance ne nécessitent pas, pour ce laboratoire minimal, de déployer une charge de travail coûteuse.

Les ressources décrites dans une stack restent toutefois des ressources Azure normales : une VM, un storage account ou une database ajoutée au template peut générer sa facturation habituelle.

Le lab proposé se limite donc à un resource group afin d’éviter un coût applicatif inutile.

Aucun prix précis n’est nécessaire pour réaliser cette migration.

Limites et points de vigilance

Une conversion Blueprint vers Bicep n’est pas à traiter comme une traduction automatique universelle.

Les Blueprints complexes peuvent comporter :

plusieurs scopes ;
des dependencies entre artifacts ;
des paramètres ;
des Policy definitions ou assignments ;
des RBAC assignments ;
plusieurs ARM template artifacts ;
des locks.

La conversion doit être vérifiée artifact par artifact.

La timeline Microsoft doit également être contrôlée à nouveau juste avant une migration planifiée, car le calendrier de retrait Azure Blueprints a déjà évolué. Au 26 août 2026, la prochaine échéance structurante reste le 31 octobre 2026.

Enfin, aucun des exemples de cet article n’est présenté comme ayant été exécuté dans un environnement de production.

Rollback ou nettoyage

Tant que l’ancien Blueprint reste en place, le rollback d’un premier test est relativement simple : supprimer la stack en demandant de détacher ses ressources plutôt que de les supprimer.

Avant une commande de suppression, contrôlez impérativement le nom de la stack et la subscription active :

az account show

Puis, uniquement dans le laboratoire :

az stack sub delete \
  --name "blueprint-migration-lab" \
  --action-on-unmanage "detachAll"

detachAll supprime la relation de gestion par la stack mais conserve les ressources concernées. Les modes de suppression doivent être utilisés uniquement après analyse de leur portée.

Après le 31 janvier 2027, ce mécanisme ne permettra évidemment pas de recréer le service Azure Blueprints lui-même. L’export doit donc être considéré comme une mesure de préservation, et non comme la garantie d’un rollback indéfini.

Références officielles

Azure Blueprints retirement — Microsoft Learn
Migrate Azure Blueprints to template specs — Microsoft Learn
Migrate blueprints to deployment stacks — Microsoft Learn
Create and deploy Azure deployment stacks in Bicep — Microsoft Learn
Azure Blueprints retirement FAQ — Microsoft Learn

Conclusion

Azure Blueprints n’est plus un composant à intégrer dans de nouvelles architectures : son retrait est déjà engagé.

La priorité est maintenant d’inventorier, exporter, convertir et valider. Bicep ou ARM reprend la définition des ressources, Template Specs ou Git assure le versioning, et Azure Deployment Stacks reprend le lifecycle management et les protections nécessaires.

Le point critique est de ne supprimer l’ancien mécanisme qu’après avoir démontré que le nouveau reproduit réellement les ressources et les contrôles de gouvernance attendus.