Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Bonnes pratiques pour les grandes migrations Les migrations de grande envergure peuvent s'avérer difficiles, en fonction des facteurs qui régissent le fonctionnement d'une organisation. Cette section couvre certains des facteurs clés qui peuvent simplifier les migrations de grande envergure s'ils sont pris en compte au cours des phases initiales de l'effort et suivis tout au long du projet. Les meilleures pratiques suivantes pour les migrations de grande envergure sont basées sur les données collectées auprès d'autres clients. Les meilleures pratiques sont réparties en trois catégories : + Personnes + Technologie + Processus # Point de vue des personnes Cette section met l'accent sur les domaines clés suivants du point de vue des personnes : + Soutien à la direction — Identifier un leader à fil unique habilité à prendre des décisions + Collaboration et appropriation des équipes — Collaboration entre différentes équipes + Formation — Former les équipes de manière proactive aux différents outillages ## Soutien à la direction **Contents** + [Identifiez un leader à fil unique](#leader) + [Aligner l'équipe de direction](#align-leadership) ### Identifiez un leader à fil unique Lorsque vous démarrez une migration de grande envergure, il est important d'identifier un responsable technique à fil unique entièrement dédié au projet et responsable. Ce leader est habilité à prendre des décisions, à éviter les silos et à rationaliser les flux de travail en maintenant des priorités cohérentes. Un important client de migration internationale a pu passer d'un serveur par semaine au début du programme à plus de 80 serveurs par semaine au début du deuxième mois. Le soutien complet du CIO en tant que leader mono-thread était essentiel à l'augmentation rapide du nombre de serveurs faisant l'objet de la migration. Le directeur informatique a participé à des appels hebdomadaires avec l'équipe chargée de la migration pour garantir l'escalade et la résolution des problèmes en temps réel, ce qui a accéléré la vitesse de migration. ### Aligner l'équipe de direction Il est important de créer un alignement entre les différentes équipes en ce qui concerne les critères de réussite de la migration. Bien que la planification et la mise en œuvre de la migration puissent être effectuées par une petite équipe dédiée, des défis se posent lors de la définition de la stratégie et de l'exécution d'activités périphériques. Ces obstacles potentiels peuvent nécessiter des actions ou des escalades de la part de différents secteurs de l'organisation informatique, notamment les suivants : + Entreprise + Applications + Réseaux + Sécurité + Infrastructures + Fournisseurs tiers L'action directe des propriétaires des applications, le leadership, l'alignement et une remontée claire vers le leader mono-thread deviennent importants. ## Collaboration et appropriation au sein de l'équipe **Contents** + [Créez une équipe interfonctionnelle chargée de la mise en œuvre du cloud](#cross-function) + [Définissez à l'avance les exigences pour les équipes et les personnes extérieures à l'équipe de migration principale](#define-reqs) + [Vérifiez qu'il n'y a aucun problème de licence lors de la migration des charges de travail](#licensing) ### Créez une équipe interfonctionnelle chargée de la mise en œuvre du cloud **Contents** La première étape essentielle d'un projet de migration de grande envergure consiste à permettre à l'organisation de travailler dans le cloud. Pour ce faire, nous vous recommandons de créer un [moteur d'activation du cloud](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE). Le CEE est une équipe autonome et responsable qui se concentre sur la préparation opérationnelle de l'organisation aux AWS migrations vers. Le CEE doit être une équipe interfonctionnelle comprenant des représentants de l'infrastructure, des applications, des opérations et de la sécurité. L'équipe est chargée des responsabilités suivantes : + Élaboration de politiques + Définition et mise en œuvre des outils, des processus et des architectures qui établiront le modèle d'opérations cloud de l'organisation + Continuer à faciliter l'alignement des parties prenantes dans tous les domaines qu'elles représentent Un client du secteur de la santé n'a pas commencé par un CEE. Cependant, grâce aux premières migrations pilotes, l'écart a été identifié. Avant la date limite de migration, avec des délais stricts en place, l'équipe a mis en place une salle de crise *migratoire.* Dans la salle de crise de la migration, les parties prenantes de l'infrastructure, de la sécurité, des applications et des entreprises pourraient aider à résoudre les problèmes. ### Définissez à l'avance les exigences pour les équipes et les personnes extérieures à l'équipe de migration principale Identifiez les équipes et les personnes qui ne font pas partie du programme principal et définissez leur implication lors des phases de planification de la migration. Pour faciliter la dynamique de la migration au cours des étapes ultérieures, portez une attention particulière à l'implication des équipes chargées des applications. Leur connaissance de l'application, leur capacité à diagnostiquer les problèmes et leur obligation d'approuver le transfert seront nécessaires. Bien que la migration soit dirigée par une équipe centrale, les équipes chargées des applications seront probablement impliquées dans la validation du plan de migration et les tests lors du passage à la technologie. Les clients abordent souvent la migration vers le cloud comme un projet d'infrastructure plutôt que comme une migration d'applications. Cela peut entraîner des problèmes lors de la migration. Nous vous recommandons de prendre en compte l'implication requise de l'équipe d'application lors de la sélection d'une stratégie de migration. Par exemple, une stratégie de réhébergement nécessite moins d'implication de l'équipe d'application par rapport à une stratégie de replateforme ou de refactorisation dans laquelle une plus grande partie du paysage applicatif est modifiée. Si la disponibilité du propriétaire de l'application est limitée, envisagez d'utiliser le rehost ou le replatform plutôt que les stratégies de refactorisation, de relocalisation ou de rachat. ### Vérifiez qu'il n'y a aucun problème de licence lors de la migration des charges de travail Les licences peuvent changer lorsque vous migrez des produits d'entreprise prêts à l'emploi vers le cloud. Vos contrats de licence peuvent être axés sur votre patrimoine sur site. Par exemple, une licence peut être attribuée par processeur ou liée à une adresse MAC spécifique. Par ailleurs, les contrats de licence peuvent ne pas inclure le droit d'hébergement dans un environnement de cloud public. Cependant, la renégociation des licences avec les fournisseurs peut entraîner de longs délais et constitue un obstacle majeur à la migration. Nous vous recommandons de collaborer avec vos équipes de gestion des achats ou des fournisseurs dès que le périmètre de la migration est défini. Les licences peuvent également influencer votre architecture cible et vos modèles de migration. ## Entraînement **Contents** + [Former les équipes aux nouveaux outils et processus](#tools-training) ### Former les équipes aux nouveaux outils et processus Une fois la stratégie de migration définie, prenez le temps de comprendre quelle formation pourrait être nécessaire pour la migration et pour votre modèle d'exploitation cible. Au cours de la migration, vous utiliserez probablement des outils AWS Database Migration Service, tels que ceux qui sont nouveaux pour votre organisation. La formation proactive des équipes réduit les délais pendant les phases de migration. Nous vous recommandons de rechercher des méthodes actives de transfert de connaissances qui offrent la possibilité d'expérimenter l'outillage de manière pratique. À titre d'exemple, AWS Professional Services a organisé plusieurs sessions de formation Cloud Migration Factory à l'intention de trois AWS partenaires intégrateurs de systèmes (SI) responsables d'une migration de grande envergure. Cela a permis à l'équipe de disposer de connaissances de base au moment de passer à la phase de migration. Cela a également permis d'identifier des experts en la matière (SMEs) susceptibles de jouer un rôle de premier plan au sein de chaque équipe SI AWS Partner. # Perspective technologique La technologie constitue une base solide pour accélérer les grandes migrations. Par exemple, la solution Cloud Migration Factory se concentre sur la manière d' end-to-endautomatiser les migrations. Cette section explore certaines des meilleures pratiques d'utilisation de la technologie pour atteindre l'échelle et la rapidité requises, conformément à la portée, à la stratégie et aux délais. Le principe fondamental consiste à examiner les domaines d'automatisation dans la mesure du possible. Si vous avez des milliers de serveurs à portée de main, l'exécution manuelle des tâches peut s'avérer coûteuse et fastidieuse. Pour effectuer une migration, plusieurs outils sont généralement utilisés, tels que les suivants : + Découverte + Mise en œuvre des migrations + Base de données de gestion de configuration (CMDB) + Feuille de calcul d'inventaire + Gestion de projets Ces outils sont utilisés à différentes étapes des migrations, de l'évaluation à la mobilisation en passant par la mise en œuvre. La sélection de ces outils est dictée par les objectifs commerciaux et les délais. Une fois les phases de migration planifiées, l'étape suivante consiste à s'assurer que l'équipe de migration possède les compétences nécessaires pour utiliser les outils dont elle aura besoin. Si une équipe n'a pas les compétences ou l'expérience nécessaires, planifiez des formations ciblées pour améliorer ses compétences. Si possible, créez des événements permettant aux équipes d'acquérir de l'expérience avec les outils de migration dans un environnement sûr. Par exemple, existe-t-il des serveurs de laboratoire ou de bac à sable que les équipes peuvent migrer pour acquérir de l'expérience avec l'outillage ? Sinon, est-il acceptable que les charges de travail de développement initiales soient utilisées à des fins d'apprentissage ? ## Automatisation, suivi et intégration des outils **Contents** + [Automatisez la découverte des migrations pour réduire le temps nécessaire](#discovery) + [Automatisez les tâches répétitives](#repeating) + [Automatisez le suivi et le reporting pour accélérer la prise de décision](#decision) + [Découvrez les outils qui peuvent faciliter votre migration](#tooling) ### Automatisez la découverte des migrations pour réduire le temps nécessaire La plupart des grands programmes de migration commencent par comprendre l'étendue de la migration (ce qui doit être migré) et par l'élaboration d'une stratégie (comment elle sera migrée). La découverte en est un aspect important. Les points de métadonnées requis sont capturés pour former un arbre décisionnel relatif à la stratégie de migration. Pour migrer les charges de travail à un rythme soutenu, vous devez identifier et importer les métadonnées de migration requises dans vos processus de mise en œuvre, tels qu'une usine de migration. Un mécanisme entièrement automatisé pour extraire, transformer et charger (ETL) les métadonnées de migration réduit considérablement le temps et le niveau d'effort nécessaires au processus de découverte. Un client a développé un processus de saisie de données entièrement automatisé pour son usine de migration. Le plan de la vague de migration avec toutes les métadonnées de migration a été hébergé et maintenu dans une feuille de calcul sur Microsoft SharePoint. Lorsque des modifications ont été apportées à la source, une AWS Lambda fonction a été lancée pour charger les données dans l'usine de migration sans intervention manuelle. Ce processus de saisie automatique des données a permis au client de réduire le travail manuel, de minimiser les erreurs humaines et d'accélérer sa rapidité. Ils ont pu migrer plus de 1 000 serveurs vers AWS. ### Automatisez les tâches répétitives Au cours de la phase de mise en œuvre de la migration, de nombreux petits processus doivent être répétés fréquemment. Lorsque vous utilisez AWS Application Migration Service (MGN), par exemple, vous devez installer l'agent sur chaque serveur concerné par la migration. La création d'une usine de migration adaptée à vos besoins commerciaux et techniques spécifiques est le moyen le plus efficace d'atteindre l'efficacité et la rapidité nécessaires à la réussite d'une migration de grande envergure. Une usine de migration fournit un cadre d'intégration et d'orchestration qui utilise un ensemble de données standardisé pour accélérer la migration. Une fois toutes les tâches identifiées, consacrez du temps à automatiser toutes les tâches manuelles qui peuvent être automatisées parallèlement aux runbooks prescriptifs. La solution [Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) en est un exemple. Cloud Migration Factory est conçu pour fournir les bases de l'automatisation de la migration sur lesquelles vous pouvez automatiser les aspects spécifiques à votre organisation. Par exemple, vous souhaiterez peut-être mettre à jour un indicateur dans votre CMDB pour indiquer que les serveurs locaux peuvent désormais être mis hors service. Dans ce scénario, vous pouvez créer une automatisation qui exécute cette tâche à la fin de la vague de migration. Cloud Migration Factory dispose d'un magasin de métadonnées centralisé contenant toutes les métadonnées des vagues, des applications et des serveurs. Le script d'automatisation peut se connecter à Cloud Migration Factory pour obtenir une liste des serveurs de cette vague et effectuer les actions correspondantes. Cloud Migration Factory prend en charge [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html). ### Automatisez le suivi et le reporting pour accélérer la prise de décision Nous vous recommandons de créer un tableau de bord de reporting de migration automatisé pour suivre et rapporter les données en temps réel, y compris les indicateurs de performance clés (KPIs) du programme. Les projets de migration impliquent des parties prenantes de l'ensemble de l'organisation, notamment les suivantes : + Équipes de candidature + Testeurs + Équipes de mise hors service + Architectes + Équipes d'infrastructure + Direction Pour remplir leur rôle, ces parties prenantes ont besoin de données en temps réel. Par exemple, les équipes réseau doivent connaître les prochaines vagues de migration pour comprendre l'impact sur la connexion partagée entre les ressources locales et AWS. Les équipes de direction veulent savoir dans quelle mesure la migration est terminée. Le fait de disposer d'un flux de données en direct fiable et automatisé permet d'éviter les problèmes de communication et de fournir une base sur laquelle les décisions peuvent être prises. Un important client du secteur de la santé préparait la sortie d'un centre de données dont la date limite était proche. Compte tenu de l'ampleur et de la complexité, un temps considérable a été initialement consacré au suivi et à la communication de l'état de la migration entre les parties prenantes. L'équipe de migration a ensuite utilisé [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) pour créer des tableaux de bord automatisés qui visualisaient les données, simplifiant ainsi considérablement le suivi et les communications tout en augmentant la vitesse de migration. ### Découvrez les outils qui peuvent faciliter votre migration Il n'est pas facile de choisir les bons outils pour votre migration, surtout si aucun membre de votre organisation n'a encore géré une migration de grande envergure. Nous vous recommandons de prendre le temps de choisir l'outillage approprié pour prendre en charge la migration. Cette exploration peut entraîner un coût de licence, mais elle peut présenter un avantage financier si l'on considère l'initiative dans son ensemble. Vous pourriez également constater que les outils intégrés à votre organisation peuvent fournir un résultat similaire. Par exemple, vous disposez peut-être déjà d'outils de surveillance des performances des applications déployés dans votre parc, qui peuvent fournir de riches informations de découverte. Un client du secteur des technologies était initialement réticent à utiliser des outils de découverte automatisés lors de sa migration en raison d'un manque de familiarité. Par conséquent, un AWS partenaire SI a dû organiser 5 à 10 heures de réunions par application pour découvrir manuellement le parc, y compris les noms des serveurs, les versions du système d'exploitation et les dépendances. Il a été estimé que si des outils de découverte avaient été utilisés, l'effort de découverte aurait pu être réduit de plus de 1 000 heures. ## Conditions préalables et validation après la migration **Contents** + [Construisez la zone d'atterrissage pendant la phase de pré-migration](#landing-zone) + [Décrire les activités préalables](#outline) + [Mettre en œuvre des contrôles après la migration pour une amélioration continue](#post-checks) ### Construisez la zone d'atterrissage pendant la phase de pré-migration Nous vous recommandons de créer l'environnement AWS cible, ou zone d'atterrissage, à l'avance, plutôt que de créer les clouds privés virtuels (VPCs) et les sous-réseaux cibles pendant la vague de migration. La création d'une zone d'atterrissage bien conçue est une condition préalable à la migration. La zone d'atterrissage doit inclure la surveillance, la gouvernance, les contrôles opérationnels et de sécurité. La création et la validation de la zone d'atterrissage avant la migration minimisent l'incertitude liée à l'exécution de vos charges de travail dans un nouvel environnement. Une fois la zone de landing zone en place, les parties prenantes peuvent se concentrer sur la migration des charges de travail sans se soucier des aspects gérés au niveau du compte ou du VPC. ### Décrire les activités préalables Outre la zone d'atterrissage, il est important d'aligner les autres prérequis techniques avant la migration, en particulier les processus nécessitant de longs délais. Par exemple, apportez les modifications nécessaires au pare-feu pour permettre la réplication des données sur site vers AWS. La communication précoce des prérequis techniques permet de préparer et d'allouer les ressources nécessaires. Il est fréquent que les migrations soient bloquées parce que les conditions préalables ne sont pas remplies. Cela a non seulement un impact sur la vague de migration en cours, mais cela peut également repousser les dates de toutes les migrations futures pendant que le problème est en cours de résolution. Une société de services financiers avait l'intention d'effectuer une migration massive vers AWS, dans le but de libérer plusieurs centres de données. Cependant, leur bande passante était disponible entre les sites et n' AWS était pas suffisante pour atteindre la vitesse prévue. Malheureusement, l'augmentation de la bande passante a nécessité une nouvelle connexion et a nécessité un délai de trois mois. Cela signifie que la vitesse de migration a été limitée pendant les trois premiers mois. ### Mettre en œuvre des contrôles après la migration pour une amélioration continue Enfin, n'oubliez pas de mettre en œuvre des validations après la migration, telles que l'intégration des opérations, l'optimisation des coûts et les contrôles de gouvernance et de conformité. La validation après la migration inclut l'évaluation des charges de travail précédemment migrées afin de découvrir les leçons techniques apprises qui devraient être appliquées aux futures vagues. De plus, c'est une excellente occasion de mettre en œuvre des opérations de contrôle des coûts. Par exemple, lors de la migration, vous pouvez décider de faire correspondre la taille des AWS instances à celle de votre parc sur site afin de réduire le besoin de tests de performance. Maintenant que les tests ne constituent plus la phase critique de fermeture du centre de données, vous pouvez utiliser Amazon CloudWatch pour évaluer l'utilisation de l'instance et déterminer si une instance de plus petite taille convient. Pour illustrer l'importance de cette phase, un grand client technologique effectuait une migration importante mais n'avait initialement pas inclus de validations après la migration. Après avoir migré plus de 100 serveurs, ils ont constaté que l' AWS Systems Manager agent (agent SSM) n'était pas configuré correctement. Tous les serveurs précédemment migrés ont dû être corrigés, et la migration a été bloquée. Le client a également constaté que le volume des instances était jusqu'à cinq fois supérieur aux estimations initiales. Il a donc mis en place un point de contrôle des coûts à la fin de chaque vague de migration. # Perspective du processus Les processus apportent de la cohérence, mais ils évoluent également et sont susceptibles de changer car chaque projet est unique. Au fur et à mesure que vous exécuterez le processus à plusieurs reprises, vous identifierez les lacunes et les possibilités d'amélioration susceptibles d'apporter d'énormes avantages en cas d'échec, d'apprentissage, d'adoption et d'itération. Ces changements peuvent mener à de nouvelles idées ou à des innovations dont le projet et l'entreprise pourront tirer parti à l'avenir, ce qui constitue un catalyseur de croissance qui apporte qualité et confiance aux équipes. Les processus de migration peuvent être complexes car ils transcendent des technologies et des frontières qui n'étaient peut-être pas liées auparavant. Cette perspective fournit des processus et des conseils sur les exigences spécifiques pour les grandes migrations. ## Préparation de votre migration de grande envergure Les sections suivantes décrivent les principes de base nécessaires pour vous assurer de démarrer votre processus de migration avec une direction claire et l'adhésion des parties prenantes, ce qui sera essentiel à sa réussite. **Contents** + [Définissez les moteurs commerciaux et communiquez le calendrier, le champ d'application et la stratégie](#bus-drivers) + [Définissez un chemin d'escalade clair pour aider à éliminer les bloqueurs](#escalation) + [Minimiser les changements inutiles](#change) + [Documenter et end-to-end traiter rapidement](#end-to-end) + [Documenter les modèles et artefacts de migration standard](#artifacts) + [Établissez une source fiable unique pour les métadonnées et le statut de la migration](#metadata) ### Définissez les moteurs commerciaux et communiquez le calendrier, le champ d'application et la stratégie Lorsque vous abordez une migration importante vers AWS, vous découvrirez rapidement qu'il existe de nombreuses façons de migrer vos serveurs. Par exemple, vous pouvez effectuer les opérations suivantes : + Réhébergez les charges de travail à l'aide de. [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) + Conteneurisez votre application et hébergez-la sur la plateforme de [conteneurs gérés Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) ou [Amazon Elastic Kubernetes Service (Amazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) EKS). + Redéfinissez votre charge de travail pour en faire une application entièrement sans serveur. Pour déterminer la bonne voie de migration, il est important de prendre en compte les facteurs déterminants pour votre activité. Si votre objectif ultime est d'accroître l'agilité de votre entreprise, vous pouvez privilégier les deux autres modèles, qui impliquent davantage de niveaux de transformation. Si votre objectif est de quitter un centre de données d'ici la fin de l'année, vous pouvez choisir de réhéberger les charges de travail en raison de la rapidité du réhébergement. Une migration de grande envergure implique généralement un large éventail de parties prenantes, notamment les suivantes : + Propriétaires de l'application + Équipes du réseau + Administrateurs de base de données + Sponsors exécutifs Il est essentiel d'identifier les moteurs commerciaux de la migration et d'inclure cette liste dans un document, tel qu'une charte de projet accessible aux membres du programme de migration. En outre, créez des indicateurs de performance clés (KPIs) étroitement liés à vos résultats commerciaux cibles. Par exemple, un client souhaitait migrer 2 000 serveurs en 12 mois pour atteindre son objectif commercial, à savoir quitter son centre de données. Cependant, leurs équipes de sécurité n'étaient pas alignées sur cet objectif. Le résultat a donné lieu à plusieurs mois de débats techniques sur l'opportunité de ne pas respecter la date de fermeture du centre de données tout en modernisant davantage les applications ou de le réhéberger dans un premier temps pour permettre la fermeture rapide du centre de données, puis de moderniser les AWS applications. ### Définissez un chemin d'escalade clair pour aider à éliminer les bloqueurs Les grands programmes de migration vers le cloud impliquent généralement un large éventail de parties prenantes. Après tout, vous êtes susceptible de modifier des applications hébergées sur site depuis plusieurs décennies. Il est courant que chacune des parties prenantes ait des priorités contradictoires. Bien que toutes les priorités puissent générer de la valeur, le programme sera probablement doté d'un budget limité et d'un résultat cible défini. Il peut être difficile de gérer les différentes parties prenantes et de se concentrer sur les résultats commerciaux cibles. Ce défi est encore aggravé lorsque vous le multipliez par les centaines ou les milliers d'applications concernées par la migration. En outre, les parties prenantes relèvent probablement de différentes équipes de direction, qui ont d'autres priorités. Dans cette optique, en plus de documenter clairement les résultats commerciaux cibles, il est important de définir une matrice d'escalade claire pour aider à éliminer les obstacles. Cela permet de gagner beaucoup de temps et d'aider à aligner les différentes équipes sur un objectif commun. C'est le cas, par exemple, d'une société de services financiers dont l'objectif était de quitter son centre de données principal dans les 12 mois. Il n'y avait pas de mandat clair ni de trajectoire d'escalade, ce qui a amené les parties prenantes à élaborer les voies de migration souhaitées, quelles que soient les contraintes de temps et de budget. À la suite d'une escalade auprès du CIO, un mandat clair a été défini et un mécanisme a été mis en place pour demander les décisions requises. ### Minimiser les changements inutiles Le changement est une bonne chose, mais plus il y a de changements, c'est plus de risques. Lorsque l'analyse de rentabilisation de la migration à grande échelle est approuvée, il est fort probable que cette initiative soit motivée par un résultat commercial cible, tel que la libération d'un centre de données à une date précise. Bien qu'il soit courant que les technologues souhaitent tout réécrire pour tirer pleinement parti des AWS services, ce n'est peut-être pas votre objectif commercial. Un client s'est concentré sur une migration de deux ans de l'ensemble de l'infrastructure Web de l'entreprise vers AWS. Ils ont créé une règle des deux semaines afin d'empêcher les équipes chargées des applications de passer des mois à réécrire leurs candidatures. En utilisant la règle des deux semaines, le client a pu effectuer une migration à long terme à une cadence constante lorsque des centaines d'applications devaient être déplacées sur une période de plusieurs années. Pour plus d'informations, consultez le billet de blog [La règle des deux semaines : refactorisez vos applications pour le cloud en 10](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/) jours. Nous recommandons de minimiser tout changement qui ne correspond pas aux résultats commerciaux. Créez plutôt des mécanismes pour gérer ces changements supplémentaires dans les futurs projets. ### Documenter et end-to-end traiter rapidement Documentez le processus complet de migration et l'attribution de propriété dès les premières étapes d'un vaste programme de migration. Cette documentation est importante pour informer toutes les parties prenantes sur le fonctionnement de la migration ainsi que sur leurs rôles et responsabilités. La documentation vous aidera également à comprendre où des problèmes peuvent survenir et à fournir des mises à jour et des itérations du processus au fur et à mesure que vous progressez dans les migrations. Pendant le développement du projet de migration, assurez-vous que tous les processus existants sont compris et que les points d'intégration et les dépendances sont clairement documentés. Incluez les endroits où l'engagement avec les responsables de processus externes sera requis, notamment les demandes de modification, les demandes de service, le support des fournisseurs et le support du réseau et du pare-feu. Une fois le processus compris, nous recommandons de documenter la propriété dans une matrice responsable, responsable, consultée et informée (RACI) afin de suivre les différentes activités. Pour finaliser le processus, établissez un plan de compte à rebours en identifiant les délais nécessaires à chaque étape de la migration. Le compte à rebours fonctionne généralement à rebours à partir de la date et de l'heure de transition de la charge de travail. Cette approche de documentation a bien fonctionné pour une multinationale d'appareils électroménagers qui a migré AWS avec succès vers quatre centres de données en moins d'un an et a quitté quatre centres de données. Six équipes organisationnelles différentes et plusieurs tiers y ont participé, ce qui a entraîné des frais de gestion supplémentaires, ce qui a entraîné des back-and-forth décisions et des retards dans la mise en œuvre. L'équipe des services AWS professionnels, en collaboration avec le client et ses tiers, a identifié les processus clés pour les activités de migration et les a documentés auprès des propriétaires respectifs. La matrice RACI qui en a résulté a été partagée et approuvée par toutes les équipes impliquées. À l'aide de la matrice RACI et d'une matrice d'escalade, le client a atténué les obstacles et les problèmes à l'origine des retards. Ils ont ensuite pu quitter les centres de données plus tôt que prévu. Dans un autre exemple d'utilisation du RACI et de matrices d'escalade, une compagnie d'assurance a pu quitter le centre de données en moins de 4 mois. Le client a compris et mis en œuvre un modèle de responsabilité partagée, et une matrice RACI détaillée a été suivie pour suivre la progression de chaque processus et activité tout au long de la migration. Le client a ainsi pu migrer plus de 350 serveurs au cours des 12 premières semaines de mise en œuvre. ### Documenter les modèles et artefacts de migration standard Pensez à cela comme à la création d'emporte-pièces pour la mise en œuvre. Les références, la documentation, les runbooks et les modèles réutilisables sont la clé de l'évolutivité. Ils décrivent les expériences, les enseignements, les pièges, les problèmes et les solutions que les futurs projets de migration peuvent réutiliser et éviter, accélérant ainsi considérablement la migration. Les modèles et les artefacts constituent également un investissement qui permettra d'améliorer le processus et d'orienter les futurs projets. Par exemple, un client effectuait une migration d'un an au cours de laquelle les applications étaient migrées par trois partenaires SI AWS différents. Au début, chaque AWS partenaire utilisait ses propres normes, runbooks et artefacts. Cela a imposé de nombreuses contraintes aux équipes clients, car les mêmes informations pouvaient leur être présentées de différentes manières. Après ces premières difficultés, le client a établi la propriété centralisée de toute la documentation et de tous les artefacts à utiliser dans le cadre de la migration, avec un processus de soumission des modifications recommandées. Ces actifs sont notamment les suivants : + Un processus de migration standard et des listes de contrôle + Normes de style et de format des diagrammes de réseau + Normes d'architecture et de sécurité des applications basées sur la criticité de l'entreprise En outre, les modifications apportées à l'un de ces documents et normes étaient envoyées à toutes les équipes chaque semaine, et chaque partenaire était tenu de confirmer la réception et le respect de toutes les modifications. Cela a considérablement amélioré la communication et la cohérence du projet de migration, et lorsqu'un important effort de migration distinct a été lancé dans une autre unité commerciale, cette équipe a pu adopter le processus et les documents existants, accélérant ainsi considérablement son succès. ### Établissez une source fiable unique pour les métadonnées et le statut de la migration Lorsqu'il s'agit de planifier une migration de grande envergure, il est important d'établir une source fiable pour maintenir l'alignement des différentes équipes et permettre des décisions basées sur les données. Au début de cette aventure, vous trouverez peut-être de nombreuses sources de données que vous pourrez utiliser, telles que la base de données de gestion des configurations (CMDB), les outils de surveillance des performances des applications, les listes d'inventaire, etc. Il se peut également que vous constatiez qu'il existe peu de sources de données et que vous deviez créer des mécanismes pour recueillir les données nécessaires. Par exemple, vous devrez peut-être utiliser des outils de découverte pour découvrir des informations techniques et pour interroger les responsables informatiques afin d'obtenir des informations commerciales. Il est important d'agréger les différentes sources de données dans un seul jeu de données que vous pouvez utiliser pour la migration. Vous pouvez ensuite utiliser la source fiable unique pour suivre la migration pendant la mise en œuvre. Par exemple, vous pouvez suivre les serveurs qui ont été migrés. Un client des services financiers qui souhaitait migrer toutes ses charges de travail s' AWS est concentré sur la planification de la migration avec le jeu de données fourni. Cet ensemble de données présentait des lacunes importantes, telles que des informations sur la criticité et la dépendance de l'entreprise. Le programme a donc lancé un exercice de découverte. Dans un autre exemple, une entreprise du même secteur s'est lancée dans la mise en œuvre de la vague de migration sur la base d'une out-of-date compréhension de son inventaire d'infrastructures de serveurs. Ils ont rapidement commencé à voir le nombre de migrants diminuer parce que les données étaient incorrectes. Dans ce cas, les propriétaires des applications n'ont pas été compris, ce qui signifie qu'ils n'ont pas pu trouver de testeurs à temps. En outre, les données n'étaient pas adaptées à la mise hors service effectuée par leurs équipes chargées des applications, de sorte que les serveurs fonctionnaient sans être utilisés à des fins commerciales. ## Exécution de votre migration de grande envergure Une fois que vous avez défini les résultats de votre entreprise et communiqué la stratégie aux parties prenantes, vous pouvez passer à la planification de la manière dont vous répartissez l'ampleur de la migration en événements ou en vagues de migration durable. Les exemples suivants fournissent des conseils essentiels pour l'élaboration du plan de vague. **Contents** + [Planifiez les vagues de migration à l'avance pour garantir un flux constant](#plan-waves) + [Conservez la mise en œuvre des vagues et la planification des vagues en tant que processus et équipes distincts](#separate) + [Commencez petit pour obtenir d'excellents résultats](#start-small) + [Minimiser le nombre de fenêtres inversées](#cutover-numbers) + [Échouez rapidement, appliquez votre expérience et itérez](#iterate) + [N'oubliez pas la rétrospective](#retrospective) ### Planifiez les vagues de migration à l'avance pour garantir un flux constant La planification de votre migration est l'une des phases les plus importantes du programme. Cela va de pair avec le dicton « si vous ne planifiez pas, vous planifiez l'échec ». La planification des vagues de migration à l'avance permet au projet de se dérouler rapidement à mesure que l'équipe devient plus proactive face à la situation migratoire. Cela facilite l'évolution du projet et améliore la prise de décision et les prévisions à mesure que les exigences du projet augmentent et deviennent complexes. La planification à l'avance améliore également la capacité de l'équipe à s'adapter aux changements. Par exemple, un important client des services financiers travaillait sur un programme de sortie de centre de données. Au départ, le client a planifié les vagues de migration de manière séquentielle, en achevant une vague avant de commencer à planifier la suivante. Cette approche a permis de réduire le temps de préparation. Lorsque les parties prenantes ont été informées que leurs applications étaient en cours de migration AWS, il leur restait encore plusieurs étapes à effectuer avant de commencer la migration. Cela a entraîné des retards importants dans le programme. Une fois que le client s'en est rendu compte, il a mis en œuvre un flux de planification de migration holistique et axé sur l'avenir, dans le cadre duquel les vagues de migration étaient planifiées plusieurs mois à l'avance. Cela a permis aux équipes chargées des applications d'effectuer leurs activités préalables à la migration, telles que la notification AWS des partenaires, l'analyse des licences, etc. Ils pourraient ensuite supprimer ces tâches du chemin critique du programme. ### Conservez la mise en œuvre des vagues et la planification des vagues en tant que processus et équipes distincts Lorsque les équipes de planification et de mise en œuvre des vagues sont séparées, les deux processus peuvent fonctionner en parallèle. Grâce à la communication et à la coordination, cela permet d'éviter de ralentir la migration car trop peu de serveurs ou d'applications sont prêts à atteindre la vitesse attendue. Par exemple, l'équipe de migration peut avoir besoin de migrer 30 serveurs par semaine, mais seuls 10 serveurs sont prêts pour la vague actuelle. Ce défi est souvent dû aux facteurs suivants : + L'équipe de mise en œuvre de la migration n'a pas participé à la planification de la vague, et les données collectées lors de la phase de planification de la vague ne sont pas complètes. L'équipe de mise en œuvre de la migration doit collecter davantage de données sur le serveur avant de démarrer la vague. + La mise en œuvre de la migration devrait commencer juste après la planification des vagues, sans aucune zone tampon entre les deux. Il est essentiel de planifier les vagues à l'avance et de créer une zone tampon entre la préparation et le début de la mise en œuvre des vagues. Il est également important de s'assurer que l'équipe de planification des vagues et l'équipe de migration travaillent ensemble pour collecter les bonnes données et éviter les retouches. ### Commencez petit pour obtenir d'excellents résultats Prévoyez de commencer modestement et d'augmenter la vitesse de migration à chaque vague suivante. La vague initiale doit être une seule petite application comportant moins de 10 serveurs. Ajoutez des applications et des serveurs supplémentaires au cours des vagues suivantes, pour atteindre votre vitesse de migration maximale. En donnant la priorité aux applications moins complexes ou moins risquées et en accélérant la vitesse selon un calendrier, l'équipe a le temps de s'adapter à la collaboration et d'apprendre le processus. En outre, l'équipe peut identifier et mettre en œuvre des améliorations de processus à chaque vague, ce qui peut améliorer considérablement la vitesse des vagues ultérieures. Un client a migré plus de 1 300 serveurs en un an. En commençant par une migration pilote et quelques vagues plus petites, l'équipe de migration a pu identifier plusieurs moyens d'améliorer les migrations ultérieures. Par exemple, ils ont identifié de nouveaux segments de réseau de centres de données plus tôt. Ils ont travaillé avec leur équipe de pare-feu au début du processus pour mettre en place des règles de pare-feu permettant la communication avec les outils de migration. Cela a permis d'éviter des retards inutiles lors des prochaines vagues. En outre, l'équipe a pu développer des scripts pour automatiser davantage ses processus de découverte et de transition à chaque vague. Commencer modestement a permis à l'équipe de se concentrer sur l'amélioration précoce des processus et a considérablement accru leur confiance. ### Minimiser le nombre de fenêtres inversées Les migrations de masse nécessitent une approche disciplinée pour générer de l'ampleur. Le fait d'être trop flexible dans certains domaines constitue un contre-modèle pour les grandes migrations. En limitant le nombre de fenêtres de transition hebdomadaires, le temps consacré aux activités de transition a une plus grande valeur. Par exemple, si la fenêtre de transition est trop flexible, vous pourriez vous retrouver avec 20 découpes avec cinq serveurs chacune. Au lieu de cela, vous pourriez avoir deux cutovers de 50 serveurs chacun. Étant donné que le temps et les efforts nécessaires pour chaque transition sont similaires, le fait de réduire le nombre de tranches plus importantes réduit le fardeau opérationnel lié à la planification et limite les retards inutiles. Une grande entreprise technologique essayait de quitter quelques centres de données loués avant l'expiration de son contrat. Le fait de ne pas respecter l'expiration entraînerait des conditions de renouvellement coûteuses et de courte durée. Au début de la migration, les équipes chargées des applications étaient autorisées à dicter le calendrier de migration jusqu'à la dernière minute, y compris à refuser la migration pour quelque raison que ce soit, quelques jours avant le passage à la norme. Cela a entraîné de nombreux retards dans les premières étapes du projet. Souvent, le client a dû négocier avec d'autres équipes de candidature à la dernière minute pour remplir le formulaire. Le client a fini par renforcer sa discipline de planification, mais cette erreur précoce a entraîné un stress constant pour l'équipe de migration. Des retards dans le calendrier global ont empêché certaines applications de sortir des centres de données à temps. ### Échouez rapidement, appliquez votre expérience et itérez Au départ, chaque migration comporte des embûches. Un échec précoce aide l'équipe à apprendre, à comprendre les obstacles et à appliquer les leçons apprises à des vagues plus importantes. On s'attend à ce que les deux premières vagues d'une migration soient lentes pour les raisons suivantes : + Les membres de l'équipe s'adaptent les uns aux autres et au processus. + Les grandes migrations impliquent généralement de nombreux outils et personnes différents. + Il faut du temps pour intégrer, tester, échouer, apprendre et améliorer continuellement le end-to-end processus. Les problèmes sont courants et attendus au cours des deux premières vagues. Il est important de le comprendre et de le communiquer à l'ensemble de l'organisation, car certaines équipes peuvent ne pas aimer essayer de nouvelles choses et échouer. Un échec peut décourager l'équipe et bloquer les futures migrations. S'assurer que tout le monde comprend que les problèmes initiaux font partie du travail et encourager tout le monde à essayer et à échouer est la clé d'une migration réussie. Une entreprise prévoyait de migrer plus de 10 000 serveurs en 24 à 36 mois. Pour atteindre cet objectif, ils devaient migrer près de 300 serveurs par mois. Toutefois, cela ne signifie pas qu'ils ont migré 300 serveurs dès le premier jour. Les deux premières vagues étaient des vagues d'apprentissage afin que l'équipe puisse comprendre comment les choses fonctionnaient et qui était autorisé à faire quoi. Ils ont également identifié des intégrations susceptibles d'améliorer le processus, telles que l'intégration avec CMDB et. CyberArk Ils ont utilisé les vagues d'apprentissage pour échouer, s'améliorer et échouer à nouveau, en affinant le processus et en automatisant le processus. Au bout de 6 mois, ils ont pu migrer plus de 120 serveurs par semaine. ### N'oubliez pas la rétrospective Il s'agit d'un élément important d'un processus agile. C'est là que l'équipe communique, s'adapte, apprend, accepte et avance. Une rétrospective au niveau le plus élémentaire consiste à regarder en arrière, à discuter de ce qui s'est passé, à déterminer ce qui s'est bien passé et ce qui doit être amélioré. Des améliorations peuvent ensuite être apportées sur la base de ces discussions. Les rétrospectives intègrent une certaine formalité ou un processus autour de l'idée des leçons apprises. Les rétrospectives sont importantes car pour atteindre l'ampleur et la rapidité nécessaires à la réussite des migrations de grande envergure, les processus, les outils et les équipes doivent constamment évoluer et s'améliorer. Les rétrospectives peuvent jouer un rôle important à cet égard. Les sessions traditionnelles sur les leçons apprises n'ont pas lieu avant la fin d'un programme, si bien que ces leçons ne sont souvent pas révisées au début de la prochaine vague migratoire. Dans le cas de grandes migrations, les leçons apprises devraient être appliquées à la prochaine vague et devraient constituer un élément clé du processus de planification des vagues. Pour un client, des rétrospectives hebdomadaires ont été organisées pour discuter et documenter les leçons tirées des ruptures. Au cours de ces sessions, ils ont découvert des domaines dans lesquels il était possible de rationaliser les processus ou d'automatiser les processus. Cela a entraîné la mise en œuvre d'un calendrier de compte à rebours avec des activités, des propriétaires et des scripts d'automatisation spécifiques afin de minimiser les tâches manuelles, notamment la validation d'outils tiers et l'installation d' CloudWatch agents Amazon, lors du passage à la technologie. Dans une autre grande entreprise technologique, des rétrospectives régulières ont été organisées avec l'équipe afin d'identifier les problèmes liés aux vagues de migration précédentes. Cela s'est traduit par des améliorations des processus, des scripts et de l'automatisation qui ont permis de réduire le temps de migration moyen de 40 % au cours du programme. ## Considérations supplémentaires De nombreux domaines doivent être pris en compte dans un vaste programme de migration. Les sections suivantes fournissent des idées sur d'autres éléments qui doivent être pris en compte. **Contents** + [Nettoyez au fur et à mesure](#clean-up) + [Implémenter plusieurs phases pour toute transformation supplémentaire](#phases) ### Nettoyez au fur et à mesure Une migration n'est pas considérée comme réussie si son coût est 10 fois supérieur à ce que vous attendiez et si le projet n'est pas terminé tant que les ressources utilisées pour la migration ne sont pas arrêtées et nettoyées. Ce nettoyage doit faire partie de l'activité post-migration. Cela garantit que vous ne laisserez pas de ressources et de services inutilisés dans votre environnement, ce qui augmentera les coûts. Le nettoyage après migration est également une bonne pratique de sécurité pour prévenir les menaces et les vulnérabilités qui exposent votre environnement. Les deux principaux résultats du passage à la AWS Cloud sont les économies de coûts et la sécurité. Le fait de laisser des ressources inutilisées peut aller à l'encontre de l'objectif commercial de la migration vers le cloud. Les ressources les plus courantes qui ne sont pas nettoyées sont les suivantes : + Données de test + bases de données de test + Comptes de test, y compris les règles de pare-feu, les groupes de sécurité et les adresses IP des listes de contrôle d'accès réseau (ACL) + Ports provisionnés pour les tests + Volumes Amazon Elastic Block Store (Amazon EBS) + Instantanés + Réplication (par exemple, arrêt de la réplication des données sur site vers AWS) + Fichiers consommant de l'espace (tels que les sauvegardes de base de données temporaires utilisées pour la migration) + Instances hébergeant les outils de migration Dans un exemple de mauvaises pratiques de nettoyage, les AWS partenaires SI ne supprimaient pas les agents de réplication après une migration réussie. Un AWS audit a révélé que les serveurs de réplication et les volumes EBS déjà migrés coûtaient 20 000 dollars américains par mois. Pour atténuer le problème, les services AWS professionnels ont créé un processus d'audit automatisé qui avertissait les AWS partenaires SI lorsque des serveurs obsolètes étaient toujours en cours de réplication. Les AWS partenaires SI pourraient alors prendre des mesures sur les instances inutilisées et périmées. Pour les futures migrations, un processus a été adopté pour définir une période d'hypersoin de 48 heures après la migration afin de garantir une adoption fluide de la plateforme. L'équipe d'infrastructure du client a ensuite soumis une demande de mise hors service pour les serveurs sur site. Il a été informé qu'une fois la demande de mise hors service approuvée, les serveurs de la vague correspondante seraient retirés de la console du service de migration des applications. ### Implémenter plusieurs phases pour toute transformation supplémentaire Lorsque vous effectuez une migration de grande envergure, il est important de rester concentré sur votre objectif principal, comme la fermeture du centre de données ou la transformation de l'infrastructure. Dans le cas de migrations de moindre envergure, le changement de portée peut avoir un impact minimal. Cependant, quelques jours d'efforts supplémentaires multipliés par des milliers de serveurs peuvent prolonger considérablement le programme. En outre, les modifications supplémentaires peuvent également nécessiter des mises à jour de la documentation, des processus et de la formation des équipes de support. Pour éviter une éventuelle modification du périmètre, vous pouvez mettre en œuvre une approche en plusieurs phases pour votre migration. Par exemple, si votre objectif était de quitter un centre de données, la phase 1 peut inclure uniquement le réhébergement de la charge de travail le AWS plus rapidement possible. Une fois la charge de travail réhébergée, la phase 2 permet de mettre en œuvre des activités de transformation sans compromettre le résultat commercial cible. Par exemple, un client prévoyait de quitter son centre de données dans les 12 mois. Cependant, leur migration a englobé d'autres activités de transformation, telles que le déploiement de nouveaux outils de surveillance des performances des applications et la mise à niveau des systèmes d'exploitation. Plus de 1 000 serveurs étaient concernés par la migration. Ces activités ont donc considérablement retardé la migration. De plus, cette approche nécessitait une formation à l'utilisation du nouvel outillage. Le client a ensuite décidé de mettre en œuvre une approche en plusieurs phases en se concentrant initialement sur le réhébergement. Cela a accéléré leur migration et réduit le risque de ne pas respecter la date de fermeture du centre de données.