The Doppler Quarterly (FRANÇAIS) Printemps 2018 | Page 22

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’application 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 migra-
tion, et que ses modèles de migration sont connus, vous devez élaborer un plan de
migration détaillé. Outre l’objectif 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’infra-
structure 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’accompagnement, 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és
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-ser-
vice destinées à une multiplicité de parties prenantes, sont de nature à réduire gran-
dement 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 appli-
cations. Bon nombre d’organisations 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 applica-
tions suivant le rythme souhaité.
20 | THE DOPPLER | PRINTEMPS 2018