Comment migrer depuis Azure Lab Services : guide étape par étape

Azure Lab Services sera retiré le 28 juin 2027, et Microsoft a fermé les nouvelles inscriptions le 15 juillet 2024. Pour migrer, prenez deux décisions pour chaque lab : le reconstruire ou le migrer, et reconstruire ou migrer son image de VM personnalisée. Les images sont toujours déplacées en premier, car l’outil de migration de labs de CloudLabs associe chaque lab à son image migrée par son nom. Pour un ou deux labs simples, repartir de zéro est généralement plus rapide ; pour les environnements plus importants ou les images difficiles à reconstruire, migrez d’abord les images, puis les labs par lots. Testez chaque lab migré avant que quiconque n’y enseigne, basculez entre deux semestres plutôt qu’en cours de session, et menez un pilote au moins un semestre avant votre premier cours en production.

Ce qui remplace Azure Lab Services, et ce que « migration » signifie ici

Microsoft, dans son guide de retrait, cite ses propres services, Azure Virtual Desktop et Windows 365 Cloud PC, ainsi que des solutions de partenaires Azure, comme options de transition. CloudLabs de Spektra Systems fait également partie des solutions partenaires citées. Pour comparer les options, consultez Comparatif des alternatives à Azure Lab Services.

Il n’existe pas de mise à niveau sur place. Microsoft ne déplace pas vos labs vers une nouvelle version du service. Migrer signifie retirer vos labs et leurs images personnalisées d’Azure Lab Services et les reconstruire, ou les déplacer à l’aide d’outils, sur une autre plateforme.

La date limite détermine ce que vous conservez. Après le 28 juin 2027, vous perdez l’accès à vos comptes de lab, plans de lab et labs. Vous conservez en revanche l’accès à votre Azure Compute Gallery et aux images qui y sont enregistrées. Ces images peuvent rester disponibles pour une réutilisation ou une migration ultérieure, mais les labs Azure Lab Services eux-mêmes ne seront plus accessibles après le retrait. Pour le calendrier complet du retrait, consultez le calendrier de retrait d’Azure Lab Services.

Chemins de migration Azure Labs : quels labs et images reconstruire, et lesquels migrer

Toute migration Azure Labs se résume à deux choix par lab.

• D’abord, que faire du lab : l’environnement de cours avec ses paramètres, son planning et ses utilisateurs.
• Ensuite, que faire de son image personnalisée : le disque de VM que votre équipe a construit avec les logiciels du cours installés.

Pour chacun, soit vous repartez de zéro sur la nouvelle plateforme, soit vous migrez ce que vous avez.

	Repartir de zéro avec l’image	Migrer l’image
Repartir de zéro avec le lab	Chemin 1 : tout reconstruire. Idéal pour un ou deux labs simples, ou lorsque vous souhaitez une image de base plus récente.	Chemin 2 : migrer l’image, puis créer un nouveau lab dessus. Idéal lorsque l’image est difficile à reconstruire mais que les paramètres du lab sont simples.
Migrer le lab	Impossible pour les labs qui utilisent une image personnalisée. L’outil de migration de labs a besoin que l’image migrée existe au préalable.	Chemin 3 : migrer l’image, puis le lab. Idéal pour de nombreux labs, des images complexes ou des labs dont les utilisateurs doivent être déplacés avec eux.

Lorsque vous utilisez l’outil de migration de labs de CloudLabs, les labs qui utilisent des images personnalisées exigent que ces images soient migrées au préalable, car l’outil associe le lab à l’image migrée correspondante.

Les questions qui déterminent votre chemin

1. Images personnalisées. Pouvez-vous reconstruire l’image rapidement, ou cela demanderait-il des jours d’installations et de tests ? Reconstruisez les images simples ; migrez les images complexes.
2. Réseaux virtuels personnalisés. Vos labs se connectent-ils à votre propre réseau, par exemple à un serveur de licences ou à des ressources du campus ? Si oui, un nouveau réseau virtuel et son peering doivent exister sur la nouvelle plateforme avant de créer ou de migrer le moindre lab.
3. Nombre de labs. Avec un ou deux labs, les créer de zéro est généralement plus rapide. Avec beaucoup, l’outil de migration vous aide à les déplacer par lots.
4. Utilisateurs. Êtes-vous à l’aise avec l’idée d’ajouter ou d’importer les utilisateurs après le déplacement ? Si vous préférez emporter la liste des utilisateurs, migrez le lab.

Existe-t-il un outil de migration ? Microsoft n’en fournit pas. Son guide indique que des partenaires pourraient fournir des outils pour migrer les labs automatiquement, et c’est le cas de CloudLabs : un script de migration d’images et un outil de migration de labs, présentés dans les deux sections suivantes.

Quand repartir de zéro est le meilleur choix. Microsoft note qu’il est souvent plus efficace de créer de nouveaux labs que de déplacer les anciens. C’est vrai lorsque vous n’avez que quelques labs, lorsque vos images méritent une mise à niveau (par exemple vers des VM Generation 2), ou lorsque vous prévoyez de toute façon de repenser le lab.

Comment migrer les images de VM personnalisées

Si l’image dont vous avez besoin n’existe qu’au sein d’Azure Lab Services, exportez-la d’abord vers une Azure Compute Gallery ; le script de migration d’images de CloudLabs fonctionne avec les images stockées dans une Azure Compute Gallery. Vous en avez besoin pour le chemin 2 (migrer l’image, puis créer un nouveau lab) et le chemin 3 (migrer l’image, puis le lab) : chaque fois qu’une image est trop complexe à reconstruire, ou qu’un lab utilisant cette image va être migré.

Avant de commencer

Vous avez besoin de deux ensembles d’accès.

• Côté Azure : le rôle Contributor (ou supérieur) sur le groupe de ressources ou l’abonnement qui contient la compute gallery. Un rôle personnalisé convient également s’il dispose d’un accès en lecture plus l’autorisation de créer des disques managés.
• Côté CloudLabs : un compte administrateur sur le portail CloudLabs, plus cinq valeurs fournies par l’équipe CloudLabs : groupe de ressources, ID de tenant, ID d’abonnement, ID d’application et secret d’application. En pratique, la migration d’images commence par une prise de contact avec CloudLabs.

Depuis le portail Azure, notez les noms des définitions d’image, le nom de la compute gallery, son groupe de ressources et l’ID d’abonnement.

Exécuter le script

1. Installez le module Azure PowerShell : Install-Module Az

2. Ouvrez PowerShell ISE en tant qu’administrateur.

3. Téléchargez le script, MigrateVMImagestoCloudLabs.ps1 :

   Invoke-WebRequest -Uri https://cloudlabs.ai/alb-imagemigration-script -OutFile C:\MigrateVMImagestoCloudLabs.ps1

4. Connectez-vous à votre environnement Azure source avec Connect-AzAccount, en utilisant le compte qui dispose des rôles ci-dessus.

5. Exécutez le script avec votre groupe de ressources source, le nom de la galerie, l’ID d’abonnement, une liste de noms d’images séparés par des virgules (-VMImagesList) et les cinq valeurs CloudLabs.

6. Gardez la fenêtre PowerShell ouverte. Le script vérifie la progression de la copie toutes les 2 minutes et vous indique quand elle est terminée. Fermer la fenêtre ou appuyer sur Ctrl + C interrompt la migration.

7. Pour migrer d’autres images, exécutez à nouveau Connect-AzAccount, puis relancez le script.

La copie s’exécute côté serveur dans Azure ; rien n’est téléchargé vers ou depuis votre ordinateur. La durée dépend de la taille et du nombre de disques ; prévoyez-la plutôt que d’attendre une durée fixe.

Ce que vous obtenez

• Une nouvelle galerie dans CloudLabs, nommée d’après votre galerie source avec le suffixe « migrated », contenant les images copiées. Vos images d’origine restent là où elles sont.
• Les disques temporaires que le script crée dans votre groupe de ressources sont supprimés automatiquement à la fin.
• Pour utiliser les images, allez dans Manage VM Lab > Settings > Custom Images, ajoutez la galerie migrée, ouvrez Manage Images et sélectionnez Sync Image.

Si une image échoue, le script écrit un fichier journal (CloudLabsVMImageMigration_ScriptLog) dans le dossier depuis lequel vous l’avez exécuté ; envoyez-le à l’équipe CloudLabs. Les images Confidential VM ne sont pas prises en charge.

Vérifiez vos images avant de vous y fier

Ne partez pas du principe que chaque image fonctionne telle quelle sur la nouvelle plateforme. Microsoft note qu’Azure Lab Services n’exporte que des images spécialisées, et suggère de recréer une image si vous passez à des VM Generation 2 ou si vous avez besoin d’une image généralisée. Testez chaque image migrée dans un lab pilote avant qu’un cours n’en dépende.

Le dépôt de scripts de retrait de Microsoft sur GitHub sert à supprimer les ressources Azure Lab Services inutilisées, pas à les migrer.

Comment migrer les labs par lots

Une fois vos images dans CloudLabs, l’outil de migration de labs recrée vos labs à partir des comptes de lab ou des plans de lab Azure Lab Services, par lots, sur les images migrées. L’ordre ne change jamais : d’abord les images, puis les labs, puis la vérification.

L’ordre des opérations

1. Configurez le réseau, si vos labs en ont besoin. Les labs qui se connectent à votre propre réseau ont besoin d’un nouveau réseau virtuel dans CloudLabs, en peering avec le vôtre, avant tout déplacement de lab. Vous transmettez le nom de ce réseau à l’outil de migration de labs lorsque vous l’exécutez.
2. Migrez les images dont dépendent les labs, comme décrit ci-dessus.
3. Exécutez l’outil de migration de labs sur vos comptes de lab ou plans de lab. Il recherche l’image de chaque lab par son nom dans la galerie migrée et recrée le lab dessus.
4. Vérifiez chaque lab avant que quiconque n’y enseigne (voir la liste de contrôle de la section suivante).

Les utilisateurs sont facultatifs. Vous pouvez migrer la liste des utilisateurs de chaque lab avec celui-ci, ou laisser les utilisateurs de côté et les ajouter ou les importer ensuite. Repartir sur une base propre est souvent plus simple si vos listes d’étudiants changent de toute façon à chaque semestre.

Ce qui change de nom, pas de fonction

Quelques concepts d’Azure Lab Services sont repris sous de nouveaux noms. Les connaître avant votre première connexion vous évite de longues recherches.

Dans Azure Lab Services	Dans CloudLabs VM Labs
Plans de lab et comptes de lab	Global Lab Settings au niveau du tenant : un seul endroit pour les paramètres autrefois répartis entre plusieurs entités
Pool de VM	Lab Instances : les labs se déploient à la demande lorsque les apprenants les demandent, et sont gérés depuis la page Lab Instances
Heures de lab par utilisateur	Restrict VM Uptime : un quota facultatif par utilisateur qui inclut les événements planifiés
Liens de réinitialisation de mot de passe	Mots de passe uniques générés aléatoirement pour chaque utilisateur, distribués directement

Les plannings récurrents de démarrage et d’arrêt sont disponibles dans VM Labs, et les labs se connectent à votre LMS existant via LTI 1.1 et LTI 1.3.

Ce qui est repris, et ce qu’il faut vérifier

L’outil de migration reprend pour chaque lab le titre, la date d’expiration, les paramètres d’arrêt en cas d’inactivité, l’image, la région et la taille de VM. La reprise des affectations d’étudiants, des plannings et des quotas d’utilisation n’est pas confirmée ; vérifiez donc chaque lab migré et reconfigurez-les si nécessaire.

Que migre réellement l’outil de migration CloudLabs ?

Voici la liste des éléments que l’outil de migration reprend :

Élément Azure Lab Services	Comportement de la migration
Lab	Un nouveau lab est créé dans CloudLabs
Image personnalisée	À migrer séparément au préalable
Titre du lab	Migré
Date d’expiration	Migrée
Arrêt en cas d’inactivité	Migré
Taille de VM/SKU	Migrée/mappée
Région	Migrée
Liste des utilisateurs	Facultatif

Pour un détail complet des concepts renommés, consultez CloudLabs pour les utilisateurs d’Azure Lab Services.

Avant la bascule : capacité, vérification et pilote

Une migration n’est pas terminée lorsque les labs ont été déplacés. Elle est terminée lorsque vous les avez vérifiés, pilotés et que vous vous êtes assuré de disposer d’une capacité Azure suffisante pour les exécuter. Faites les trois avant de retirer Azure Lab Services.

Demandez de la capacité tôt

Les limites de cœurs de votre abonnement Azure ne peuvent pas être transférées d’Azure Lab Services vers une nouvelle plateforme. Les cœurs pour la nouvelle configuration doivent être demandés à nouveau. Microsoft conseille de les demander le plus tôt possible, par petits incréments plutôt qu’en une seule grosse demande, et de rester flexible sur la région.

Vous aurez peut-être besoin de moins de cœurs qu’avant. Microsoft suggère de fonder la demande sur l’utilisation réelle des labs, et les plateformes qui partagent des VM multi-sessions ou déploient les labs à la demande peuvent faire tourner les mêmes cours avec moins de capacité.

Vérifiez chaque lab migré

• Toutes les images de VM migrées et visibles dans la galerie d’images CloudLabs
• Chaque lab recréé à partir de son image migrée, ordre « images d’abord » confirmé
• Titres de lab présents, avec date d’expiration et paramètres d’arrêt en cas d’inactivité corrects
• Région Azure et taille de VM correctes sur chaque modèle de lab
• Listes d’utilisateurs complètes (si vous avez migré les utilisateurs) et accès fonctionnel

Invitez ensuite un ou deux utilisateurs test dans chaque lab avant de l’ouvrir à une classe entière.

Validez le pilote

Un pilote est un vrai cours donné sur la nouvelle plateforme avec un petit groupe. Il est réussi lorsque :

• Les formateurs ont testé VM Shadow lors d’une session en direct
• Les étudiants ont testé l’accès via navigateur de bout en bout
• L’intégration LMS/LTI fonctionne pour chaque cours

Ce n’est qu’alors que vous planifiez la bascule en production, entre deux semestres, avec le corps enseignant et l’équipe informatique formés et un circuit d’escalade du support confirmé pour la semaine de mise en service.

Remonter depuis l’automne 2027 : un calendrier de migration pour une petite équipe informatique

La plupart des établissements qui quittent Azure Lab Services ont une à trois personnes pour mener toute la migration, en plus de tout le reste. Pour que cela reste gérable, il faut remonter à partir de la date qui ne peut pas bouger, le 28 juin 2027, et à partir du semestre que vous voulez ouvrir sur la nouvelle plateforme.

Quand	Que faire
De maintenant à décembre 2026	Inventoriez les labs et les images, choisissez votre chemin pour chaque lab et déposez la demande de budget. Vérifiez dès maintenant le cycle budgétaire de votre établissement ; l’approbation d’une nouvelle plateforme peut prendre des mois.
Semestre de printemps 2027	Pilotez un ou deux vrais cours sur la nouvelle plateforme. Migrez les images et demandez les cœurs en parallèle.
Entre les semestres de printemps et d’été	Basculez les labs de production par vagues, après vérification et formation des formateurs.
28 juin 2027	Azure Lab Services est retiré. Tout lab encore présent devient inaccessible.
Automne 2027	Les sections ouvrent sur la nouvelle plateforme, avec les enseignements du pilote déjà intégrés.

La durée du travail technique dépend du nombre de labs et d’images dont vous disposez et de leur complexité. Il n’y a pas de chiffre fixe, et c’est précisément pour cela que le pilote a besoin d’un semestre complet.

Migrez par vagues, pas tout d’un coup

À éviter : basculer en cours de session, lancer une migration majeure juste avant le début du semestre, garder vos images les plus complexes pour la dernière vague, former les formateurs après le déplacement, et découvrir les problèmes d’intégration en production.

À viser : une évaluation précoce, un pilote avant la production, une migration entre deux semestres, des vagues contrôlées et une vérification avant que les apprenants n’aient accès.

Risques d’une migration précipitée vs. planifier dès maintenant

Lorsque la migration est précipitée, la préparation des formateurs, les vérifications du LMS et la planification des coûts se retrouvent toutes comprimées dans une fenêtre beaucoup plus étroite.

Risque	Dans une migration précipitée	Impact sur les étudiants et les formateurs	Comment la planification aide
Perturbation opérationnelle	La migration chevauche des semestres en cours.	Accès aux labs retardé, sessions lentes ou ateliers interrompus.	Recréez les labs tôt, testez-les et déplacez les cours progressivement en fonction du calendrier académique.
Formateurs non préparés	Les formateurs découvrent de nouveaux outils sans temps de préparation.	Les sessions se déroulent moins bien et la qualité de l’enseignement en pâtit.	Les formateurs prennent en main la plateforme lors de sessions pilotes avant le déploiement.
Problèmes d’intégration LMS	Les liens de lancement des labs peuvent se comporter différemment.	Liens cassés, problèmes de connexion ou accès retardé.	Passez en revue les intégrations LMS avant la migration finale.
Coûts cloud inattendus	Les paramètres d’utilisation et les limites de ressources sont mal configurés.	Utilisation d’Azure plus élevée et coûts difficiles à prévoir.	Analysez les habitudes d’utilisation et ajustez les paramètres des labs avant la migration.

Que peuvent faire les équipes pendant une migration en parallèle ?

CloudLabs VM Labs prend en charge une migration en parallèle : Azure Lab Services et VM Labs fonctionnent côte à côte pendant que vous déplacez les cours un par un. Pendant cette période, votre équipe peut :

• Recréer les environnements de lab existants dans VM Labs
• Tester les labs migrés avec les formateurs avant que les étudiants ne les voient
• Mener des sessions pilotes avec un petit groupe de vrais étudiants
• Passer en revue l’intégration LMS et les liens de lancement des labs cours par cours

Pendant ce temps, les cours en cours continuent de fonctionner sur Azure Lab Services.

Pourquoi la migration en parallèle fonctionne

• Les cours actifs ne sont pas perturbés. Les étudiants des cours de ce semestre continuent d’utiliser leurs labs existants jusqu’à ce que leur cours soit déplacé.
• Le corps enseignant a le temps d’apprendre la plateforme. Les formateurs essaient VM Labs lors de sessions pilotes avant d’y enseigner.
• Les étudiants conservent un accès ininterrompu. Il n’y a aucune interruption entre la disparition de l’ancien lab et la disponibilité du nouveau.
• Vous maîtrisez le calendrier. Chaque cours est déplacé lorsqu’il est prêt et vérifié, et non tous en même temps à l’approche de la date limite.

Commencez par une preuve de concept gratuite

CloudLabs propose une preuve de concept gratuite et accompagnée aux clients d’Azure Lab Services. Les clients éligibles peuvent obtenir jusqu’à 2 000 $ de crédits Azure offerts par CloudLabs pour soutenir leur transition depuis Azure Lab Services.

Des experts examinent votre environnement, vos labs et vos images actuels, élaborent un plan et un calendrier de migration, et accompagnent un pilote avec vos propres cours : les formateurs testent VM Shadow, les étudiants testent l’accès via navigateur, et votre équipe vérifie l’intégration LMS de bout en bout.

• Testez la plateforme avec des utilisateurs sélectionnés. Organisez des sessions de lab contrôlées, menez des tests pilotes en direct et recueillez des retours exploitables.
• Bénéficiez d’un support managé de bout en bout. Configuration des labs, gestion de la configuration, scripts d’automatisation et résolution prioritaire des incidents inclus.
• Découvrez des calendriers de migration clairs. Les experts CloudLabs analyseront votre configuration actuelle de labs et partageront des estimations de délais de transition.
• Effectuez des vérifications de compatibilité approfondies avec votre LMS existant. Vérifiez l’intégration entre CloudLabs VM Labs et votre écosystème d’apprentissage existant.

Lancez une preuve de concept (POC) gratuite et évaluez la plateforme dans votre environnement réel.

Obtenez le plan de migration complet

Le Azure Lab Services Migration Playbook (édition 2026) couvre tout ce que contient ce guide de manière plus approfondie, y compris une liste de contrôle de préparation, le plan de migration complet en 9 phases et la liste de contrôle pré-bascule, dans un format que vous pouvez partager avec votre direction.

Téléchargez le Azure Lab Services Migration Playbook (édition 2026)

Pour plus de guides et d’outils, consultez CloudLabs VM Labs et Alternatives à Azure Lab Services et guide de migration.

Questions fréquentes

Existe-t-il un outil de migration officiel de Microsoft ?

Non. Microsoft publie des scripts de nettoyage, pas un outil de migration. Le guide de retrait de Microsoft indique que des partenaires pourraient fournir des outils pour migrer les labs automatiquement. CloudLabs fournit un script de migration d'images et un outil de migration de labs pour passer d'Azure Lab Services à CloudLabs VM Labs.

Puis-je conserver mes images après le retrait ?

Oui. Les images enregistrées dans votre Azure Compute Gallery restent accessibles après le 28 juin 2027. Les labs, les plans de lab et les comptes de lab, non.

Les limites de cœurs sont-elles transférées vers une nouvelle plateforme ?

Non. Les limites de cœurs de l'abonnement Azure ne peuvent pas être transférées depuis Azure Lab Services ; demandez donc les cœurs pour la nouvelle plateforme le plus tôt possible.

Combien de temps prend la migration des images ?

Cela dépend de la taille et du nombre de disques. Il n'y a pas de durée fixe ; effectuez donc une migration test d'une image pendant votre pilote pour l'estimer.

Dois-je migrer les utilisateurs avec mes labs ?

Non. La migration des utilisateurs est facultative. Vous pouvez déplacer la liste des utilisateurs d'un lab avec celui-ci, ou ajouter et importer les utilisateurs ensuite.