The Doppler Quarterly (FRANÇAIS) Édition spéciale 2019 | Page 50
La détermination de la compatibilité avec le cloud et du modèle de migration exige la création et
la définition de cette compatibilité, puis une analyse soigneuse des caractéristiques de l’applica-
tion au travers d’objectifs et de moyens qualitatifs.
Facteur n° 3 : plan de migration prescriptif avec prise en compte des
détails
Lorsqu'une analyse de l'application détermine que celle-ci est adaptée à la migration, et que ses
modèles de migration sont connus, vous devez élaborer un plan de migration détaillé. Outre l’ob-
jectif global de la migration, un plan de migration doit inclure les détails de l’exécution, y compris
toutes les tâches et tous les propriétaires de la migration.
Les détails du niveau d'exécution sont variables selon le modèle de migration choisi. Un modèle
Rehost, par exemple, comprendra principalement des tâches d’infrastructure incluant quelques
modifications de configuration des applications, ainsi qu’un plan de test et de validation. Une
migration fondée sur le modèle Refactor, en revanche, devra prévoir les détails de chacun des élé-
ments à modifier, y compris leur état actuel et futur, les fonctionnalités, le code d’accompagne-
ment, les détails du déploiement, ainsi que les plans de test et de validation.
Il convient que le plan de migration contienne au minimum les éléments suivants :
•
•
•
•
•
•
•
•
•
Vecteurs et attentes en matière d'activité
Fonctionnalité
Architecture à l’état actuel et à l'état futur
Modèles et approche
Liste des ressources et dépendances
Configurations ou modifications souhaitées
Outils (migration, déploiement, surveillance, journalisation)
Tâches de migration détaillées, plans de déploiement avec RACI
Niveau de préparation, test, validation, mise en service et plans opérationnels
Pour que les efforts de migration permettent d'atteindre la vitesse et l’échelle désirées, le plan de
migration appliqué lors de l’exécution doit être très prescriptif. De plus, les approches et artefacts
réutilisables, ainsi que les approches en libre-service destinées à une multiplicité de parties
prenantes, sont de nature à réduire grandement le temps de latence.
Lors de la création d'un plan de migration détaillé, il importe de prendre en compte les approches
susceptibles de raccourcir les temps d’immobilisation nécessaires au basculement durant la phase
de migration. Pour viser une interruption de service quasi-nulle lors de la migration d’applications,
vous pouvez appliquer différentes options telles que des déploiements « bleu/vert », la réplication
incrémentielle, un environnement isolé pour le test et la validation avant le basculement, ou encore
des enregistrements DNS temporaires aux fins de test.
Vous pouvez par exemple élaborer des listes de contrôle de migration standard pour chacun des
modèles, que vous pourrez ensuite répercuter sur l'ensemble des applications. Bon nombre d’or-
ganisations disposent d'un ensemble d’outils de test et de validation communs. Par conséquent,
l'usage d'un ensemble de tests commun à tous les modèles est utile pour permettre à l’équipe des
opérations d'intégrer les applications suivant le rythme souhaité.
48 | THE DOPPLER | ÉDITION SPÉCIALE 2019