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. # Le processus de migration vers Cloud Migration Factory Processus de migration Le processus Cloud Migration Factory comprend cinq étapes principales. Elles sont abordées dans les sections suivantes : + [Étape 1. Préparez le fichier CSV et importez les données dans Cloud Migration Factory](step1.md) + [Étape 2. Construisez les serveurs](step2.md) + [Étape 3. Valider la migration](step3.md) + [Étape 4. Réaliser des tests de démarrage liés à la migration](step4.md) + [Étape 5. Passez aux nouvelles instances de serveur sur AWS](step5.md) **Important** Les scripts d'automatisation pour les étapes de migration décrites dans ce guide nécessitent Cloud Migration Factory. Pour obtenir Cloud Migration Factory, consultez la [solution AWS Cloud Migration Factory](https://aws.amazon.com/solutions/implementations/cloud-migration-factory-on-aws/) sur le site Web AWS des solutions. Si vous avez des questions, envoyez un e-mail aux services AWS professionnels à l'adresse [migration-factory-support@amazon .com](mailto:migration-factory-support@amazon.com). # Étape 1. Préparez le fichier CSV et importez les données dans Cloud Migration Factory La première étape d'une migration à grande échelle consiste à préparer les métadonnées de l'application et du serveur. Ces métadonnées sont généralement collectées à partir de l'analyse du portefeuille et de la planification des vagues, et placées dans un fichier de valeurs séparées par des virgules (CSV). Vous utilisez les métadonnées pour automatiser le processus de migration et pour mettre à jour les modèles de lancement Amazon Elastic Compute Cloud (Amazon EC2) afin de lancer des instances EC2 cibles. Le fichier CSV par défaut que nous fournirons inclut les attributs suivants : + `wave_name`— ID de vague unique, basé sur la priorité et les dépendances. + `app_name`— Application à migrer. + `aws_region`— Cible Région AWS pour les machines sources. + `aws_accountid`— ID de compte à 12 chiffres du AWS compte de destination. + `server_name`— Serveur local à migrer. + `server_os_family`— Système d'exploitation (Windows ou Linux) exécuté sur le serveur local. + `server_os_version`— Version du système d'exploitation du serveur. + `server_fqdn`— Nom de domaine complet (FQDN) du serveur. + `server_tier`— Type de serveur (Web, application ou base de données). + `server_environment`— Environnement hôte pour le serveur (développement, test, production, assurance qualité, préproduction). + `r_type`— Stratégie de migration pour le serveur source, telle que le réhébergement ou la replateforme. + `subnet_IDs`— IDs des AWS sous-réseaux à utiliser pour les instances EC2 après le passage. + `securitygroup_IDs`— IDs des groupes AWS de sécurité à utiliser après le transfert. + `subnet_IDs_test`— IDs des AWS sous-réseaux à utiliser pour les tests. + `securitygroup_IDs_test`— IDs des groupes AWS de sécurité à utiliser pour les tests. + `instanceType`— [Type d'instance EC2](https://aws.amazon.com/ec2/instance-types/) à utiliser pour les serveurs. + `tenancy`— Si l'instance s'exécute sur du matériel partagé, sur du matériel à locataire unique (dédié) ou sur un serveur isolé (hôte dédié). + `tags`— AWS balises pour les instances EC2 cibles. Cloud Migration Factory inclut un script d'automatisation que vous exécutez sur le serveur d'exécution de la migration pour importer les métadonnées du fichier CSV vers Cloud Migration Factory. Pour obtenir des instructions détaillées, consultez la section [Importation de données](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/metadata-management.html#importing-data) dans le *guide de mise en œuvre de Cloud Migration Factory*. # Étape 2. Construisez les serveurs Après avoir importé les métadonnées de l'application et du serveur, vous vérifiez les machines sources et installez l'agent de réplication pour démarrer la réplication des données. ## Vérifier les conditions requises pour les serveurs sources Au cours de cette étape, vous vous assurez que vos serveurs sources disposent de la configuration requise pour démarrer la réplication des données. Par exemple, si le serveur source est un serveur Windows, il doit répondre aux exigences suivantes : + Le port TCP 443 sortant doit être ouvert pour que la machine source puisse se connecter à la AWS Application Migration Service console. + Le port TCP 1500 sortant doit être ouvert pour que la machine source puisse se connecter au serveur de réplication du service de migration d'applications dans le cloud privé virtuel (VPC) cible. AWS + Le serveur doit exécuter .NET Framework version 3.5 ou ultérieure. + Le serveur doit disposer d'au moins 3 Go d'espace libre sur le lecteur C. Cloud Migration Factory inclut un script d'automatisation que vous exécutez sur le serveur d'exécution de la migration pour vérifier automatiquement les conditions requises pour tous les serveurs sources Windows et Linux. Pour obtenir des instructions détaillées, consultez la section [Vérifier les prérequis](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#prerequisites-2) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Installation de l'agent de réplication Après avoir vérifié les conditions requises, vous installez l'agent de réplication sur les machines sources. Ce processus prend généralement 5 à 10 minutes par serveur, mais Cloud Migration Factory inclut un script d'automatisation pour envoyer les agents vers tous les serveurs sources au cours d'une même vague. Ce script fonctionne pour plusieurs cibles Régions AWS et Comptes AWS. Le script d'installation de l'agent utilise l' AWS API pour extraire le jeton d'installation pour la cible Compte AWS. Pour obtenir des instructions détaillées, consultez la section [Installation des agents de réplication](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#install-the-replication-agents) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Appuyez sur le script post-lancement L'une des tâches courantes de la migration de réhébergement consiste à désinstaller les anciens logiciels tels que les outils VMware et les logiciels de sauvegarde des instances EC2 cibles, et à installer de nouveaux logiciels tels que l'agent. AWS Systems Manager L'exécution manuelle de ces activités peut prendre de 15 à 30 minutes par serveur, mais Cloud Migration Factory automatise ce processus pour accélérer le temps de transition. Le service de migration d'applications prend en charge les scripts de post-lancement qui vous aident à exécuter automatiquement les tâches de configuration du système d'exploitation, telles que l'installation ou la désinstallation de logiciels. Pour obtenir des instructions détaillées, consultez la section [Envoyer les scripts post-lancement](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#push-the-post-launch-scripts) dans le *guide de mise en œuvre de Cloud Migration Factory*. # Étape 3. Valider la migration Après avoir installé l'agent de réplication sur les machines sources, vous surveillez l'état de la réplication des données et résolvez les problèmes tels que les autorisations ou les performances du réseau. S'il s'agit d'une petite migration, vous pouvez vérifier l'état de la réplication manuellement à partir de la console du service de migration des applications. Toutefois, si vous avez des migrations à grande échelle, des serveurs répartis sur plusieurs projets et des serveurs répartis sur plusieurs vagues, cette vérification peut s'avérer difficile. Par exemple, si vous avez 100 serveurs dans la phase 1, vous devez répéter les étapes suivantes 100 fois pour vérifier leur état de réplication : + Trouvez la cible Région AWS et Compte AWS le serveur. + Connectez-vous à la console du service de migration des applications, puis recherchez le nom du serveur. + Vérifiez la barre de progression et mettez à jour l'état du serveur sur votre feuille de calcul. Cloud Migration Factory inclut un script d'automatisation que vous exécutez une fois pour tous les serveurs. Le script réessaie toutes les 5 minutes jusqu'à ce que l'état de chaque serveur de la vague 1 passe à *Continuous Data Replication*, et il met à jour l'état de réplication dans la base de données Cloud Migration Factory. Pour obtenir des instructions détaillées, consultez [Vérifier l'état de réplication](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-replication-status) dans le *guide de mise en œuvre de Cloud Migration Factory*. # Étape 4 : Réaliser des tests de démarrage liés à la migration Une fois la réplication des données terminée sur tous les serveurs, vous devez tester le processus de démarrage de l'instance et vous assurer que tout fonctionne comme prévu du point de vue du système d'exploitation. En d'autres termes, l'instance EC2 doit réussir les vérifications de santé 2/2 (état du système et statut de l'instance). ## Lancez des serveurs pour les tests de démarrage Si vous migrez un petit nombre de serveurs, vous pouvez sélectionner le serveur et le lancer directement depuis la console Application Migration Service. Toutefois, pour les migrations à grande échelle, il est plus efficace de lancer tous les serveurs ensemble à partir de la console Web Cloud Migration Factory. Cette console fournit un seul bouton **Launch servers** pour automatiser les processus suivants : + Vérifier l'état de la réplication et s'assurer que le délai est inférieur à 180 minutes. + Mise à jour des modèles de lancement Amazon EC2 pour tous les serveurs de la vague donnée avec les métadonnées de la base de données Cloud Migration Factory. + Envoi de tous les serveurs vers une tâche du service de migration d'applications et lancement de ceux-ci en mode test. Pour obtenir des instructions détaillées, consultez la section [Launch instances for testing](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#launch-instances-for-testing) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Vérifier l'état de démarrage de l'instance Le démarrage des instances du serveur prendra entre 15 et 30 minutes. Vous pouvez vérifier l'état manuellement en vous connectant à la console Amazon EC2, en recherchant le nom du serveur et en vérifiant l'état. Vous verrez un message « 2/2 vérifications réussies », qui indique que l'instance est saine du point de vue de l'infrastructure. ![\[Verifying instance boot-up status in Cloud Migration Factory\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-factory-cloudendure/images/status-check.png) Cependant, pour une migration à grande échelle, la vérification de l'état de chaque instance prend du temps. Cloud Migration Factory fournit donc un script d'automatisation unique pour vérifier le statut 2/2 de toutes les machines d'une vague donnée. Si une instance échoue aux vérifications d'état 2/2, contactez le [AWS Support](https://aws.amazon.com/premiumsupport/) pour obtenir de l'aide. Pour obtenir des instructions détaillées, consultez [Vérifier l'état de l'instance cible](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-target-instance-status) dans le *guide de mise en œuvre de Cloud Migration Factory*. # Étape 5. Découper La dernière étape d'une migration de réhébergement classique consiste à planifier une période de transition et à préparer les ressources nécessaires à la prise en charge de cette transition. ## Vérifiez l'état de la réplication Tout d'abord, vous devez vérifier l'état de réplication et vous assurer que l'état de tous les serveurs de la vague donnée est sain. Comme à [l'étape 3](step3.md), vous pouvez exécuter un script Cloud Migration Factory pour automatiser cette étape. Le script réessaie toutes les 5 minutes jusqu'à ce que l'état de chaque serveur de la vague donnée passe à sain, et met à jour l'état de réplication dans la base de données Cloud Migration Factory. Pour obtenir des instructions détaillées, consultez [Vérifier l'état de réplication](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-replication-status) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Arrêtez les serveurs sources en vue de la transition Après avoir vérifié l'état de réplication des serveurs sources, vous êtes prêt à arrêter les serveurs sources pour arrêter les transactions entre les applications clientes et les serveurs. En général, vous pouvez arrêter les serveurs sources dans la fenêtre de transition. L'arrêt manuel des serveurs sources peut prendre 5 minutes par serveur et, pour les grandes vagues, cela peut prendre quelques heures au total. Au lieu de cela, vous pouvez exécuter un script d'automatisation Cloud Migration Factory pour arrêter tous vos serveurs au cours de la vague donnée. Pour obtenir des instructions détaillées, consultez la section [Arrêter les serveurs source concernés](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#shut-down-the-in-scope-source-servers) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Lancer des instances EC2 cibles pour le transfert Après avoir arrêté les serveurs sources, vous pouvez lancer les instances de serveur EC2 cibles. Comme à [l'étape 4](step4.md), vous pouvez utiliser un seul bouton **Launch servers** pour lancer tous les serveurs de la vague donnée en mode cutover. La seule différence ici est que vous choisissez **Cutover comme type** de lancement. Comme lors des tests de démarrage, le bouton **Lancer les serveurs** automatise les processus suivants : + Vérifier l'état de la réplication et s'assurer que le délai est inférieur à 180 minutes. + Mise à jour des modèles de lancement Amazon EC2 pour tous les serveurs de la vague donnée avec les métadonnées de la base de données Cloud Migration Factory. + Envoi de tous les serveurs vers une tâche du service de migration d'applications et lancement de ces derniers en mode basculement. Pour obtenir des instructions détaillées, consultez la section [Launch instances for cutover](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#launch-instances-for-cutover) dans le guide de mise en *œuvre de Cloud Migration Factory*. ## Vérifier l'état de démarrage de l'instance Après avoir lancé les instances en mode cutover, attendez au moins 15 minutes avant de passer à l'étape suivante, qui consiste à vérifier l'état de démarrage de l'instance. Lorsque le lancement du cutover est terminé, vous pouvez exécuter le script d'automatisation Cloud Migration Factory pour vérifier le statut 2/2 de toutes les machines de la vague donnée. Si une instance échoue aux vérifications d'état 2/2, contactez le [AWS Support](https://aws.amazon.com/premiumsupport/) pour obtenir de l'aide. Pour obtenir des instructions détaillées, consultez [Vérifier l'état de l'instance cible](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-target-instance-status) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## (Facultatif) Obtenez de nouvelles adresses IP pour les instances cibles Si les instances du serveur cible utilisent de nouvelles adresses IP, l'étape suivante consiste à mettre à jour le serveur DNS avec les nouvelles adresses IP. Dans certains scénarios, les instances cibles prennent en charge l'enregistrement DNS dynamique et enregistrent automatiquement la nouvelle adresse IP auprès du serveur DNS. Par exemple, si un serveur Windows utilise un contrôleur de domaine comme serveur DNS, l'enregistrement DNS peut être automatique. En revanche, si la mise à jour du DNS est un processus manuel, vous devez obtenir les nouvelles adresses IP pour toutes les instances cibles. Dans ce cas, vous pouvez utiliser le script d'automatisation Cloud Migration Factory pour exporter les nouvelles adresses IP de toutes les instances de la vague donnée vers un fichier CSV. Pour obtenir des instructions détaillées, consultez la section [Récupérer l'adresse IP de l'instance cible](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-command-prompt.html#retrieve-the-target-instance-ip) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Tester RDP/SSH l'accès aux serveurs cibles Après avoir mis à jour les enregistrements DNS, vous pouvez vous connecter aux instances cibles avec le nom d'hôte. Au cours de cette étape, vous vérifiez si vous pouvez vous connecter au système d'exploitation en utilisant le protocole RDP (Remote Desktop Protocol) ou via un accès Secure Shell (SSH). Vous pouvez vous connecter manuellement à chaque serveur individuellement, mais il est plus efficace de tester la connexion au serveur à l'aide du script d'automatisation Cloud Migration Factory. Pour obtenir des instructions détaillées, consultez [Vérifier les connexions au serveur cible](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-command-prompt.html#verify-the-target-server-connections) dans le *guide de mise en œuvre de Cloud Migration Factory*. ## Reconfigurer les paramètres de l'application et du réseau Une fois que l'équipe de migration a terminé les tests au niveau du système d'exploitation, l'équipe chargée de l'application apporte des modifications au niveau de l'application. Ces modifications peuvent inclure les éléments suivants : + Si l'application nécessite un équilibreur de charge, modifiez le point de terminaison de l'application dans l'équilibreur de charge pour qu'il pointe vers la nouvelle instance IPs . AWS + Modifiez la chaîne de connexion pour que le niveau Web de l'application se connecte à la base de données. + Modifiez les autres paramètres spécifiques à l'application. ## Tester l'application Les tests d'applications, qui ont lieu après les mises à jour décrites dans la section précédente, sont généralement gérés par le propriétaire de l'application ou par l'équipe de support. Cela implique de se connecter aux nouveaux serveurs et de confirmer que l'application fonctionne comme prévu. Si ce n'est pas le cas, le propriétaire de l'application ou l'équipe de support travaille avec l'équipe de migration pour résoudre les problèmes. ## Terminez le découpage Il s'agit de la dernière étape de la migration. Le propriétaire de l'application décide si l'application cible AWS répond à ses attentes du point de vue des fonctionnalités et des performances. Si une annulation est requise, elle implique généralement les activités suivantes : + Mettre fin à toutes les AWS instances de l'application concernée. + Activer les serveurs sur site pour l'application donnée. + Rétablir les anciennes adresses IP des serveurs dans les enregistrements DNS.