Power BI Premium P1 à P5 : migrer vers Microsoft Fabric avant la fin de votre contrat
Microsoft retire les SKU Power BI Premium par capacité, P1 à P5 : chaque abonnement prend fin au terme de son contrat. Suivent 30 jours de grâce, un accès ralenti du jour 31 au jour 90, puis le rejet de toutes les opérations. La migration vers une capacité Fabric se fait à la main, par espace de travail.
Microsoft retire les SKU Power BI Premium par capacité, de P1 à P5, au profit des capacités Microsoft Fabric, appelées SKU F. Un SKU est la référence commerciale d’une offre : ici, la taille de la capacité achetée. Il n’y a pas de date de retrait commune à tous les clients. Chaque abonnement P prend fin au terme du contrat qui le porte, et la date qui compte pour votre organisation est donc écrite dans votre contrat, pas dans une annonce de Microsoft.
La migration de Power BI Premium vers Fabric n’est pas automatique au renouvellement. Il faut acheter une capacité F dans Azure, puis y réaffecter chaque espace de travail (workspace) un par un ou par lots. Microsoft ne résilie pas non plus l’abonnement P quand la capacité F est créée : la résiliation se fait à la main, une fois la migration validée.
| Phase | Moment | Ce qui se passe |
|---|---|---|
| Retrait | Fin du contrat en cours | L’abonnement P prend fin et ne se renouvelle pas |
| Période de grâce | Jours 1 à 30 après la fin | La capacité continue de tourner à sa taille, sans frais ; la réaffectation vers une capacité F reste possible |
| Accès ralenti | Jours 31 à 90 | Les opérations interactives sont retardées ; l’export et la récupération des données restent possibles |
| Blocage | À partir du jour 91 | Toutes les opérations sont rejetées ; les données sont conservées mais inaccessibles |
Relevé le 29 septembre 2026 sur la documentation Microsoft.
Qui est concerné par le retrait des SKU P1 à P5
Le retrait vise les seuls abonnements Power BI Premium par capacité, de P1 à P5. Les licences par utilisateur ne sont pas touchées : Power BI Pro et Power BI Premium Per User (PPU) continuent telles quelles, et vos utilisateurs n’ont pas à changer de licence dans le cadre de cette migration. Microsoft précise que, lorsqu’un article ancien parle de « Power BI Premium » sans dire s’il s’agit de la capacité ou de l’utilisateur, le retrait ne vaut que pour la capacité.
Les licences Embedded EM et A ne font pas partie du retrait. Les environnements souverains de Microsoft, où Fabric n’est pas encore disponible, en sont également exclus pour l’instant ; Microsoft annonce des consignes séparées pour eux.
Côté achat, Microsoft ne vend plus de nouveaux SKU P. Un client dont l’Enterprise Agreement est encore actif peut continuer à exploiter sa capacité P existante et la renouveler chaque année par ce contrat, jusqu’au terme de l’Enterprise Agreement. Un client dont l’Enterprise Agreement ou le Microsoft Cloud Agreement expire ne peut plus ajouter ni renouveler de capacité P par ce contrat. Microsoft renvoie au représentant de compte pour les termes propres à chaque contrat.
Après la fin de l’abonnement P : période de grâce jusqu’au jour 30, blocage dès le jour 91
La fin de l’abonnement ne coupe pas l’accès le jour même, mais elle déclenche un calendrier que Microsoft décrit en trois temps. Pendant les 30 premiers jours, la capacité continue de tourner à sa taille actuelle, sans frais, et les espaces de travail peuvent encore être réaffectés à une capacité F. Du jour 31 au jour 90, l’accès est ralenti : les opérations interactives sont retardées, et les données peuvent encore être exportées. À partir du jour 91, toutes les opérations sont rejetées. Les données restent conservées, mais inaccessibles, jusqu’à ce que les espaces de travail soient migrés vers une capacité F ou que la capacité soit supprimée.
Microsoft écrit que la période de grâce et la période d’accès ralenti sont un filet de sécurité, pas une fenêtre de migration planifiée. Le même calendrier s’applique si l’abonnement P est résilié avant qu’une capacité F soit en place : Microsoft recommande d’éviter cet ordre, et d’acheter d’abord la capacité F, de réaffecter et valider les espaces de travail, puis seulement de résilier l’abonnement P.
De P1 à F64 : un v-core vaut 8 unités de capacité
Microsoft fait correspondre les deux familles par les unités de capacité (capacity units, CU), qui mesurent la puissance de calcul. Le v-core, l’unité de calcul du SKU P, correspond à 8 CU.
| SKU P | SKU F équivalent | CU | v-cores du SKU P |
|---|---|---|---|
| P1 | F64 | 64 | 8 |
| P2 | F128 | 128 | 16 |
| P3 | F256 | 256 | 32 |
| P4 | F512 | 512 | 64 |
| P5 | F1024 | 1’024 | 128 |
Microsoft précise que ce tableau compare la puissance de calcul et ne doit pas se lire comme une équivalence fonctionnelle ni une équivalence de licence. Le SKU équivalent est un point de départ sûr ; l’ajustement se fait ensuite sur la consommation réelle, mesurée avec l’application Microsoft Fabric Capacity Metrics, qui permet de relire la consommation de la capacité P sur les 30 à 45 derniers jours.
F64, la taille minimale pour les lecteurs sans licence Pro ni PPU
Sur une capacité F64 ou plus grande, un utilisateur qui n’a qu’une licence Fabric gratuite (Free) et le rôle Viewer sur l’espace de travail peut consulter le contenu, comme sur une capacité P. Sur les capacités F2 à F32, chaque lecteur a besoin d’une licence Power BI Pro ou PPU. Les auteurs et ceux qui modifient du contenu dans un espace de travail partagé ont besoin de Pro ou de PPU, quelle que soit la taille de la capacité.
Microsoft ajoute que les fonctionnalités Power BI Premium ne s’ouvrent que sur une capacité F64 ou plus grande. Une organisation qui passe d’une P1 à une capacité plus petite pour réduire la facture doit donc prévoir une licence Pro pour chaque lecteur de rapports.
Ce qui change dans l’achat et la facturation
L’abonnement P est un engagement Microsoft 365, mensuel ou annuel, facturé chaque mois. La capacité F s’achète dans Azure : elle est facturée à l’usage par défaut, à la seconde avec un minimum d’une minute, et peut faire l’objet d’une réservation d’un an ou de plusieurs années. Elle se met en pause et se redimensionne à tout moment. Les prix d’une capacité F varient selon la région Azure, alors que les SKU P avaient un prix global.
Microsoft indique que les tarifs à l’usage sont en général plus élevés que ceux du SKU P équivalent, et que les réservations accordent en général une remise sur les charges stables. Pour les montants, Microsoft renvoie à son calculateur de prix Azure, par région et par taille. Microsoft met aussi en garde contre un changement de région motivé par le seul écart de prix : la complexité d’un déménagement entre régions l’emporte en général sur les écarts de prix à court terme.
L’autoscale et Power BI Report Server changent de forme
L’autoscale, qui ajoutait des v-cores facturés par tranche de 24 heures sur une capacité P, n’existe pas sur les SKU F : il est remplacé par le redimensionnement à la demande et par la protection contre le dépassement de capacité (capacity overage protection). Power BI Report Server, inclus avec un SKU P, passe par une réservation de capacité Fabric, de taille F64 ou plus selon le tableau comparatif de Microsoft, ou par SQL Server Enterprise Edition avec Software Assurance. Microsoft demande de vérifier cette licence avant de résilier l’abonnement P. Power BI Embedded, en revanche, est inclus dans chaque SKU F.
Les six étapes de la migration décrites par Microsoft
La migration se fait au niveau de l’espace de travail : il n’y a pas de bascule unique pour tout le tenant. Microsoft la découpe en six étapes.
- Inventorier les espaces de travail et leurs éléments. Pour chaque espace affecté à la capacité P : ses propriétaires, ses rapports et modèles sémantiques (la couche de données sur laquelle reposent les rapports), ses horaires d’actualisation, ses passerelles de données (le logiciel qui relie Power BI aux sources de données internes). Microsoft signale que des utilisateurs ont pu créer des éléments Fabric pendant un essai, même dans une organisation qui n’a acheté que Power BI Premium.
- Créer la capacité F dans Azure, avant toute réaffectation, en gardant l’abonnement P actif jusqu’à la fin de la validation.
- Piloter sur un espace de travail peu critique, qui porte au moins un rapport, une actualisation planifiée et une connexion à une passerelle.
- Réaffecter les espaces de travail vers la capacité F : à la main depuis les réglages d’administration de la capacité s’il y a peu d’espaces, par un notebook de migration (un script exécuté dans Fabric) s’il y en a beaucoup. La réaffectation d’un espace prend en général quelques secondes.
- Valider chaque lot : les rapports s’ouvrent, les actualisations passent, les passerelles répondent, le nombre d’éléments correspond à l’inventaire.
- Mettre hors service la capacité P, en résiliant l’abonnement à la main côté Microsoft 365, une fois tous les espaces validés.
Pour une réaffectation dans la même région, Microsoft annonce une interruption nulle, hormis les actualisations en cours au moment du changement. Après la réaffectation, il peut falloir jusqu’à une heure avant de pouvoir créer des éléments Fabric sur la nouvelle capacité. Dans la même région, les modèles sémantiques, les stratégies d’actualisation incrémentielle (qui ne rechargent que la partie récente des données) et les planifications suivent l’espace de travail, et les Dataflows Gen1, la première génération des flux de préparation de données de Power BI, continuent de fonctionner sur une capacité F.
Les réglages de la capacité P à recréer sur la capacité F
Les réglages du tenant, qui valent pour toute l’organisation, ne dépendent pas de la capacité et restent en place. Les réglages propres à la capacité ne suivent pas : il faut les reconfigurer sur la capacité F. Ce sont les réglages de workload (les paramètres de la capacité par type de charge), les administrateurs de capacité et toute règle de gouvernance posée sur la capacité P. Microsoft conseille d’ajouter les administrateurs de la nouvelle capacité avant de réaffecter un premier espace, de recréer les réglages de workload dont vous dépendez, comme les limites de mémoire des modèles sémantiques, et de relire les réglages du tenant qui autorisent la création d’éléments Fabric. S’y ajoutent les droits Azure sur la ressource de capacité, à vérifier pour que les bons administrateurs puissent la gérer.
Une migration vers une autre région Azure demande plus de travail
Les rapports, les modèles sémantiques au format de stockage par défaut (petit format) et les tableaux de bord passent une réaffectation vers une autre région. Les modèles au format de grand stockage et tous les éléments Fabric, notamment les Lakehouses, Warehouses, Notebooks et pipelines Data Factory, ne la passent pas : il faut les sauvegarder avant la réaffectation, puis les recréer dans la nouvelle région, et Microsoft prévient qu’omettre cette sauvegarde entraîne une perte de données. Microsoft recommande par défaut la migration dans la même région.
Notre lecture
La première question n’est pas technique : c’est la date de fin du contrat qui porte votre abonnement P, et le nom de la personne qui détient ce contrat. L’abonnement P est un engagement Microsoft 365, alors que la capacité F sera une ressource Azure, facturée sur un abonnement Azure : ce ne sont pas forcément le même budget ni les mêmes administrateurs. Nous commencerions par réunir le détenteur du contrat Microsoft 365 et le responsable de l’abonnement Azure, et par vérifier qui détient les rôles de facturation du tenant Microsoft 365, puisque la résiliation de l’abonnement P passera par eux. Trois vérifications se font sans prestataire : la date du contrat, l’inventaire des espaces de travail et le décompte des lecteurs sans licence Pro.
Sur le dimensionnement, nous partirions du SKU équivalent, dans la même région, sans rien changer d’autre. Microsoft recommande lui-même de traiter la consolidation, le changement de région ou le redimensionnement comme des chantiers séparés, après la migration des licences, et nous sommes d’accord : un redimensionnement se décide sur une mesure faite sur la capacité F, pas sur une estimation faite avant. Descendre sous F64 ne se discute qu’après avoir compté les lecteurs sans licence Pro, parce que l’économie sur la capacité peut disparaître dans les licences.
Enfin, le calendrier réel se joue sur la validation, pas sur la réaffectation, qui prend quelques secondes par espace. Microsoft conseille de surveiller la nouvelle capacité une à deux semaines après la bascule et de valider sur un cycle d’activité complet, clôtures mensuelle et trimestrielle comprises, avant de tenir la mesure pour définitive. Payer la capacité P et la capacité F en parallèle pendant ce temps nous paraît le prix normal d’une migration sans coupure, et c’est une raison de ne pas commencer dans le dernier mois du contrat.
Ce qu’il faut vérifier
- La date de fin du contrat qui porte l’abonnement P, et la personne qui détient ce contrat chez vous.
- La liste des espaces de travail affectés à la capacité P, avec les éléments Fabric créés pendant un essai.
- Le nombre de lecteurs de rapports sans licence Pro ni PPU, si une capacité inférieure à F64 est envisagée.
- La consommation relevée par l’application Microsoft Fabric Capacity Metrics sur la capacité P.
- Les réglages de la capacité P à reproduire sur la capacité F : administrateurs, réglages de workload, gouvernance propre à la capacité.
- L’usage éventuel de Power BI Report Server et de l’autoscale, qui changent de forme sur une capacité F.
- L’ordre des opérations : capacité F achetée, espaces réaffectés et validés, puis résiliation de l’abonnement P.
Les sources Microsoft
Ce qu'un article ne peut pas savoir
Un article décrit ce qui vaut pour tout le monde. Ce qui change d'une organisation à l'autre, c'est l'inventaire : quelles applications, quels comptes, quels équipements sont réellement concernés chez vous. C'est l'inventaire qui décide de l'effort, et il ne se répond pas sur une page.
Vous parlez aux ingénieurs qui feraient le travail, pas à un intermédiaire. Réponse sous 24 heures ouvrées.
Vérifier ce qui est encore vrai
Les dates annoncées sont parfois repoussées, les produits changent de nom, les conditions évoluent. Le blog suit ces sujets au fil du temps : quand une règle change, un nouvel article le dit.
Chercher un sujet dans le blogDans le même dossier
Trois articles du même sujet. Le blog en compte 155, tous en accès libre.