Passer au cloud sans naviguer à l'aveugle.

Une application peut dépendre de composants qui n'apparaissent pas dans la première liste des systèmes : services d'annuaire, tâches planifiées en arrière-plan, partages de fichiers ou interface d'un partenaire externe. Ces liens sont recensés avec les responsables concernés. Il en résulte des groupes de migration dont les composants sont basculés ensemble ou reliés délibérément à titre transitoire. Le volume de données, les fenêtres de maintenance et la disponibilité des interlocuteurs métier influencent l'ordre des opérations. Le plan de vagues reflète ainsi les processus réels, et non une simple liste de systèmes techniquement déplaçables.

Une méthode de migration adaptée est définie pour chaque groupe. Certaines applications peuvent d'abord être reprises pratiquement sans modification, d'autres nécessitent des adaptations à l'environnement cible. Une modernisation plus poussée peut être pertinente comme étape distincte, lorsqu'elle alourdirait inutilement la migration. La décision tient compte du risque de bascule, de l'exploitation ultérieure et des ressources disponibles. Avant le transfert, l'environnement cible, les accès et les connexions nécessaires sont vérifiés, afin de ne pas devoir attendre la fenêtre de bascule prévue pour réunir des prérequis déjà connus.

Le jour de la bascule, l'état des données, les modifications d'accès et les vérifications métier doivent être cohérents entre eux. Un déroulement coordonné décrit donc à quel moment le travail sur l'ancien système s'arrête, quelles données sont transférées et quels tests ont lieu ensuite. Cela inclut les interlocuteurs et les canaux de communication. Les parties concernées doivent savoir qui évalue un problème et qui décide de la poursuite des opérations. L'accessibilité technique n'est qu'une étape de vérification parmi d'autres ; l'application doit aussi pouvoir exécuter les opérations pertinentes pour l'activité de votre entreprise.

Les conditions dans lesquelles la bascule doit être interrompue ou annulée sont également discutées au préalable. Un retour arrière n'est pas aussi simple pour toutes les applications, en particulier lorsque de nouvelles données ont déjà été créées dans le système cible. La planification fixe donc les conditions et les limites de la procédure prévue. Le pilote et les tests servent à vérifier les hypothèses et à améliorer le déroulement. Ce n'est qu'avec ces résultats qu'il est possible de juger ensemble si une nouvelle vague de migration est prête ou si un travail supplémentaire reste nécessaire.

Après la mise en production, de nouveaux constats peuvent apparaître : charge modifiée, autorisations manquantes ou processus qui n'étaient pas entièrement visibles pendant les tests. Ces éléments sont recensés, évalués et traités pendant la phase de stabilisation convenue. Le transfert vers l'exploitation comprend la configuration, les accès, la surveillance et les tâches résiduelles connues. Vos responsables applicatifs confirment que l'application est utilisable du point de vue métier ; les responsabilités techniques et organisationnelles sont documentées de manière à ce qu'il soit clair, après la fin du projet, qui traite les signalements ultérieurs.

Les anciens systèmes ne doivent pas continuer à fonctionner ensuite sans contrôle. Le démantèlement ne doit toutefois supprimer aucune dépendance encore nécessaire. Après la recette, on détermine donc ensemble quelles ressources doivent être arrêtées, quelles données doivent être conservées et quels contrats doivent être adaptés. Un plan de démantèlement fixe l'ordre des opérations et les validations. Les coûts redondants et les tâches en suspens restent ainsi visibles. La migration se termine par un transfert ordonné et des travaux de suivi coordonnés, et non par le simple constat que les données se trouvent désormais ailleurs.