Power BI : approches et stratégies de migration de locataire

Les organisations font face à différents scénarios de migration de locataires dans Power BI, pilotées par des fusions et acquisitions, des désaffectations d’entreprise, des exigences de résidence des données ou des besoins de conformité régionaux. Les migrations de locataires sont des entreprises complexes qui nécessitent une planification minutieuse, des stratégies de sauvegarde complètes et une exécution systématique. Cet article fournit des conseils pour les migrations de locataires à l’échelle de l’entreprise Power BI, y compris les frameworks de décision pour déterminer si la migration est nécessaire et des méthodologies d’implémentation détaillées pour différents modèles de migration.

Important

Les migrations de locataires présentent un risque important et nécessitent un effort manuel étendu. Microsoft ne fournit pas de prise en charge directe de la migration de contenu entre des locataires ou au sein du même locataire pendant les réinstallations régionales. Avant de poursuivre la migration, évaluez soigneusement les alternatives telles que les capacités multigéographiques qui peuvent traiter de nombreux scénarios sans la complexité et le risque de migration complète du locataire.

Scénarios de migration de locataire

Power BI migration de locataire couvre trois scénarios. Identifiez celui qui s’applique à votre situation avant de planifier votre migration.

Scénario Description Déclencheur classique
Migration côte à côte (entre locataires) Deux locataires distincts Microsoft 365 fonctionnent en parallèle. Les artefacts sont déplacés du locataire source vers le locataire cible individuellement. Fusions et acquisitions qui consolident deux organisations en un seul locataire.
Fractionnement du locataire Un seul locataire Power BI est séparé en deux locataires indépendants. Les artefacts, les espaces de travail et les utilisateurs appartenant à l’entité métier sortante sont découpés de manière sélective. Désaffectations et spin-offs.
Remappage de locataire (relocalisation du locataire) Le locataire Power BI est supprimé puis recréé dans une nouvelle région d’origine au sein du même locataire Microsoft 365. L’ID de locataire, le domaine et les identités utilisateur Microsoft 365 sont conservés. Pour plus d’informations, consultez Move Power BI entre les régions géographiques. Exigences de localisation des données qui imposent la région d’accueil du locataire dans un pays/une région spécifique.

Les migrations parallèles et les scissions de locataires sont des opérations inter-locataires. Le remappage de locataire est une relocalisation de région au sein du même locataire Microsoft 365.

Note

Pour connaître les considérations et limitations relatives au remappage du locataire (relocalisation régionale) avec le support Microsoft, consultez Déplacer votre locataire Power BI vers une autre région. L’assistance Support Microsoft se limite à supprimer le locataire précédent et à réaffecter un nouveau locataire à la région spécifiée ; aucune assistance à la migration n’est fournie. Vous devez disposer d’un plan de réhydratation pour les données et les métadonnées, que ce soit par le biais d’une sauvegarde et d’une restauration par script, d’actions manuelles ou d’un processus de recréation et de rechargement. Cette procédure présente un risque considérable, notamment la perte potentielle de données ou d’artefacts si les sauvegardes sont incomplètes ou les artefacts sont omis. La durée d’interruption pendant le remappage du locataire peut aller de trois à 24 heures, une interruption plus longue étant nécessaire pour restaurer les artefacts.

Évaluer les alternatives avant la migration

La migration de locataire implique des risques et des efforts considérables. Explorez d’autres options avant de continuer. Les stratégies suivantes peuvent vous aider à éviter la migration ou la réinstallation d’un locataire.

Déploiement multigéographique

Un déploiement multigéo vous permet de déployer Power BI et la capacité Fabric dans la région de votre choix tout en conservant inchangée la région d’origine du locataire. Les données au sein de ces capacités restent proches de vos utilisateurs finaux, et vous pouvez avoir plusieurs capacités dans différentes régions sous le même locataire.

La migration d’artefacts vers une capacité dans une autre région est plus simple que la migration du locataire lui-même. Pour déplacer un espace de travail vers une autre région, réaffectez l’espace de travail d’une capacité à une autre. La réaffectation est transparente pour les éléments Power BI.

Important

Les éléments Fabric ne sont pas conservés lors de la réaffectation d’un espace de travail entre des capacités situées dans différentes régions. Supprimez Fabric éléments avant la réaffectation de l’espace de travail et recréez-les par la suite, ou utilisez l’intégration Git pour sauvegarder et restaurer des éléments Fabric.

Prenez en compte le déploiement multigéographique pour les exigences suivantes :

  • Latence des données. Placez des données et calculez plus près des utilisateurs finaux en déployant la capacité dans leur région.
  • Résidence des données. Vos données et calcul sont liés à votre région de capacité , et non à votre région de locataire. Un déploiement multi-géo permet de conserver les données dans les limites des exigences de résidence des données pour la plupart des charges de travail.

N’envisagez un remappage du locataire que lorsque les exigences en matière de résidence des données sont si strictes que même les métadonnées du locataire (définitions d’espace de travail, métadonnées du modèle sémantique, métadonnées visuelles, paramètres, stratégies) et les informations utilisateur de Microsoft 365 doivent rester dans les limites imposées par la résidence des données.

Apportez votre propre compte de stockage pour Dataflow Gen1

Dataflow Gen1 écrit ses données de sortie dans un compte Azure Data Lake Storage (ADLS) Gen2 qui, par défaut, se trouve dans la région d’origine du locataire Power BI. Si l’emplacement de stockage de Dataflow Gen1 est votre seule exigence en matière de résidence des données, configurez à la place un compte ADLS Gen2 que vous fournissez vous-même dans la région souhaitée, plutôt que de déplacer le locataire.

Relais Azure personnalisé pour incompatibilité de région de la passerelle

Si votre capacité est déployée dans une autre région que celle de votre région d’accueil de locataire, le point de terminaison de passerelle de données locale par défaut achemine le trafic vers la région d’origine. Pour conserver le trafic de passerelle dans votre région de capacité, configurez un relais Azure personnalisé. Une discordance entre régions de passerelle, à elle seule, ne devrait pas déclencher une migration de locataire.

Évaluer l’analyse de rentabilité

Si une migration de locataire est pilotée par un besoin métier (par exemple, consolidation de la facturation), pesez l’effort et le risque par rapport au résultat. Un petit tenant peut être facile à migrer ; un grand tenant avec un volume important de contenu Fabric peut nécessiter de réexaminer le besoin métier avant d’aller plus loin.

Ce qui est pris en charge pour la migration

La plupart des éléments Power BI prennent en charge l’export de définition via l’API d’administration Power BI ou l’Workspace Scanner API et peuvent faire l’objet de scripts. La plupart des éléments Fabric ne prennent pas en charge l'exportation de définition et doivent être recréés manuellement.

Le tableau suivant récapitule le chemin de migration de chaque type d’artefact.

Commande Artéfact Chemin de migration
1 Gateways Aucun chemin de migration. Doit être reconfiguré dans le locataire cible par un administrateur Power BI.
2 Espaces de travail Aucun chemin de migration. Doit être recréé dans le tenant cible. La création en bloc est possible à l’aide de l’API d’administration Power BI.
3 Articles en tissu Les éléments qui prennent en charge l’intégration Git peuvent être sauvegardés en validant un commit dans Git, en les dissociant de l’espace de travail source, puis en les associant de nouveau à un nouvel espace de travail dans le locataire cible. Seule la définition est sauvegardée ; les données ne sont pas incluses. Les éléments qui ne prennent pas en charge l’intégration Git doivent être recréés manuellement. Pour Lakehouse, seules les métadonnées sont conservées ; les tables delta et les schémas ne sont pas transférés.
4 Flux de données Téléchargez le JSON de définition et réimportez-le dans le locataire de destination. Le script est possible à l’aide de l’API d’administration.
5 Modèles sémantiques / jeux de données Utilisez la sauvegarde et la restauration sur un compte de stockage ADLS Gen2, ou téléchargez la définition et réimportez. Le script est possible à l’aide de l’API d’administration.
6 Rapports Les propriétaires ou les administrateurs téléchargent le fichier .pbix et le republient dans le locataire cible. Vous pouvez également exporter la définition JSON. Le script est possible à l’aide de l’API d’administration.
7 Dashboards Aucun chemin de migration. Doit être recréé manuellement.
8 Applications Power BI Aucun chemin de migration. Doit être recréé manuellement.
9 Rapports paginés Les propriétaires ou administrateurs téléchargent le fichier RDL et publient sur le locataire cible.

Important

Recréez toujours les artefacts dans cet ordre. Les artefacts en aval dépendent des artefacts en amont, et ne pas respecter cet ordre peut entraîner des références brisées pendant l’exécution. L’exécution d’une synchronisation Git efface tous les éléments de l’espace de travail qui n’existent pas dans le référentiel.

Méthodologie de migration

Tenez compte des activités de référence suivantes. La plupart des étapes s’appliquent aux trois scénarios. Les étapes spécifiques à un scénario sont indiquées dans leurs titres.

Étape 1 : Évaluation de la découverte et de l’inventaire

Créez un inventaire complet des artefacts et des dépendances, et identifiez ce que vous pouvez, ne pouvez pas ou ne devez pas migrer.

Activités

  • Effectuez une découverte à l’échelle de l’ensemble du locataire à l’aide d’une combinaison des éléments suivants :
    • API d’administration Power BI
    • API d’administration Fabric
    • Journaux d’activité (espaces de travail, rapports, jeux de données, actualisations)
    • Documentation manuelle pour les éléments non exposés par les API
  • Capture:
    • Espaces de travail (type, capacité, région)
    • Rapports, modèles sémantiques (en particulier format de stockage volumineux), dataflows
    • éléments de Fabric (Lakehouse, Warehouse, Eventhouse, notebooks)
    • Passerelles, sources de données, informations d’identification
    • Rôles de sécurité au niveau des lignes (RLS), autorisations d’espace de travail, liens de partage
  • Classifiez chaque espace de travail par complexité de migration (faible, moyen, élevé) en fonction des artefacts qu’il contient et des dépendances.

Résultats

  • Feuille de calcul d’inventaire principale.
  • Classification de complexité de la migration pour chaque espace de travail.

Étape 2 : Découverte de l’utilisateur et de la sécurité

Capturez l’identité de l’utilisateur, les licences et les autorisations, puis mappez-les entre les locataires si nécessaire.

Lors d’un remappage de locataire, les identifiants des objets utilisateur sont conservés. Pour une migration côte à côte ou un fractionnement de locataire, les utilisateurs ont des ID d’objet différents dans le locataire cible. Associez l’identité de chaque locataire source à celle du locataire cible. Réaffecter les attributions de licences Power BI (Free, Pro, PPU). Groupes de sécurité miroir dans le nouveau locataire Microsoft 365.

Activités

Identifier et enregistrer :

  • Power BI attributions de licences (provenant de Microsoft Graph)
  • ID d’objet utilisateur dans le locataire source
  • ID d’objet utilisateur dans le locataire cible (côte à côte ou fractionné uniquement)
  • Autorisations utilisateur et niveaux d’accès à l’espace de travail
  • Paramètres actuels au niveau du locataire (capturer manuellement via le portail d’administration)
  • Configurations de gouvernance actuelles (étiquettes de confidentialité, stratégies d’approbation)

Vous pouvez extraire des autorisations d’espace de travail et d’artefact à l’aide des API d’administration Power BI et de l’API Workspace Scanner.

Étape 3 : Communication des parties prenantes et gestion des changements

Communiquez le plan de migration tôt pour réduire la résistance et la charge de prise en charge.

Groupes de parties prenantes clés

  • Sponsors exécutifs
  • Propriétaires d’espaces de travail et auteurs de rapports
  • Utilisateurs finaux
  • Équipes informatiques, de sécurité et d’identité

Activités

  • Développer un plan de communication couvrant les points suivants :
    • Vue d’ensemble de la migration et logique.
    • Qu’est-ce qui n’est pas migré (par exemple, espaces de travail personnels, espaces de travail inactifs).
    • Modifications (URL, accès, minutage de l’actualisation). Les liens Power Apps et SharePoint en aval qui font référence à des URL Power BI sont également affectés.
    • Ce qui ne change pas (sémantique des données, visuels, logique métier).
  • Communiquer les dates clés :
    • Figer les fenêtres (généralement environ une semaine d’absence de modification dans le locataire source pendant la sauvegarde finale).
    • Durée d’indisponibilité prévue (pour les scénarios de réaffectation de locataire).
    • Périodes de validation pour que les parties prenantes vérifient leurs propres rapports dans le locataire cible.
    • Jalons de basculement et dates de mise hors service pour le locataire source (scénarios parallèles).

Résultats

  • Une présentation d’information à destination des parties prenantes.
  • Une FAQ pour l’utilisateur final.

Étape 4 : Soumettre une demande de réattribution du locataire (réattribution du locataire uniquement)

Lorsque la date de migration est verrouillée, envoyez un ticket d’assistance et sélectionnez spécifiquement l’option de remappage de locataire. Un ingénieur du support technique Microsoft prend la demande.

Activités

  • Envoyez le ticket de support.
  • Terminez la liste de contrôle de préparation fournie par Microsoft.
  • Convenez d’une date et d’un créneau horaire pour la migration, ainsi que d’un créneau de secours.
  • Supprimez la capacité existante avant la remappage du locataire.

Résultats attendus

  • Un remappage classique prend environ trois heures, mais les retards allant jusqu’à 24 heures sont possibles si des complications se produisent.
  • Une fois le remappage terminé, le nouveau locataire a le même ID de locataire et se trouve dans la région demandée.

Étape 5 : Préparation du locataire cible

Un locataire nouvellement créé ou nouvellement réaffecté n’est pas immédiatement prêt à recevoir du contenu. Configurez-le d’abord.

Activités

  • Configurez les paramètres de locataire Power BI :
    • Contrôles de création d’espace de travail
    • Partage et stratégies d’accès externe
    • Gouvernance des visuels personnalisés
    • Étiquettes de confidentialité et protection des informations
    • Journal d’audit et activation de la surveillance
  • Achetez des capacités Fabric de SKU égal ou supérieur à celui de la source.
  • Configurez et validez les passerelles, les clusters de passerelle et la connectivité des données.
  • Pour les scénarios côte à côte ou de fractionnement de locataire :
    • Créez un utilisateur dans le locataire cible pour chaque utilisateur du locataire source et consignez la correspondance des utilisateurs.
    • Recréez des groupes d’utilisateurs à partir du locataire source.
    • Attribuez des licences Power BI dans le locataire cible.
  • Aligner la gouvernance : étiquettes de confidentialité, intégration Microsoft Purview et stratégies d’approbation.

Étape 6 : Pilote de migration

Exécutez une migration de test sur un exemple d’espace de travail représentatif avant la migration de production.

Pour les migrations parallèles, le tenant source reste disponible comme solution de repli en cas de nouvelle tentative. Lors d’un remappage de locataire, le contenu qui n’a pas été correctement sauvegardé avant le remappage est irrécupérable. Un pilote réussi est le principal moyen de réduire les risques liés au parcours de remappage.

Critères de sélection de l’espace de travail pilote

  • Contient un mélange d’artefacts : rapports, modèles sémantiques, dataflows et éléments Fabric.
  • Utilise des sources de données réalistes et des planifications d’actualisation.
  • Dispose des autorisations au niveau de l’espace de travail et idéalement des lignes de sécurité.
  • Est activement utilisé, mais pas stratégique.

Étape 7 : Exécution de la migration

Exécutez la migration. Les éléments pris en charge sont d’abord scriptés ; les éléments non pris en charge sont recréés manuellement.

Pour les environnements client de grande taille, écrivez des scripts qui s’appuient sur l’API d’administration de Power BI pour exporter et recréer en masse des artefacts.

Recréez les artefacts selon l’ordre défini dans Éléments pris en charge pour la migration. Ne pas respecter l’ordre rompt les dépendances.

Étape 8 : Validation et test

Vérifiez que le contenu est correctement migré et se comporte correctement.

Les définitions de modèle sémantique exportées n’incluent pas les données sous-jacentes. Chaque modèle sémantique importé a besoin d’au moins une actualisation manuelle dans le locataire cible.

Tip

Envisagez une mise à l’échelle temporaire vers une référence SKU de capacité plus élevée pendant la validation. Un grand nombre d’actualisations simultanées peuvent autrement saturer la capacité cible.

Activités

  • Valider les données : nombres de lignes, agrégats de clés, réussite de l’actualisation.
  • Valider la sécurité : règles RLS, accès à l’espace de travail, étendues de partage.
  • Valider les performances : indiquez les temps de chargement des rapports, les temps de réponse des requêtes et la marge de capacité disponible.

Étape 9 : Basculement et adoption des utilisateurs

Déplacez les utilisateurs vers le locataire cible et mettez à jour les applications en aval.

Activités

  • Accordez aux utilisateurs l’accès aux espaces de travail et aux artefacts dans le locataire cible.
  • Mettez à jour les URL des rapports incorporés, les liens SharePoint, les connexions Power Apps et les flux Power Automate qui font référence à du contenu Power BI.
  • Désactivez les modifications dans le locataire source (phase de lecture seule) avant la mise hors service définitive.
  • Exécutez des sessions d’activation courtes couvrant ce qui a changé et où trouver du contenu.

Contenu connexe

  • Last updated on