10 min
La migration tenant-to-tenant d’infrastructure Azure est une opération délicate. Elle peut s’avérer nécessaire notamment en cas d’acquisition ou de scission d’entreprises.
Dans cet article, notre expert vous détaille les enjeux et les complexités de la modification de rattachement des ressources et du tenant, ainsi que les différentes approches pour y parvenir, en fonction des types d’abonnements.
🗣️ Gilles Fay, architecte technique, Blue Soft Empower.
Les types d’abonnements sont une composante importante des stratégies de migration cloud Azure car ils déterminent les limites de ressources et les permissions d’accès pour les utilisateurs et les services. En choisissant le bon type d’abonnement, les entreprises peuvent optimiser leur coût et leur sécurité tout en bénéficiant d’une flexibilité accrue pour leurs déploiements Azure.
Pour avoir une vue exhaustive des différentes possibilités selon le type d’abonnement source et cible, consultez la page de Microsoft Learn : Hub de transfert de produits Microsoft Cloud Azure : Prise en charge du transfert de produits
Néanmoins, en tant que CSP (Cloud Service Provider), les cas que nous avons eu à traiter concernaient des abonnements CSP (MPA = Microsoft Partner Agreement) et des abonnement MOSP (PAYG). À chaque fois, cela a nécessité le déplacement de ressources Azure d’un abonnement vers un autre.
Lexique sur les types d’abonnements
Les abonnements Microsoft Cloud Azure permettant d’héberger des ressources – et donc des charges de travail – sont associés à un Locataire Azure AD (tenant), c’est-à-dire un annuaire cloud permettant de gérer les droits sur ces ressources. Il est parfois nécessaire de modifier ces abonnements, soit pour les rattacher à un autre annuaire, soit pour déplacer des ressources qu’ils contiennent vers un autre abonnement :
Compte tenu des dépendances entre abonnement et tenant, mais aussi entre les ressources d’un même abonnement, c’est une opération qui peut parfois s’avérer très délicate à chiffrer et à effectuer. Ce type d’opération peut également amener à des interruptions de service assez importantes quand il est exécuté sur des environnements de production. Enfin, selon le cas, le premier besoin (déplacement entre tenant) peut nécessiter le deuxième (déplacement entre abonnement).
Dans le cas d’abonnement rattachable (Pay-as-you-Go), le rattachement de l’abonnement à un autre tenant est possible.
– Avantage : pas besoin de déplacer les ressources d’un abonnement vers un autre
– Impact : perte des informations qui relient l’abonnement au tenant (RBAC, identités managées, rôles personnalisés, stratégies d’accès, ACL, authentifications AD dans les bases de données…etc)
Il faudra donc faire un état des lieux détaillé et recréer/reconfigurer tout cela dans la cible après rattachement.
Dans le cas d’abonnement non rattachable (CSP), il n’est pas possible de rattacher l’abonnement à un autre tenant : l’option de changement d’annuaire n’est pas prise en charge pour l’abonnement CSP).
Il faut alors déplacer les ressources d’un abonnement vers un autre.
De plus, si l’abonnement cible est également de type CSP, il va falloir utiliser un abonnement intermédiaire de type Pay-As-You-Go qui sera rattaché successivement au tenant source puis au tenant cible. Et un double déplacement sera nécessaire : d’abord de l’abonnement source vers l’abonnement intermédiaire, puis de l’abonnement intermédiaire vers l’abonnement cible.
L’abonnement intermédiaire étant détaché et rattaché à un tenant différent, l’impact observé dans le premier cas est toujours vrai : perte des informations qui relient l’abonnement au tenant.
L’impact du déplacement de ressources d’un environnement vers un autre est le plus lourd :
Pour déplacer des ressources d’un abonnement vers un autre, les 2 abonnements doivent être rattachés au même Tenant.
Enfin, la procédure présente deux contraintes à ne pas négliger :
Un travail important d’analyse doit ainsi être effectué en amont du projet de migration cloud Azure tenant-to-tenant.
Tout d’abord, une analyse du besoin est nécessaire pour identifier dans quel cas on se trouve :
En cas de détachement/rattachement à une autre tenant, une analyse de l’existant et des objets qu’il faudra recréer dans le tenant Cible en prévision de la reconfiguration après migration sera nécessaire.
En cas de déplacement de ressources d’un abonnement vers un autre, il convient de procéder à une analyse détaillée des ressources de l’abonnement source :
Trois points clés devront également retenir notre attention :
| Nos réalisations | Retours d’expérience et impacts |
|---|---|
| Création d’un abonnement cible Pay-as-you-Go rattaché au tenant et déplacement de ressources depuis l’abonnement source vers l’abonnement cible (déplacement partiel pour pouvoir utiliser des réservations et répartir les coûts). | Déplacement en succès. Maitrise de l’environnement Azure (interne). Nombre de ressources raisonnable et pas de difficulté majeure ou de cas “complexes” nécessitant de “casser” des dépendances, de supprimer et recréer des ressources. |
| Création d’un abonnement Pay-As-You-Go intermédiaire rattaché au même tenant que l’abonnement CSP source et déplacement des ressources depuis l’abonnement source vers cet abonnement intermédiaire. Rattachement de cet abonnement à un tenant cible. Charge au client de faire le déplacement depuis cet abonnement intermédiaire vers son abonnement cible. | Bon déroulement de la partie à notre charge. Nombre de ressources relativement faible. Abonnement intermédiaire fourni au client avec l’environnement à l’exacte reproduction de l’environnement source. Difficultés mineures dues au monitoring en place nécessitant de la recréation. |
| Création d’un abonnement CSP cible chez nous et déplacement des ressources de l’abonnement source vers l’abonnement cible. | Déplacement en succès malgré un nombre de ressources assez important et une contrainte temporelle forte. Pas de contrainte de perte de service en raison de la période non travaillée où s’est déroulé l’opération. Difficulté technique assez forte en raison d’un nombre d’inconnues important au moment du déplacement. Nécessité de “casser” des dépendances, de supprimer et recréer des ressources, d’effectuer des reconfigurations et de faire des exports/imports de données de databases. Reconfiguration nécessaire et plutôt longue de certaines ressources réseaux. |
Collaboratif & usages
Collectivités
Microsoft 365
Teams
Microsoft 365 pour les Collectivités : Retour d'Expérience de Châteauroux Métropole
Collaboratif & usages
Toutes les organisations
Teams
Adieu Skype : La fin des "wizz" et des émojis dansants !
Cloud & infra
Toutes les organisations
Copilot
Microsoft 365
Partenaire
De VMware vers l'écosystème Microsoft : les clés pour faire le bon choix
Actualités Empower
Partenaire
Toutes les organisations
Copilot
Microsoft 365
Partenaire
L'IA générative au service de la Santé Publique
Do you have a question or a project?
