Interruptions de service, incompatibilités techniques, perte de performances, … une migration Cloud mal préparée peut avoir de lourdes conséquences sur l’activité d’une entreprise. Car migrer vers le Cloud ne consiste pas simplement à transférer des applications et des données vers une nouvelle infrastructure. C’est l’ensemble du système d’information, avec ses contraintes techniques, ses dépendances et ses exigences métiers, qu’il faut prendre en compte. Réussir cette transition exige donc une connaissance précise de l’existant, une anticipation des risques et une stratégie adaptée aux besoins de chaque entreprise.
KDDI France, spécialiste des solutions IT avancées, sécurisées et personnalisables, identifie 7 erreurs qui peuvent impacter le bon déroulement d’une migration vers le Cloud.
1. Vouloir tout migrer à l’identique
Reproduire l’infrastructure existante dans le Cloud peut sembler être l’option la plus simple et la plus rapide. Pourtant, cette approche n’est pas toujours le plus pertinente. Selon la nature des environnements et les objectifs de l’entreprise, certaines briques technologiques peuvent être conservées, d’autres adaptées parfois même il faut repenser entièrement l’architecture. Une migration peut donc être l’occasion de simplifier l’infrastructure, de renforcer sa sécurité et de mieux répondre aux évolutions futures. L’essentiel est de déterminer, en amont, ce qui doit être conservé, transformé ou entièrement reconstruit.
2. Sous-estimer l’hétérogénéité du système d’information
Serveurs physiques, machines virtuelles, hyperviseurs multiples ou workloads spécifiques : tous les environnements ne peuvent pas être migrés de la même manière. La présence ou non de solutions de sauvegarde et de réplication peut également conditionner la stratégie à adopter. Sans une analyse précise de l’infrastructure existante, certaines contraintes techniques risquent d’être découvertes trop tard, et de compliquer la migration. Un audit préalable permet d’identifier ces particularités et de choisir les méthodes de transfert les plus adaptés.
3. Négliger les dépendances applicatives
Une application peut être correctement migrée et pourtant devenir inutilisable. Il suffit qu’un service indispensable à son fonctionnement (base de données, système d’authentification, partage de fichiers, flux réseau, …) soit resté dans l’ancien environnement. Les applications fonctionnent rarement de manière isolée et leurs interdépendances peuvent provoquer des interruptions de service si elles sont mal anticipées. Cartographier ces dépendances en amont permet d’organiser leur migration de manière cohérente et de préserver le fonctionnement des services.
4. Mal évaluer les volumes de données à transférer
Plus les volumes de données sont importants, plus la migration risque de prendre du temps et de compliquer la synchronisation entre les infrastructures source et cible. Tout transférer au moment de la bascule peut alors entraîner des interruptions prolongées. Pour limiter ce risque, une première copie des données, suivie de synchronisations régulières portant uniquement sur les modifications intervenues depuis ce transfert initial, permet de réduire le volume restant à transférer lors de la bascule définitive et de réduire d’autant la durée d’indisponibilité des services.
5. Appliquer la même stratégie à toutes les applications
Toutes les applications n’ont pas le même niveau de criticité. Certaines peuvent être interrompues plusieurs heures sans conséquence majeure, tandis que d’autres nécessitent une continuité de service quasi permanente. Appliquer une stratégie identique à l’ensemble du système d’information peut donc fragiliser les activités les plus critiques. Chaque application doit faire l’objet d’une évaluation spécifique : degré de criticité, durée d’interruption acceptable, éventuelles solutions de repli, …. Une application métier stratégique ne peut être migrée selon les mêmes modalités qu’un serveur dont l’arrêt peut être planifié plusieurs heures à l’avance.
6. Attendre la bascule pour tester l’environnement cible
Découvrir une incompatibilité au moment de la mise en production peut compromettre la continuité des activités. Les tests ne doivent donc pas être considérés comme une simple formalité précédant la bascule, mais comme une étape à part entière du processus de migration. Le fonctionnement des workloads, les communications réseau, les accès utilisateurs et les dépendances applicatives doivent donc être vérifiés progressivement dans l’environnement cible. Plus ces contrôles sont réalisés tôt, plus il est facile d’identifier et de corriger les éventuels dysfonctionnements.
7. Considérer la migration comme une finalité
La mise en production ne marque pas l’aboutissement d’une migration Cloud. Une infrastructure Cloud n’est jamais figée et doit évoluer avec les besoins de l’entreprise. Les performances, la disponibilité, la sécurité et la consommation des ressources nécessitent un suivi régulier afin d’identifier les ajustements nécessaires. La migration peut également ouvrir la voie à une modernisation progressive de l’infrastructure, notamment grâce à davantage d’automatisation et à une meilleure adaptation des ressources aux usages.
