Une proposition de migration peut sembler complète dès lors qu’elle répertorie des serveurs et une destination. Les questions les plus délicates concernent pourtant le travail que ces serveurs rendent possible. Les équipes peuvent-elles continuer à traiter les commandes ? Quand un export planifié s’exécute-t-il ? Qui vérifie les enregistrements après le transfert ? Un plan de migration cloud doit relier les décisions d’infrastructure à ces activités quotidiennes. La séquence suivante permet de transformer un transfert global en travaux concrets pouvant être examinés.
Sur cette page
Définissez l’amélioration opérationnelle
Remplacez « passer au cloud » par une raison que l’on peut évaluer. Peut-être les mises en production dépendent-elles d’un unique serveur configuré manuellement, ou une période de forte activité exige-t-elle une capacité que l’environnement actuel ne peut fournir. Consignez le fonctionnement présent avant de définir l’environnement futur. Sans cette référence, il est difficile de savoir si la migration a résolu le problème initial ou simplement changé l’endroit où il se manifeste.
- Nommez le processus concerné et son responsable.
- Décrivez une amélioration observable, comme un processus de déploiement reproductible.
- Dressez la liste des contraintes que la migration doit respecter.
Cartographiez les connexions autour de chaque charge de travail
Pour chaque application, répertoriez sa base de données, son stockage de fichiers, ses tâches planifiées, ses services externes et ses exigences d’accès. Demandez aux personnes qui l’exploitent de revoir cette cartographie. Un rapport nocturne ou une connexion fournisseur peut facilement passer inaperçu dans un inventaire de serveurs. Indiquez les dépendances à migrer ensemble et les connexions qui peuvent rester en place pendant une transition par étapes.
Choisissez une approche de migration par application
Exemple de décision : un portail client utilise un environnement d’exécution encore pris en charge, mais partage une base de données avec une ancienne application comptable. Migrer le portail en premier peut être pertinent uniquement si la connexion à la base de données restante respecte les exigences convenues d’accès et de performance. Dans le cas contraire, migrez les charges de travail connectées ensemble ou résolvez d’abord la dépendance. Comparez un transfert direct, des modifications ciblées et une refonte selon les besoins de cette application : tout le parc n’a pas besoin d’une approche unique.
Concevez le fonctionnement du nouvel environnement
Attribuez les responsabilités pour les accès, les déploiements, les alertes, les sauvegardes et le suivi des dépenses. Estimez la demande à partir des informations d’utilisation disponibles, en intégrant les périodes calmes et les pics. Examinez l’évolution de l’estimation lorsque le stockage augmente ou que des données circulent entre services. Une discussion utile sur les coûts explicite ses hypothèses et les éléments à surveiller après le lancement, plutôt que de considérer la première estimation comme une facture d’exploitation fixe.
- Qui peut modifier les paramètres de production ?
- Qui intervient lorsqu’une tâche échoue ?
- Comment la restauration des sauvegardes sera-t-elle vérifiée ?
Définissez les conditions de retour arrière avant la bascule
Pour le portail de l’exemple, convenez de la manière dont l’équipe vérifiera la connexion, l’envoi de commandes et le nombre d’enregistrements avant d’ouvrir le nouvel environnement. Définissez les échecs qui imposent d’arrêter la transition et la personne qui prendra cette décision. Si les utilisateurs peuvent créer de nouveaux enregistrements après la bascule, renvoyer le trafic vers l’ancien serveur ne suffit pas : ces enregistrements nécessitent un plan de traitement convenu. Répétez la séquence, en incluant le point au-delà duquel le retour arrière exige un travail supplémentaire sur les données.
Clôturez la migration par des vérifications d’exploitation
Après le transfert, comparez les processus, les tâches planifiées, les alertes et les usages à la référence convenue. Attribuez un responsable aux problèmes non résolus. Ne retirez l’ancien environnement qu’une fois les vérifications de transition terminées et les données ou configurations à conserver identifiées. Laissez la cartographie applicative et les consignes de reprise accessibles aux personnes qui maintiendront le service.