Azure Migrate : l’expérience classique ferme le 30 septembre 2026
Les organisations qui migrent des machines VMware ou physiques vers Azure par réplication avec agent ont jusqu’au 30 septembre 2026 pour terminer. Après cette date, l’expérience classique d’Azure Migrate est retirée : plus de migration, plus de bascule, et même plus de visibilité sur les machines restées dessus depuis le portail Azure.
Deux des trois dates du calendrier sont déjà passées, et c’est ce qui rend la situation moins confortable qu’elle n’en a l’air.
Le calendrier, et ce qui est déjà derrière nous
| Date | Ce qui s’arrête |
|---|---|
| 31 mars 2026 | Plus aucune nouvelle réplication ne peut être démarrée depuis l’appliance classique. Les réplications existantes continuent. |
| 31 mai 2026 | La prise en charge de la réplication s’arrête sur l’expérience classique. Les migrations des réplications existantes restent possibles, mais on ne peut plus les modifier ni en démarrer de nouvelles. |
| 30 septembre 2026 | Retrait complet. Plus de vue, plus de gestion, plus aucune opération de réplication ou de migration sur ces machines depuis le portail. |
Une organisation qui a lancé sa réplication avant le 31 mars et qui n’a pas encore basculé est donc dans une fenêtre étroite : elle peut encore migrer, mais elle ne peut plus rien ajuster. Si la configuration de réplication ne convient pas, la seule sortie est de repasser par la nouvelle appliance.
Ce que remplace l’expérience simplifiée
L’expérience simplifiée n’est pas un habillage : c’est une pile de migration avec agent reconstruite pour les environnements physiques et VMware. Microsoft met en avant quatre différences qui comptent en exploitation.
L’appliance de réplication tourne sur Windows Server 2022, là où la version classique reposait sur une base plus ancienne. C’est le point qui débloque le reste.
La prise en charge des systèmes d’exploitation est élargie, notamment pour les distributions Linux récentes. Une matrice unifiée remplace les tableaux séparés — ce qui simplifie surtout la phase de vérification, avant même la migration.
Les mises à jour deviennent automatiques, pour l’agent de mobilité comme pour l’appliance. Sur la version classique, les deux composants se mettaient à jour à la main, et c’est typiquement ce qu’on oublie sur une appliance posée pour un projet de trois mois.
L’intégration demande environ moitié moins d’étapes de configuration. Sur un projet à quelques dizaines de machines, ce n’est pas anecdotique.
Un point à ne pas manquer : les nouvelles fonctionnalités, les correctifs de sécurité et la prise en charge de nouvelles distributions Linux n’arrivent que sur l’expérience simplifiée. La version classique est figée.
Qui est réellement concerné
Pas tout le monde, et c’est utile de le préciser avant de déclencher une alerte inutile.
La réplication avec agent concerne les serveurs physiques, les machines virtuelles VMware migrées en mode agent, et les machines d’autres environnements traitées comme physiques. La migration VMware sans agent, elle, utilise la même appliance que la découverte et l’évaluation, et ne dépend pas de l’appliance de réplication classique. La migration Hyper-V passe par des agents installés sur l’hôte, et suit un autre chemin.
Autrement dit : si votre projet de migration utilise l’appliance de réplication, vous êtes concerné. S’il repose sur la découverte sans agent, vous ne l’êtes pas.
La question à poser à l’équipe qui exploite le projet est donc précise : quelle appliance est déployée, et quelles machines répliquent encore à travers elle. Une réponse floue est déjà une réponse.
Ce qu’il faut faire, selon la situation
Une migration terminée, l’appliance encore en place. Rien d’urgent côté Azure, mais l’appliance est une machine qui consomme des ressources et porte des identifiants. Elle se retire.
Une réplication en cours, bascule prévue avant fin septembre. C’est jouable en l’état, sans transition. Mais figez la configuration : elle ne peut plus être modifiée, et découvrir le besoin d’un ajustement en septembre laisse peu de marge.
Une réplication en cours, bascule après septembre. Il faut transiter vers l’appliance simplifiée. Ce n’est pas une mise à jour de l’existant : c’est une nouvelle appliance à déployer, et des réplications à relancer.
Une migration pas encore commencée. La question ne se pose pas : l’appliance classique n’accepte plus de nouvelle réplication depuis mars.
Dans les trois derniers cas, la vraie contrainte n’est pas technique, elle est calendaire. Une réplication initiale sur un volume conséquent prend des jours, la validation applicative en prend d’autres, et les fenêtres de bascule se négocient avec les métiers. Compter en semaines, pas en jours.
Ce type d’arbitrage entre une plateforme figée et une plateforme qui évolue revient régulièrement dans les projets d’infrastructure ; nous l’abordons aussi sous l’angle de l’hébergement local connecté dans notre article sur Azure Local.
Les sources Microsoft
- Expérience simplifiée pour Azure Migrate — Microsoft Learn
- À propos d’Azure Migrate — Microsoft Learn
- Migrer des machines virtuelles VMware avec la migration basée sur un agent — Microsoft Learn
- Matrice de prise en charge Azure Migrate — Microsoft Learn
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 149, tous en accès libre.