Migrer des centaines d'applications existantes sur VM vers AWS fonctionne quand on le mène comme une chaîne de production plutôt que comme des centaines de projets isolés : inventorier et classer chaque application, décider mise à niveau ou reconstruction application par application, et découper le parc en lots confiés à de petites équipes. Un squelette applicatif commun, des étapes de bascule et de retour arrière testées et des runbooks que n'importe quelle équipe peut suivre maintiennent une qualité constante à mesure que le volume augmente.
Commencez par un inventaire qui montre ce dont chaque application a vraiment besoin
Avant que quiconque touche à AWS, listez chaque application qui tourne sur les anciennes VM et notez les éléments qui déterminent l'effort de migration. Un tableur partagé suffit au début. L'essentiel est que chaque application ait une ligne, un responsable et les mêmes colonnes.
Classez ensuite chaque application dans un petit nombre de filières, par exemple mise à niveau, reconstruction et décommissionnement. Les équipes peuvent alors planifier par filière au lieu de débattre de chaque application en repartant de zéro.
- Version de l'environnement d'exécution et du framework, en signalant tout ce qui est en fin de vie
- Bases de données, partages de fichiers et tâches planifiées dont dépend l'application
- Intégrations entrantes et sortantes, y compris les noms d'hôtes et adresses IP codés en dur
- Méthode d'authentification et secrets éventuellement stockés sur la VM
- Responsable métier, niveau d'utilisation et fenêtre d'interruption acceptable
Décidez mise à niveau ou reconstruction application par application, pas une fois pour tout le programme
Aucune stratégie unique ne convient à des centaines d'applications. Certaines n'ont besoin que d'une mise à niveau du framework, d'une configuration externalisée et d'une nouvelle cible de déploiement. D'autres contiennent tant de code mort ou de structure enchevêtrée que les reconstruire sur une base saine est plus rapide que de les réparer.
Tranchez avec des critères écrits pour que des équipes différentes arrivent à la même réponse. Une règle utile : si installer l'application sur le squelette standard implique de toute façon de réécrire la plupart de ses contrôleurs et de son accès aux données, reconstruisez-la. Si la logique métier se transpose presque intacte, mettez-la à niveau.
Le programme de Crédit Agricole, qui a migré 600+ applications internes d'anciennes VM vers AWS, a utilisé les deux voies. Les applications ont été reconstruites sur le squelette CodeIgniter interne de la banque, certaines par mise à niveau, d'autres de zéro.
- Mettez à niveau quand le code est lisible, son comportement clair et l'écart de version du framework faible
- Reconstruisez quand la logique métier est mêlée à la présentation partout ou que l'application dépend de fonctionnalités du langage supprimées
- Décommissionnez quand l'utilisation est quasi nulle et que le responsable métier est d'accord : la migration la moins chère est celle que l'on ne fait pas
Découpez le parc en lots et confiez chaque lot à une seule équipe
À cette échelle, une équipe centrale unique devient le goulot d'étranglement. Un modèle par lots confie un ensemble d'applications liées à une petite équipe qui en est responsable de l'analyse à la bascule.
Regroupez les lots par dépendances communes, pas par ordre alphabétique. Les applications qui partagent une base de données ou s'appellent entre elles doivent migrer ensemble, sinon le même travail d'intégration se répète d'une équipe à l'autre.
Les lots rendent aussi l'avancement mesurable. Chaque équipe déclare les mêmes états pour chaque application, par exemple analysée, migrée, testée, basculée et décommissionnée, et le tableau de bord du programme est la somme de ces états. Le programme de Crédit Agricole fonctionnait ainsi, et SDK Enterprises a réalisé 50+ de ses migrations d'applications au sein de l'équipe du programme.
Construisez un squelette standard et faites-y atterrir chaque application
Un squelette applicatif standard est ce qui transforme des centaines de migrations en un processus reproductible. Il fige les décisions qui ne doivent pas être reprises pour chaque application : arborescence des répertoires, configuration par variables d'environnement, format des journaux, contrôles de santé, points d'accroche pour l'authentification et pipeline de déploiement.
Chaque application migrée ne diffère alors que par sa logique métier. Les relecteurs savent où regarder, les équipes d'exploitation obtiennent des journaux et des alarmes cohérents, et une correction du squelette profite à toutes les applications construites dessus.
Gardez le squelette petit et versionné. S'il devient un framework à part entière, les équipes commenceront à le contourner.
Planifiez la bascule et le retour arrière avant la première migration
Chaque application a besoin d'un plan de bascule qui précise comment le trafic est déplacé, comment les données sont déplacées et comment revenir en arrière. Décidez-en avant la migration de la première application. Improviser un retour arrière en plein incident, c'est ainsi que les programmes de migration perdent la confiance des métiers.
- Période de gel : convenez avec le responsable métier du moment où les modifications s'arrêtent sur l'ancienne VM
- Synchronisation des données : migrez les données à l'avance, puis effectuez une dernière synchronisation différentielle pendant la fenêtre de bascule
- Bascule du trafic : modifiez le DNS ou le routage du répartiteur de charge, avec des TTL DNS abaissés plusieurs jours à l'avance
- Tests de fumée : une courte vérification scriptée de la connexion, des écrans clés et des intégrations juste après la bascule
- Déclencheur de retour arrière : une personne nommée et des conditions écrites pour revenir en arrière
- Ancienne VM conservée : arrêtez-la mais ne la supprimez pas tant que l'application n'a pas tourné sans problème sur AWS pendant une période convenue
Rédigez des runbooks que n'importe quelle équipe peut suivre dès le premier jour
Un runbook est la checklist d'une opération reproductible : préparer une application, la basculer, revenir en arrière, décommissionner la VM. Rédigez chacun une fois, testez-le sur les premières applications, et mettez-le à jour chaque fois qu'une équipe est surprise.
Un bon runbook nomme des commandes, des responsables et des résultats attendus, pas des intentions. « Vérifier que l'application fonctionne » n'est pas une étape. « Se connecter avec l'utilisateur de test et confirmer que le tableau de bord charge les données du compte » en est une.
Les runbooks permettent aussi aux ingénieurs qui arrivent en cours de programme d'être rapidement productifs. Un spécialiste arrivant la sixième semaine doit pouvoir basculer une application en suivant les documents après une seule session en binôme.
La place d'une équipe externe dans une grande migration
Les grands programmes ont souvent besoin de capacité supplémentaire pour une période définie, sans céder le contrôle. Nous prenons en charge des lots de migration au sein de programmes plus larges, en travaillant avec le squelette, les runbooks et l'outillage du client, avec nos ingénieurs et des spécialistes indépendants sélectionnés, sous un seul contrat.
À retenir
- Inventoriez et classez chaque application avant d'en migrer une seule, pour pouvoir planifier le travail par filière.
- Choisissez mise à niveau, reconstruction ou décommissionnement application par application, avec des critères écrits que chaque équipe applique de la même façon.
- Découpez le parc en lots d'applications liées, chacun porté de bout en bout par une petite équipe.
- Un squelette applicatif petit et versionné rend des centaines de migrations cohérentes et faciles à relire.
- Ne basculez jamais une application sans chemin de retour arrière testé et sans l'ancienne VM encore disponible.
FAQ
Combien de temps faut-il pour migrer des centaines d'applications vers AWS ?
Cela dépend du nombre d'applications, de la part qui doit être reconstruite, du nombre d'équipes en parallèle et des fenêtres de bascule acceptées par les métiers. Estimez après la classification : chronométrez quelques applications de chaque filière, multipliez par la taille de chaque filière et divisez par la capacité des équipes.
Faut-il d'abord faire du lift and shift, puis moderniser plus tard ?
Le lift and shift est le plus rapide quand une application tourne déjà sur un environnement d'exécution supporté et que l'objectif est de quitter un datacenter. Pour les applications sur des environnements en fin de vie, les déplacer sans changement transporte les anciens risques sur la nouvelle plateforme : les mettre à niveau ou les reconstruire pendant la migration revient souvent moins cher au total.
Qu'est-ce qu'une migration par lots ?
Une migration par lots divise un grand parc applicatif en ensembles d'applications liées et confie chaque ensemble à une équipe qui en est responsable de l'analyse à la bascule. Elle supprime le goulot d'étranglement central et rend l'avancement facile à suivre sur de nombreuses équipes.