Liste de vérification de la migration vers le cloud :8 étapes pour assurer un parcours fluide (et sûr) vers le cloud

Déplacer des applications et des données critiques vers le cloud est un projet colossal qui nécessite une planification approfondie si vous espérez un retour sur investissement élevé. Sans une stratégie solide, votre migration vers le cloud entraînera probablement plus de pertes de bénéfices et de maux de tête que d'avantages commerciaux.

Cet article propose une liste de contrôle pour la migration vers le cloud qui garantit que votre migration vers le cloud se déroule en douceur, en toute sécurité et sans mauvaises surprises. Vous pouvez utiliser notre liste de contrôle comme référence pour le processus de migration, car le plan étape par étape ci-dessous couvre tous les principaux aspects de la migration d'une application vers le cloud.

Liste de contrôle pour la migration vers le cloud

La lutte contre la migration vers le cloud est un problème courant pour les entreprises. Des études récentes révèlent que 55 % des migrations vers le cloud accusent des retards importants ou dépassent le budget .

En outre, 62 % des organisations en cours de transition vers le cloud décrivent le processus comme étant soit difficile ou échec . La plupart de ces entreprises se précipitent dans la transition sans réfléchir sérieusement :

• Le coût total de possession (TCO).
• Comment l'équipe déplacera-t-elle d'énormes quantités de données et d'applications stratégiques vers le cloud ?
• Différentes options pour les déploiements et l'intégration dans le cloud.
• Nouveaux risques potentiels pour la cybersécurité.
• Dans quelle mesure l'équipe interne est-elle préparée à opérer dans le cloud ?

La liste de contrôle de la migration vers le cloud ci-dessous vous permet de prendre en compte ces facteurs avant que l'équipe ne commence à déplacer des applications et des services vers le cloud.

Choisir un ou plusieurs architectes de migration Go-To

La migration vers le cloud implique de nombreuses décisions et plans techniques, vous devez donc désigner un seul spécialiste ou une équipe d'experts pour diriger l'effort. Que vous partiez avec un ou plusieurs membres du personnel, le rôle d'un architecte de migration est de :

• Évaluez les services pour voir s'ils conviennent mieux à l'hébergement sur site ou dans le cloud.
• Créez un calendrier pour la migration et la feuille de route cloud.
• Concevoir des stratégies optimales pour déplacer les données et les applications
• Identifier et superviser la refactorisation nécessaire de l'application.
• Déterminer les priorités de migration.
• Définissez la chaîne d'outils requise.

L'architecte dédié doit également fournir une image complète de votre informatique. Ce processus implique de répondre aux questions suivantes :

• De quelles applications disposez-vous et qui les utilise (et à quelle fréquence) ?
• Dans quelle mesure les applications que vous souhaitez migrer sont-elles critiques pour l'entreprise ?
• Quelles ressources les programmes consomment-ils et dépendent-ils d'autres applications ?
• Quels accords de niveau de service, mesures de continuité des activités et mesures de conformité sont actuellement en place ?
• Existe-t-il des problèmes de performances qui affectent les opérations en cours ?

En fonction de l'analyse, l'architecte de la migration doit évaluer si votre personnel actuel possède le savoir-faire nécessaire pour :

• Effectuez la migration.
• Fonctionner dans l'environnement cloud.

Ne démarrez jamais la transition vers le cloud à moins d'être sûr que votre équipe peut s'épanouir dans le nouvel environnement.

L'équipe de migration dédiée doit également déterminer le coût total de possession (TCO) pour illustrer le retour sur investissement de la migration vers le cloud. L'évaluation du coût total de possession pour la migration vers le cloud inclut des facteurs tels que :

• Le coût global de la migration.
• Coûts liés au cloud après la migration (principalement le prix de la bande passante et de la mise en réseau).
• Le coût de la formation du personnel.
• Maintenance post-migration régulière.
• Le coût des temps d'arrêt potentiels.
• Coûts d'espace, de refroidissement et d'électricité (pour un cloud privé sur site).

Définir des objectifs de migration et des KPI

L'étape suivante consiste à établir le ou les objectifs principaux de la migration. Voici quelques objectifs haut de gamme courants :

• Modernisation d'une ancienne application
• Accélérer un service particulier.
• Améliorer les capacités opérationnelles.
• Augmentation de la résilience du système.
• Amélioration de l'expérience utilisateur.
• Amélioration de l'évolutivité des services
• Réduire les coûts de fonctionnement.
• Améliorer la sécurité des données.

Outre l'objectif général, l'équipe doit définir les indicateurs de performance clés (KPI) de la migration vers le cloud. Ces mesures mesureront les performances d'une application ou d'un service migré par rapport aux attentes. Il n'y a pas de limite au nombre de KPI que votre équipe peut suivre, mais toutes les statistiques relèvent de l'une des deux catégories :

• KPI que vous suivez pendant le processus de migration.
• KPI post-migration.

Voici les KPI les plus courants qu'une entreprise peut suivre pendant le processus de migration :

• Durée de la migration (à la fois dans son ensemble et par application).
• Disponibilité des services critiques.
• Durée d'indisponibilité des services et des centres de données
• Dégradation du service due aux temps d'arrêt.
• Le nombre de tickets de service générés.
• Coût de la migration.

Examinons quelques KPI post-migration que votre équipe peut suivre :

• KPI de l'infrastructure (utilisation du processeur, encombrement de la mémoire de service, performances du disque, équilibrage de charge, latence, débit du réseau, etc.)
• Métriques de performances de l'application (taux d'erreur, nombre de délais d'attente, temps de réponse moyen (ART), temps de réponse maximal (PRT), disponibilité, disponibilité, etc.)
• KPI de l'expérience utilisateur (nombre de pics de requêtes, erreurs de code d'état HTTP, exceptions levées et consignées, décalage, temps de réponse, etc.).
• Métriques d'impact commercial (durée du processus de paiement, taux d'abonnement et de désabonnement, taux d'engagement, etc.).
• KPI de coûts (facturation mensuelle, frais de personnel, outils tiers, frais de conseil, etc.)

Vous devez définir une valeur de référence pour chaque KPI avant de décider quoi suivre. La création de références est le processus de mesure de l'état actuel (avant la migration) d'une application et d'un service. Ces KPI vous permettent de déterminer si les performances post-migration sont acceptables ou non.

Effectuer une évaluation des données et des applications

L'évaluation des données est une étape essentielle de cette liste de contrôle pour la migration vers le cloud, car le déplacement des données est généralement la partie la plus délicate de l'adoption du cloud. Une évaluation soigneuse des données permet à votre équipe d'évaluer :

• Niveaux de risque des données.
• Le volume et le type de données que vous prévoyez de migrer.
• Résilience globale des données.
• Exigences légales en matière de confidentialité des données (le cas échéant).
• Menaces les plus importantes pour l'intégrité des données.
• Scénarios potentiels de violation ou de fuite de données après la migration

L'emplacement de vos données peut avoir un impact sur les performances d'un service ou et . Le déplacement des données vers le cloud lorsque les méthodes d'accès aux données fonctionnent toujours sur site peut affecter considérablement les performances. Il en va de même si la base de données est toujours sur site mais que le service qui y accède réside dans le cloud.

Outre l'évaluation des données, vos applications sur site doivent bénéficier du même traitement. Avant la migration, l'équipe doit créer un inventaire de toutes les applications sur site et de leurs serveurs. Vous devez également évaluer toutes les machines virtuelles actuelles et prendre en compte les dépendances potentielles des applications.

Par conséquent, vous pouvez déterminer quelles applications nécessitent une refactorisation avant de les déplacer vers le cloud. L'équipe peut également commencer à hiérarchiser les applications à migrer en premier.

Évaluer les options de migration vers le cloud

La prochaine étape de la liste de contrôle de la migration vers le cloud consiste à évaluer quelles applications nécessitent quel type d'intégration avec le cloud. Vous avez deux options :

• Intégration cloud peu profonde (alias lift-and-shift) : Lorsque vous soulevez et déplacez une application, vous apportez peu ou pas de modifications au code et configurez l'application dans le cloud plus ou moins dans sa forme actuelle. La migration d'une application sans aucune modification est appelée réhébergement.; apporter des modifications mineures lors du déplacement d'une application vers le cloud est une refactorisation .
• Intégration cloud profonde : Contrairement à son homologue superficiel, l'intégration au cloud profond vous oblige à modifier l'application pour tirer parti des fonctionnalités du cloud. Les changements peuvent aller d'ajustements relativement simples (comme la configuration de l'autoscaling et de l'équilibrage de charge dynamique) à des mises à jour avancées (comme l'activation de l'informatique sans serveur) qui font de l'application une solution cloud native.

L'intégration cloud peu profonde est une option beaucoup plus rapide que la refactorisation des principales parties d'une application. En général, les applications critiques valent généralement l'effort d'intégrations profondes. Les applications et services moins vitaux peuvent faire l'objet d'une approche peu profonde, car vous pouvez les refactoriser au fil du temps après avoir migré vers le cloud.

Les entreprises décident également souvent de retirer ou de conserver des applications lorsqu'elles évaluent quel service nécessite quel type d'intégration :

• Le retrait est le processus d'identification d'une application ou d'un service obsolète qui n'a aucune valeur s'il est téléchargé dans le cloud.
• La conservation est la décision de conserver une application sur site, généralement en raison d'un problème de sécurité ou de conformité.

Choisir le bon modèle de déploiement cloud

Le choix d'un modèle de déploiement cloud adapté est essentiel à la réussite de la migration vers le cloud. Différents modèles correspondent à différents cas d'utilisation, et les cinq options que vous pouvez choisir sont :

• Cloud public (environnement mutualisé qui permet d'accéder à des ressources de calcul via Internet ou via une connexion directe dédiée).
• Cloud privé (système à locataire unique dans lequel une entreprise gère des ressources cloud dans son propre centre de données).
• Cloud hybride (mélange de systèmes sur site, de clouds publics et privés dans lequel les charges de travail se déplacent entre les environnements via l'automatisation et l'orchestration).
• Multicloud (combinaison d'au moins deux environnements IaaS de cloud public).
• Cloud communautaire (infrastructure partagée entre plusieurs entreprises ayant des besoins ou des préoccupations communs).

Le modèle de déploiement à utiliser dépend principalement des besoins et des objectifs uniques de votre entreprise. Voici quelques conseils :

• Le cloud public fournit un environnement évolutif avec un modèle de paiement à l'utilisation. Bien qu'il soit hautement évolutif, le cloud public n'est peut-être pas idéal pour les charges de travail sensibles.
• Un cloud privé est idéal pour une entreprise disposant du budget nécessaire pour gérer un environnement cloud sur site adapté à ses charges de travail critiques.
• Un cloud hybride vous permet d'exécuter des charges de travail sensibles sur site tout en tirant parti de l'évolutivité du cloud public pendant les pics de demande.
• Bien qu'ils soient très avantageux lorsqu'ils sont bien exécutés, vous devez être conscient de certains défis liés au cloud hybride avant de concevoir une architecture hybride.
• Le multicloud est un excellent choix pour les entreprises soucieuses de la dépendance vis-à-vis d'un fournisseur ou pour les entreprises qui cherchent à combiner les services de plusieurs fournisseurs.

Choisir un fournisseur de services cloud

À moins que vous n'ayez choisi de configurer un cloud privé sur site, le prochain élément de la liste de contrôle de la migration vers le cloud devrait être de trouver un fournisseur de cloud. Bien que la plupart des fournisseurs proposent des services similaires, ils ne sont pas tous identiques. Voici quelques considérations clés lors du choix d'un fournisseur de cloud :

• Prix.
• Sélection des services.
• Disponibilité dans des régions spécifiques.
• Garanties de disponibilité.
• La familiarité de votre équipe interne avec la pile technologique du fournisseur.
• Exigences de conformité spécifiques à l'industrie (par exemple, conserver les données utilisateur dans leur emplacement d'origine conformément au CCPA ou au RGPD).
• Assistance post-migration et services informatiques gérés.

N'oubliez pas que les fournisseurs de services les plus populaires ne sont pas toujours les mieux adaptés. Les fournisseurs de premier plan visent à répondre à un large éventail de besoins, de sorte qu'ils ne correspondent pas toujours à une entreprise d'un secteur spécifique.

Par exemple, une entreprise qui opère dans le secteur de la santé pourrait être mieux lotie en s'associant à un fournisseur de niche qui comprend mieux et prend en charge la conformité avec HIPAA.

Effectuer la refactorisation nécessaire

Une fois que vous savez de quel déploiement cloud vous avez besoin et avec qui vous associer, votre équipe doit commencer à apporter les modifications nécessaires aux applications et aux services avant de les migrer vers le cloud.

L'objectif est de faire fonctionner le logiciel aussi efficacement et efficacement que possible dans le cloud . Par exemple, votre équipe peut refactoriser une application pour :

• Travailler avec un nombre variable d'instances en cours d'exécution pour permettre une mise à l'échelle quasi instantanée.
• Tirez parti des fonctionnalités du cloud dynamique (telles que la possibilité d'allouer et de désallouer des ressources en fonction des besoins actuels).
• Créer une architecture plus orientée services pour déplacer rapidement des services individuels vers le cloud (à la fois cette fois-ci et plus tard).

C'est aussi le bon moment pour repenser la gouvernance et la sécurité. Vous devrez probablement ajuster votre stratégie de gouvernance pour moins compter sur la sécurité et le contrôle internes, et davantage sur les services cloud du fournisseur. En termes de sécurité cloud, vous devez :

• Évaluer si la migration peut entraîner de nouvelles vulnérabilités
• Comprendre comment votre équipe interne travaillera avec le fournisseur pour assurer la sécurité des ressources cloud.
• Ajustez (et éventuellement améliorez) vos mesures et pratiques de sécurité actuelles.
• Décidez si vous pouvez bénéficier des outils de sécurité supplémentaires proposés par le fournisseur.
• Configurez des mécanismes de basculement et de reprise après sinistre

Migration et basculement méthodiques du trafic depuis les opérations sur site

Bien que vous puissiez tout migrer vers le cloud en une seule fois, cette approche peut être difficile et risquée à mettre en place. Au lieu de cela, vous devez migrer les applications et les services un par un , en commençant par les applications les moins critiques et en progressant lentement vers les plus importantes.

Voici à quoi devrait ressembler cette approche de la migration :

• Donnez la priorité aux applications que votre équipe peut déplacer avec le moins de risques pour les opérations. De bons choix sont les applications qui ne nécessitent qu'un réhébergement ou qui utilisent un minimum de ressources (comme un stockage ou des calculs faibles).
• Ensuite, commencez à déplacer les applications qui ont une grande valeur pour votre entreprise, mais qui présentent un risque relativement faible lors de la migration.
• Enfin, laissez les charges de travail critiques et perturbatrices aux dernières étapes de la migration. Ne commencez jamais à déplacer ces applications à moins que celles des étapes précédentes ne fonctionnent de manière optimale.
• Utilisez un test manuel ou automatisé (ou les deux) pour vérifier si la migration a réussi ou non.

En fonction de l'architecture de vos applications et de vos magasins de données, vous pouvez basculer le trafic de la solution sur site vers le cloud de deux manières :

• Tout à la fois : L'équipe bascule tout le trafic sur site dès que l'application commence à s'exécuter dans le cloud.
• Petit à petit : Vous déplacez quelques clients vers le nouvel environnement une fois que l'équipe a configuré l'application basée sur le cloud. Si tout fonctionne comme prévu, vous continuez à transférer les clients vers le cloud au fil du temps jusqu'à ce que tous les utilisateurs finaux utilisent la nouvelle application.

Utilisez notre liste de contrôle de migration vers le cloud pour migrer en toute confiance

Bien que le passage au cloud soit souvent une décision évidente, de nombreuses entreprises rencontrent des difficultés ou ont un succès limité lors du déplacement d'applications vers le cloud. En vous en tenant à la liste de contrôle de la migration vers le cloud ci-dessus, vous évitez tous les pièges courants. Vous pouvez ainsi commencer à planifier votre adoption du cloud sans craindre de coûteux faux pas.