Entrazure
Ce que nous construisons
Nous déplaçons des charges de travail depuis VMware, depuis du matériel sur site vieillissant et depuis d’autres plateformes infonuagiques vers Azure. Le plan part toujours de dépendances mesurées, jamais d’un chiffrier d’actifs : le chiffrier se trompe systématiquement sur ce qui parle à quoi.
Une cartographie des dépendances. L’appliance Azure Migrate est déployée chez vous et la découverte sans agent tourne au moins deux semaines, assez longtemps pour attraper le traitement de fin de mois et le rapport que personne n’a documenté. Le résultat est fondé sur le trafic réel : quel serveur appelle quel port, à quelle fréquence, et ce qui casse si ça s’arrête.
Un découpage en vagues. Les charges sont regroupées par grappe de dépendances, pas par nom d’hôte ni par équipe. Une vague, c’est ce qui se déplace dans une seule fenêtre de maintenance et dont on revient en arrière en moins d’une heure : en pratique, 8 à 25 serveurs, ou une application avec sa base et ses intégrations.
Le dimensionnement et le coût avant le premier déplacement. Azure Migrate dimensionne à partir du CPU, de la mémoire et des IOPS observés, pas de la fiche technique achetée en 2019. Nous produisons le coût mensuel par vague, réservations, Azure Hybrid Benefit et licences SQL Server comprises, et nous vous montrons les vagues dont l’analyse de rentabilité est faible. Transporter tel quel un parc mal dimensionné vers Azure au prix courant, c’est la façon la plus répandue de conclure que l’infonuagique coûte cher.
La destination, construite d’abord. Les charges atterrissent dans un abonnement gouverné ou dans quelque chose que vous paierez pour défaire plus tard. Si la landing zone Azure n’existe pas, elle est livrée avant la première vague : groupes d’administration, Azure Policy, topologie réseau, identité, journalisation.
Les bases de données. SQL Server vers Azure SQL Managed Instance ou Azure SQL Database, avec l’évaluation de compatibilité faite avant le choix de la cible et non après. PostgreSQL et MySQL vers leurs équivalents gérés. La haute disponibilité et la reprise après sinistre se conçoivent à ce moment-là, pas en deuxième année.
La modernisation là où elle se rentabilise. La majorité des serveurs sont simplement réhébergés : c’est rapide, réversible et facile à raisonner. Quelques charges méritent d’être refaites au passage, un palier web vers App Service, un service conteneurisé vers Container Apps, une plateforme réellement distribuée vers Azure Kubernetes Service. Nous disons franchement quand Kubernetes n’est pas la réponse.
Ce qui reste sur site. Azure Arc ramène les serveurs, instances SQL et clusters qui ne bougent pas sous les mêmes politiques, la même supervision et la même gestion des correctifs.
La sortie de VMware, concrètement
Le repackaging de VMware par Broadcom en abonnements a changé le calcul pour beaucoup de parcs, et c’est presque toujours la date de renouvellement qui déclenche la discussion. Cette échéance est le vrai risque du projet. Une soumission de renouvellement reçue huit semaines avant l’expiration ne laisse pas le temps d’une migration réfléchie, et une migration précipitée coûte plus cher qu’un renouvellement de transition.
Nous établissons donc l’échéance réelle et nous remontons le calendrier depuis cette date. Si le calendrier ne tient pas, nous le disons et nous vous aidons à négocier une année de pont, puis à migrer correctement. S’il tient, la découverte commence tout de suite : les deux semaines d’observation sont un plancher, ajouter des ressources ne les raccourcit pas.
La partie technique est volontairement banale : découverte sans agent, réplication par Azure Migrate, un basculement de test répété par vague, puis la bascule réelle. La différence se joue sur le séquencement des grappes, sur l’arithmétique des licences (Azure Hybrid Benefit change sensiblement le résultat sur un parc Windows et SQL) et sur un décommissionnement qui met vraiment fin au contrat, au lieu de laisser quatre hôtes allumés par précaution.
Comment le mandat se déroule
Semaines 1 à 3, découverte. Appliance déployée, découverte en cours, propriétaires d’applications rencontrés. Nous produisons la cartographie, l’inventaire applicatif avec un propriétaire nommé par application, et la première version du plan de vagues. Toute application sans propriétaire est signalée : c’est soit une candidate au retrait, soit un incident qui attend une migration pour se déclencher.
Semaines 4 et 5, conception et analyse de rentabilité. Architecture cible, dimensionnement, coût d’exploitation par vague, chemin réseau, modèle d’identité, interruption prévue par application. Le livrable se présente tel quel à un comité directeur.
Semaines 6 et 7, vague pilote. Une vague à faible risque, de bout en bout. Le pilote teste le processus, pas la charge de travail. Le retour arrière est répété pour vrai et la procédure est corrigée avant d’engager le reste du parc.
À partir de la semaine 8, vagues de production. Une vague toutes les deux ou trois semaines, chacune avec sa procédure écrite, sa liste de validation signée par le propriétaire applicatif, son retour arrière et sa revue post-bascule.
Clôture, décommissionnement. La partie qu’on abandonne quand un projet déborde, et la partie qui le rentabilise. Nous produisons la liste de décommissionnement, confirmons par 30 jours de supervision que chaque source est réellement inutilisée, et restons impliqués jusqu’à l’annulation effective des licences et des contrats d’entretien.
Ce que vous gardez
- La cartographie des dépendances et l’inventaire applicatif, avec un propriétaire par application.
- Le plan de vagues, y compris les vagues que nous avons déconseillées et pourquoi.
- L’infrastructure en code de tout ce qui a été construit dans Azure, dans votre organisation Git.
- Le modèle de coût par vague, avec les hypothèses visibles et modifiables.
- Une procédure de bascule et une procédure de retour arrière par vague, déjà répétées.
- La liste de décommissionnement et les contrats qu’elle permet d’annuler.
- La liste écrite des charges laissées sur site, avec la condition qui changerait la décision.
Pour qui c’est
Des organisations de 50 à 5 000 personnes exploitant 50 à 1 000 charges sur VMware, sur du matériel physique ou en colocation, avec un renouvellement, une fin de bail, une sortie de centre de données ou une acquisition qui impose la date. Le mandat se combine bien avec un chantier d’infrastructure en code : la migration est le moment où le parc devient reproductible, ou reste bricolé à la main. Les environnements réglementés sont notre quotidien, voyez les contraintes cliniques en santé et les exigences de résidence dans architecture de conformité.
Pour qui ce n’est pas
Si vous voulez tout déplacer tel quel, le plus vite possible, sans phase de découverte, nous ne sommes pas la bonne firme. Ce projet se vend moins cher ailleurs et produit une facture Azure environ deux fois trop élevée, plus un parc que personne ne gouverne.
Si vos applications sont sans documentation, sans propriétaire et sans support de leur éditeur, la migration n’est pas votre premier problème. Réglez la question de la propriété d’abord, ou acceptez une découverte plus longue que ce que vous vouliez payer.
Et si vous migrez surtout pour réduire les coûts sans rien changer à la façon dont vous exploitez le parc, lisez d’abord Azure infogéré et FinOps : les économies viennent de la discipline d’exploitation après le déplacement, pas du déplacement.
Pages liées
- Landing zone Azure, la destination gouvernée livrée avant la première vague.
- Azure infogéré et FinOps, qui exploite le parc une fois migré.
- Cybersécurité et Entra ID, le chantier d’identité qu’une migration révèle toujours.
- Tous les services Azure, le catalogue complet des mandats.
Questions fréquentes
Combien de temps prend une migration ?
La découverte prend trois semaines, parce que les données de dépendances n’ont aucune valeur avant deux semaines d’observation continue. Ensuite, comptez une vague de production toutes les deux ou trois semaines. Un parc de 120 serveurs prend généralement cinq à sept mois, décommissionnement inclus.
Peut-on migrer sans interruption de service ?
Pour certaines charges, oui. Un palier web sans état ou une base en cluster se déplacent en quelques minutes d’interruption. Un serveur applicatif monolithique avec une seule instance SQL, non, et prétendre le contraire est exactement ce qui fait dérailler une migration à 3 h du matin. L’interruption prévue est annoncée par vague, avant l’approbation de la vague.
Que se passe-t-il si une vague échoue ?
On revient en arrière. Les systèmes sources restent éteints mais intacts pendant au moins 14 jours après chaque bascule, la durée de vie DNS est abaissée avant la fenêtre pour qu’un retour se propage en minutes, et la procédure est répétée pendant la vague pilote plutôt qu’improvisée le jour venu.
Faut-il tout migrer ?
Non, et la plupart des parcs ne devraient pas. Certaines charges coûtent moins cher là où elles sont, d’autres arrivent en fin de vie et méritent d’être retirées plutôt que déplacées, d’autres encore dépendent d’un matériel qu’Azure ne remplacera pas. Azure Arc ramène ce qui reste sous les mêmes politiques et la même supervision, pour éviter d’exploiter deux modèles en parallèle pendant des années.
Les données restent-elles au Canada ?
Oui, si c’est l’exigence. La restriction de région est appliquée par Azure Policy au niveau des groupes d’administration avant le déplacement de la première charge : une vague ne peut donc pas atterrir par accident dans une région américaine. Le même mécanisme couvre les engagements de résidence pris envers vos propres clients.
Vendez-vous les abonnements Azure ?
Nous pouvons. Entrazure est CSP direct, donc les licences, le support et la facturation consolidée peuvent passer par nous. Ce n’est jamais une condition du mandat, et les honoraires de conseil sont chiffrés séparément des licences.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.