Vue d’ensemble de la migration Power BI Premium vers Microsoft Fabric

Microsoft abandonne progressivement les SKU Power BI Premium par capacité (SKU P). Chaque abonnement de référence SKU P se termine à la fin de son contrat actuel et Microsoft ne vend plus de nouvelles références SKU P. Pour maintenir les charges de travail Power BI en fonctionnement, migrez vers les SKU de capacité Microsoft Fabric (F SKUs). Cet article vous offre une vue d’ensemble complète de la migration : pourquoi les SKU Fabric F constituent la voie à suivre, ce qui change et ce qui reste identique pour les utilisateurs finaux et les administrateurs, les étapes d’une migration classique et les scénarios qui déterminent le niveau de complexité de votre migration.

Cet article est destiné aux administrateurs Fabric, aux administrateurs Power BI, aux architectes informatiques et aux propriétaires de capacité qui planifient et exécutent la migration.

Important

Prévoyez d’achever votre migration avant la fin de votre abonnement de référence SKU P. Une fois votre abonnement terminé, votre capacité entre dans une période de grâce de 30 jours. À compter du jour 31, l’accès est limité (les opérations interactives sont retardées). Le jour 91 et au-delà, toutes les opérations sont rejetées : vos données sont conservées mais inaccessibles jusqu’à ce que vous migrez les espaces de travail vers une capacité de référence SKU F Fabric ou supprimez la capacité. Pour éviter toute perturbation, réaffectez vos espaces de travail à une capacité Fabric de type F SKU avant l’expiration de votre abonnement P SKU. Pour connaître la procédure, consultez Migrer des espaces de travail de Power BI Premium vers Microsoft Fabric.

Note

Clients Contrat Entreprise. Si votre contrat Entreprise est toujours actif, vous pouvez continuer à exécuter la capacité de référence SKU P existante et la renouveler annuellement par le biais de votre contrat jusqu’à la fin de la période EA. Les clients ayant expiré des contrats Entreprise ou des contrats Microsoft Cloud ne peuvent pas ajouter ou acheter de nouvelles capacités de référence SKU P par le biais de leur contrat. Confirmez vos conditions de contrat spécifiques avec votre représentant compte Microsoft avant de décider quand migrer.

Note

Cette mise hors service a deux limites d’étendue importantes :

Les licences par utilisateur ne sont pas affectées.Power BI Pro et Power BI Premium Per User (PPU) restent inchangés. Pour plus d’informations, voir Est-ce que Power BI Premium par utilisateur (PPU) est également mis hors service ?
Les licences incorporées (EM, A) ne sont pas affectées. Ces références SKU ne font pas partie de cette mise hors service.
Les clouds souverains ne sont pas encore affectés. Microsoft Fabric n’est pas disponible dans les environnements cloud souverains, de sorte que les SKU P y restent prises en charge. Microsoft fournit des conseils distincts lorsque Fabric devient disponible dans ces environnements.

Pourquoi migrer vers Microsoft Fabric

L’abandon des SKU P est le facteur immédiat, mais les SKU F de Fabric offrent également des capacités que les SKU P ne peuvent pas fournir :

Vous ne payez que pour ce que vous utilisez. Les SKU F utilisent par défaut la facturation Azure à l’utilisation, avec des réservations annuelles ou pluriannuelles en option pour les charges de travail prévisibles. Vous pouvez également suspendre une capacité lorsqu’elle est inactive pour arrêter la facturation pendant les heures creuses et la reprendre ultérieurement à la demande.
Augmentez ou réduisez la capacité à tout moment. Redimensionnez les capacités via le portail Azure à mesure que vos charges de travail changent, au lieu de valider une taille fixe pour la durée d’un abonnement.
Utilisez le modèle d’exploitation natif Azure. Provisionnez et gérez la capacité via le portail Azure, appliquez des étiquettes Azure pour la rétrofacturation et comptez les dépenses Fabric pour votre engagement de consommation Microsoft Azure (MACC). De nombreuses charges de travail Fabric (comme les Lakehouses, les Warehouses, les Notebooks et les pipelines Data Factory) fonctionnent sur des capacités P ou F, mais le modèle d’exploitation Azure est limité au modèle F.
Utilisez Power BI Embedded sans référenceS SKU distinctes. Les scénarios incorporés sont couverts par chaque référence SKU F. Vous n’avez donc pas besoin de références SKU EM ou A distinctes.
Utilisez la sécurité et les opérations natives Azure. Les points de terminaison privés gérés, l’accès approuvé à l’espace de travail, Azure Monitor et Microsoft Cost Management sont tous disponibles avec les SKU F.

Pour obtenir la comparaison complète des fonctionnalités par fonctionnalité, consultez les principales différences entre les références SKU Power BI P Premium et les références SKU Fabric F.

Ce qui change et ce qui reste le même

La migration implique principalement une modification des licences et de l’infrastructure. Les expériences des utilisateurs finaux et la plupart des comportements administratifs restent les mêmes. Certains domaines opérationnels changent.

Domaine	Modifier ?	Après avoir effectué la migration vers le SKU F
Rapports, modèles sémantiques, tableaux de bord	Identique	Continuez à fonctionner sans modification sur les capacités F64 ou supérieures.
Licences utilisateur (Pro, PPU, Gratuit)	Identique	Inchangé. À partir de F64, les utilisateurs disposant d’une licence Fabric gratuite et du rôle Lecteur peuvent consulter le contenu, comme avec les SKU P. De F2 à F32, chaque utilisateur doit disposer d’une licence Pro ou PPU.
Espaces de travail et applications	Identique	Les espaces de travail sont réaffectés à la nouvelle capacité. Les applications d’espace de travail, les pipelines de déploiement et l’intégration Git continuent de fonctionner.
Actualiser les planifications et les pipelines	Identique	Continuez à fonctionner sur la nouvelle capacité. Les actualisations actives peuvent être interrompues pendant la réaffectation.
Power BI Report Server	Identique, avec modification de licence	Toujours disponible, avec une réservation de capacité Fabric ou SQL Server Êdition Entreprise avec Software Assurance.
Power BI Embedded	Identique, plus simple	Inclus avec chaque référence SKU F. Les références SKU EM et A distinctes ne sont pas requises.
Achat et facturation	Changes	Passez de la facturation avec engagement Microsoft 365 à la facturation Azure. Les SKU F prennent en charge le paiement à l’utilisation ainsi que les réservations annuelles ou pluriannuelles.
Gestion de la capacité	Changes	Principalement géré via le portail Fabric (affectations d’espaces de travail et paramètres au niveau de la capacité). Les opérations de pause, de reprise, de montée en puissance et de scale-down sont effectuées via le portail Azure.
Autoscale	Changes	La mise à l’échelle automatique de la référence SKU P n’existe pas sur les références SKU F. Au lieu de cela, les SKU F utilisent le redimensionnement à la demande : vous augmentez ou réduisez manuellement la capacité dans le portail Azure.
Gouvernance de la capacité	Nouvelles fonctionnalités	De nouvelles fonctionnalités de gouvernance des coûts sont disponibles sur les références SKU F, telles que la protection contre les augmentations de capacité au niveau de l’espace de travail et la protection contre le dépassement de capacité. Utilisez-les pour maîtriser la consommation et éviter toute dérive des coûts.
Prise en charge des éléments interrégions	Nouvelle considération	Les éléments de Power BI standard survivent à une réaffectation interrégion. Les modèles sémantiques de format de stockage volumineux nécessitent la sauvegarde et la restauration ou l’effacement et la conversion en petit format de stockage avant la réaffectation. Tous les éléments Fabric (Lakehouses, Warehouses, Notebooks, pipelines de Data Factory) empêchent la réaffectation d’aboutir.

Le parcours de migration en un clin d’œil

Dans sa forme la plus simple, la migration P-to-F correspond à une migration 1:1 vers le SKU F équivalent dans la même région Azure. Les clients utilisent souvent la migration comme opportunité de consolider les capacités, de se déplacer entre les régions ou de les redimensionner. Chacune de ces modifications ajoute de la complexité et du risque. Traitez ces modifications comme des flux de travail distincts qui s’exécutent une fois la migration de licence terminée.

La migration suit les cinq mêmes étapes, quelle que soit la taille ou la complexité.

Décider. Choisissez quand migrer, la référence SKU F à utiliser et si vous souhaitez rester dans la même région Azure. Consultez le guide de décision pour la migration vers Power BI Premium P SKU.
Plan. Inventoriez les espaces de travail, établissez la consommation de base en CU à l’aide de l’application Microsoft Fabric Capacity Metrics, et estimez la consommation future avec le Fabric SKU Estimator. Inscrivez le Microsoft.Fabric fournisseur de ressources dans Azure et choisissez un espace de travail pilote. Pour une validation pratique avant l’achat, provisionnez une capacité d’essai Fabric pour tester les charges de travail.
Disposition. Achetez le SKU F avant de réaffecter quoi que ce soit. Choisissez le paiement à l’utilisation ou une réservation, puis vérifiez la licence de Power BI Report Server si vous l’utilisez.
Migrez et validez. Réaffectez des espaces de travail dans le portail d’administration Fabric ou à l’aide du bloc-notes de migration de capacité. Pour les déplacements entre régions, recréez les modèles sémantiques au format de stockage volumineux et les éléments Fabric dans la nouvelle région. Validez les actualisations, les rapports et les passerelles. Consultez Migrer des espaces de travail de Power BI Premium vers Microsoft Fabric.
Désaffecter et opérer. L'annulation de la référence SKU P est manuelle : Fabric ne désaffecte pas automatiquement votre référence SKU P lorsque vous approvisionnez une référence SKU F. Après avoir validé la migration, annulez explicitement l’abonnement P SKU dans le Microsoft 365 admin center. Ensuite, configurez la surveillance des coûts à l’aide de Microsoft Cost Management et tirez parti de la flexibilité de pause, de reprise et de mise à l’échelle dans Fabric.

Scénarios de migration

La plupart des clients se trouvent dans l’un des quatre scénarios suivants. Les trois premiers scénarios suivent les étapes de migration standard dans Migrer des espaces de travail de Power BI Premium vers Microsoft Fabric.

Scénario	Complexité	Notes
Même locataire, même région	Faible	Valeur par défaut recommandée. Réaffectez chaque espace de travail à la nouvelle référence SKU F. Aucun temps d’arrêt attendu en dehors des actualisations actives.
Même locataire, entre régions	Modéré à élevé	Suit les étapes de migration standard, mais les modèles sémantiques de format de stockage volumineux et les éléments Fabric doivent être sauvegardés ou capturés sur Git, supprimés et recréés dans la nouvelle région. Consultez les migrations interrégions : gestion spéciale.
Multigeo (plusieurs références SKU F dans différentes régions, même locataire)	Moderate	Suit les étapes de migration standard, mais implique l’achat de SKU F dans chaque région cible et la planification d’une gouvernance pour le contenu spécifique à chaque région. Consultez les migrations Multigeo.
Inter-locataires	Élevé ; non pris en charge par migration en un clic	Ne suit pas les étapes de migration standard. Nécessite de recréer manuellement les passerelles, les modèles sémantiques, les espaces de travail, les rapports, les applications et les tableaux de bord. Envisagez d’abord multigéo. Consultez les migrations interlocataires.

Caution

Les migrations interrégions impliquent beaucoup plus d’efforts que les migrations de même région. Au-delà des types d’éléments qui ne survivent pas à la réaffectation interrégion, planifiez les éléments suivants :

Les éléments Fabric ne sont pas conservés lors des déplacements entre régions. Les pipelines Lakehouses, Warehouses, Notebooks et Data Factory entraînent l’échec de la réaffectation. Capturez leurs définitions sur Git (ou exportez-les) avant de les réaffecter, puis recréez-les dans la région cible.
Rebinding de rapport. Lorsque vous sauvegardez et restaurez (ou supprimez et redéployez) un modèle sémantique de format de stockage volumineux, le modèle recréé obtient un nouveau GUID. Les rapports qui faisaient référence au modèle d’origine doivent être reliés de nouveau au modèle recréé.
Surcoût de la passerelle. Les cibles interrégions nécessitent souvent une configuration et une validation supplémentaires de la passerelle de données locale, en particulier si vos passerelles utilisent des relais Azure sous Bring Your Own Relay (BYOR), car les points de terminaison de relais sont liés à la région.

Choisissez la migration inter-régions uniquement lorsque la résidence des données ou une autre contrainte matérielle l’exige. La migration dans la même région est la valeur par défaut recommandée.

Après la migration

Après avoir réaffecté des espaces de travail et validé que les rapports et les actualisations fonctionnent sur la nouvelle référence SKU F, donnez-vous une fenêtre de stabilisation avant d’annuler la référence SKU P et avant d’entreprendre tout travail de modernisation facultatif. Les activités suivantes vous aident à vérifier que la migration s’est effectuée sans problème et à décider des prochaines étapes.

Stabiliser le coût

Les dépenses liées au SKU F sont prévisibles si vous laissez les capacités fonctionner en continu. Votre coût mensuel reste stable, même si les tarifs de paiement à l’utilisation sont généralement plus élevés que la référence SKU P équivalente. Utilisez des réservations pour garantir des économies sur des charges de travail régulières, et utilisez la mise en pause et la reprise pour les capacités réellement inactives pendant une partie de la journée. Pour stabiliser les coûts :

Suivez les dépenses quotidiennes pendant les 30 premiers jours à l’aide de Microsoft Cost Management.
Configurez des budgets et des alertes Azure pour le groupe de ressources de la capacité afin d’être averti avant que les dépenses ne dépassent le montant prévu.
Évaluez une réservation annuelle de capacité de Fabric une fois la consommation quotidienne stable. Les réservations offrent généralement une remise sur les charges de travail prévisibles.
Suspendre les capacités inactives en dehors des heures d’ouverture pour arrêter la facturation pendant ces fenêtres.

Stabiliser les performances

Pour une migration 1:1 au sein de la même région vers le SKU F équivalent, la consommation de CU devrait correspondre étroitement à votre niveau de référence du SKU P après stabilisation. Attendez-vous à une variation de performances lorsque la migration inclut une modification de configuration ( une autre région, une autre taille de référence SKU ou une consolidation de charge de travail) et validez avant de désactiver la référence SKU P. Les surcharges signalées après la migration sont souvent causées par des modifications de charge de travail (une rafale d’actualisations, un contenu ajouté, des planifications d’actualisation modifiées) plutôt que la migration elle-même. Vérifiez les modèles d’utilisation avant de supposer que la référence SKU F est la cause. Pour stabiliser les performances :

Surveillez la nouvelle capacité avec l’application Microsoft Fabric Capacity Metrics au cours de la semaine ou des deux semaines suivant le basculement.
Comparez-la à la référence relevée sur le SKU P. Examinez les écarts importants dans la fréquence d’actualisation, la taille du jeu de données ou la charge liée aux interactions avant de modifier la taille.
Augmentez la capacité à la demande via le portail Azure si vous constatez une limitation persistante. Consultez Mettre à l’échelle votre capacité.
Validez l’ensemble d’un cycle d’activité complet : incluez la fin du mois et la clôture trimestrielle avant de traiter la base de référence comme finale.
Revérifiez la ligne de base chaque fois que vous ajoutez un nouveau contenu significatif ou modifiez les planifications d’actualisation.
Validez de nouveau après toute modification de configuration de votre côté (taille du SKU, région, attribution de charge de travail).
Pour obtenir des conseils plus larges sur la planification de la croissance et de la gouvernance des capacités, consultez Microsoft Fabric guide de planification de la capacité.

Examiner les opérations et la gouvernance

Certains paramètres opérationnels ne sont pas reportés automatiquement lorsque les espaces de travail passent à une référence SKU F. Consultez les pages suivantes :

Vérifiez les attributions RBAC Azure sur la ressource de capacité afin que les administrateurs autorisés puissent la gérer.
Réappliquez les paramètres de charge de travail au niveau de la capacité (par exemple, les limites de mémoire du modèle sémantique) dans le portail d’administration Fabric s’ils ont été personnalisés sur la référence SKU P.
Vérifiez à nouveau le paramètre de locataire « Les utilisateurs peuvent créer des éléments Fabric » ainsi que toutes les délégations limitées à la capacité.
Appliquez des balises Azure à la ressource de capacité afin que les rapports de rétrofacturation et de showback attribuent les dépenses au bon centre de coûts.
Évaluez les nouvelles fonctionnalités de gouvernance de l’utilisation de la capacité disponibles sur les références SKU F (telles que la protection contre les augmentations au niveau de l’espace de travail et la protection contre le dépassement de capacité) pour définir les garde-fous avant d’ouvrir la capacité à une consommation plus large.

Explorer les opportunités de modernisation

De nombreux scénarios de modernisation de Fabric sont également techniquement possibles avec les SKU P. Les modifications apportées aux références SKU F sont le modèle d’exploitation : gestion des coûts natifs Azure, fonctionnalités de gouvernance de la capacité (telles que la protection contre les augmentations et les dépassements de capacité) et la protection unifiée Azure RBAC facilitent la prise en charge de ces scénarios avec des garde-fous de coûts plus clairs et une meilleure confiance opérationnelle. Ces options sont des suivis facultatifs, et non des exigences de migration :

Apportez des données existantes dans OneLake à l’aide de la mise en miroir et des raccourcis.
Convertissez les modèles sémantiques DirectQuery en modèles sémantiques Direct Lake lorsque les charges de travail peuvent en bénéficier.
Adoptez la sécurité OneLake pour les contrôles d’accès aux données unifiés entre les charges de travail Fabric.

Traitez ces options comme des flux de travail distincts qui s’exécutent une fois la migration de licence terminée. Ils ne bloquent pas la migration et ne doivent pas étendre sa chronologie.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-22