Migration vers le cloud : un plan application par application

Pourquoi tant de migrations dérapent

Une migration cloud échoue rarement à cause du fournisseur. Elle dérape parce que l’inventaire était incomplet, qu’une dépendance cachée (un partage de fichiers, un flux nocturne, une adresse IP codée en dur) a été découverte le jour de la bascule, ou parce que la fondation cible n’était pas prête et qu’on a ouvert des accès réseau « temporaires » qui sont restés.

Les autres causes fréquentes sont connues : une estimation de coûts faite sur une grille tarifaire plutôt que sur une architecture précise, une période de double run sous-estimée, des équipes applicatives sollicitées au dernier moment, et pas de plan de retour arrière écrit.

Notre approche vise à traiter ces risques avant qu’ils ne coûtent : on découvre, on décide, on répète, puis on bascule. Nous accompagnons des entreprises de la métropole lilloise et de toute la France, sur AWS comme sur Azure.

Notre démarche de migration

1. Découverte et inventaire

Nous recensons les serveurs, bases de données, applications et flux, avec leurs dépendances, leurs fenêtres de maintenance et leurs propriétaires métier. Les outils de découverte des fournisseurs aident à collecter les données techniques ; les entretiens avec les équipes apportent ce que les outils ne voient pas : criticité, contraintes de disponibilité, projets en cours.

2. Une stratégie par application, avec la méthode des 7R

Chaque application reçoit une stratégie parmi les sept options du modèle 7R, décrit dans la documentation de migration d’AWS. Le tableau ci-dessous résume quand nous les retenons ; le détail de la méthode est dans notre article sur la stratégie de migration vers le cloud et les 7R.

Stratégie	Quand nous la retenons
Retire (décommissionner)	Application peu ou plus utilisée : la migrer serait payer pour rien.
Retain (conserver)	Contrainte forte de latence, de licence ou de calendrier : l’application reste en place, pour l’instant.
Rehost (rehéberger)	Délai serré, application stable : on déplace les machines telles quelles, on optimise ensuite.
Relocate (relocaliser)	Parc VMware à sortir rapidement vers une offre VMware hébergée dans le cloud.
Replatform (replateformer)	Gains rapides à faible effort, par exemple une base de données vers un service managé.
Repurchase (racheter)	Un logiciel SaaS couvre le besoin mieux qu’une application maintenue en interne.
Refactor (réarchitecturer)	Application stratégique dont l’évolution justifie une refonte vers des services cloud natifs.

3. Préparation de la fondation cible

Avant la première vague, l’environnement d’accueil doit être prêt : organisation des comptes AWS ou des abonnements Azure, réseau et connectivité avec le site existant (VPN ou lien dédié), identités et droits, journalisation, sauvegardes, budgets et alertes. Le tout décrit en code. Cette fondation est détaillée sur nos pages AWS et Azure.

4. Migration par vagues

Les applications sont regroupées en lots cohérents selon leurs dépendances : ce qui communique beaucoup migre ensemble. La première vague porte volontairement sur des applications peu critiques, pour éprouver les outils, les procédures et la coordination. Les suivantes montent en criticité.

Chaque vague suit le même déroulé : réplication des données, tests fonctionnels et de performance dans le cloud par les équipes métier, répétition de la bascule, puis bascule réelle dans une fenêtre convenue.

5. Bascule et plan de retour arrière

Pour chaque vague, un plan de retour arrière est écrit et testé avant la bascule : critères objectifs de déclenchement, personne qui décide, étapes pour revenir à la source, délai maximum pour le faire. L’environnement d’origine reste disponible pendant la période de stabilisation. Une bascule sans retour arrière possible est un pari, pas un plan.

6. Stabilisation et optimisation

Après la bascule viennent l’ajustement des tailles d’instances sur les mesures réelles, la mise en place des engagements tarifaires quand l’usage est stable, et le décommissionnement des anciennes ressources. C’est là que commence la démarche FinOps.

Migration on-premise et VMware vers le cloud

Les évolutions des licences VMware conduisent de nombreuses entreprises à réexaminer leur virtualisation. Trois voies se présentent, souvent combinées :

• Rester sur VMware, mais dans le cloud. AWS et Azure proposent chacun une offre permettant d’exécuter un environnement VMware sur leur infrastructure (Amazon Elastic VMware Service côté AWS, Azure VMware Solution côté Microsoft). C’est la voie la plus rapide pour libérer un datacenter, mais elle ne règle pas la question des licences à long terme : à vérifier selon votre contrat.
• Rehéberger les machines virtuelles sur des instances natives, avec les outils de réplication des fournisseurs (AWS Application Migration Service, Azure Migrate). On quitte l’hyperviseur, mais on garde des serveurs à administrer.
• Moderniser les applications qui le justifient vers des services managés : bases de données, conteneurs, stockage objet.

Le choix se fait par application, en croisant licences, délais et effort acceptable. Une sortie de VMware est aussi l’occasion de décommissionner ce qui ne sert plus.

Les livrables

• Inventaire applicatif et cartographie des dépendances.
• Dossier de décisions : stratégie retenue par application, avec ses raisons.
• Estimation des coûts cibles sur l’architecture choisie, double run compris.
• Plan de vagues et calendrier de bascule validés avec le métier.
• Fondation cible en Infrastructure as Code (Terraform ou OpenTofu).
• Runbooks de bascule et plans de retour arrière par vague.
• Documentation d’exploitation et sessions de transfert de compétences.

Les pièges à éviter

• Migrer sans décommissionner. Payer à la fois l’ancien et le nouvel environnement plus longtemps que prévu efface vite l’intérêt économique.
• Tout réarchitecturer d’un coup. La refonte se justifie pour quelques applications stratégiques, pas pour tout le parc.
• Tout rehéberger sans revoir les tailles. Reproduire des serveurs dimensionnés pour un pic d’il y a cinq ans fait exploser la facture.
• Ouvrir le réseau « en attendant ». Les règles temporaires deviennent permanentes. La sécurité se pose avant la première vague.
• Oublier les licences. Windows Server, SQL Server, Oracle : les conditions d’utilisation dans le cloud changent l’équation et doivent être vérifiées tôt.

Comment nous travaillons avec vos équipes

Nous ne migrons pas à votre place dans une boîte noire. Vos équipes infrastructure et applicatives participent aux décisions, relisent le code, exécutent les répétitions à nos côtés. Chaque vague renforce leur autonomie : à la dernière, elles doivent pouvoir piloter une bascule seules. Ce fonctionnement suit notre méthode Cadrer, Construire, Industrialiser, Améliorer, présentée sur la page conseil cloud AWS et Azure.

Pour qui, et quand nous appeler

• Un contrat d’hébergement ou de datacenter arrive à échéance.
• Le renouvellement de votre infrastructure VMware ou de votre matériel se pose.
• Une première migration a été faite en urgence et l’environnement cloud mérite d’être repris.
• Vous voulez un avis indépendant sur un plan de migration proposé par un autre prestataire.

Si vous êtes dans l’une de ces situations, réservez un échange de 15 minutes pour en parler.

[ VOS QUESTIONS ]

Questions fréquentes

Comment migrer vers le cloud ?

En commençant par un inventaire des applications et de leurs dépendances, puis en choisissant une stratégie par application. On prépare ensuite la fondation cible (comptes ou abonnements, réseau, identités, sécurité), avant de migrer par vagues, chacune répétée et dotée d’un plan de retour arrière.

Combien coûte une migration cloud ?

Le coût dépend du nombre d’applications, de la stratégie retenue pour chacune et de la complexité des dépendances : nous ne donnons pas de chiffre avant l’inventaire. Il faut aussi compter une période de double run, où l’ancien et le nouvel environnement tournent en parallèle. Les fournisseurs proposent parfois des programmes d’accompagnement financier, dont l’éligibilité est à vérifier au cas par cas.

Pourquoi migrer vers le cloud ?

Les motifs les plus solides sont concrets : fin de contrat d’hébergement, renouvellement de matériel, évolution des licences de virtualisation, besoin de services managés ou d’environnements créés à la demande. Si aucun motif clair n’existe, une migration peut coûter plus qu’elle ne rapporte, et nous vous le dirons.

Comment migrer des machines VMware vers le cloud ?

Plusieurs voies existent : rehéberger les machines virtuelles avec les outils de réplication des fournisseurs, utiliser une offre VMware hébergée chez AWS ou Azure pour gagner du temps, ou moderniser vers des services managés. Le choix se fait application par application, selon les licences, les délais et l’effort acceptable.

Combien de temps dure une migration cloud ?

Cela va de quelques semaines pour un petit périmètre à plusieurs mois pour un datacenter complet. La durée dépend surtout des dépendances entre applications, des fenêtres de bascule acceptables pour le métier et de la disponibilité des équipes applicatives.