Préparer des outils et un backlog de migration initial
Pour implémenter votre migration, vous avez besoin des outils appropriés et d’un backlog complet des charges de travail à migrer. Cet article fournit des conseils sur la préparation de votre migration en définissant les outils nécessaires et en créant un backlog de migration initial.
Préparer les outils de migration
Pour mener à bien votre migration, vous avez besoin d’outils spécifiques pour évaluer, répliquer et suivre vos charges de travail via des itérations, notamment des activités de correction.
De nombreux outils de migration sont disponibles Plusieurs d’entre eux sont natifs de la plateforme Azure ou sont déjà couramment disponibles.
Voici une liste d’outils ou d’offres courants dont vous avez besoin pour un projet de migration réussi :
| Type d’outil | Fonctionnalités | Outil |
|---|---|---|
| Découverte et évaluation | Effectue une découverte et des évaluations automatisées de votre environnement. Identifie les obstacles à la migration et les dépendances entre les serveurs. | Azure Migrate |
| Réplication | Réplique l’état des données entre votre source locale et un environnement intermédiaire cloud. Utilisé pour sérialiser et migrer les ressources. | Azure Migrate |
| Suivi | Utilisé pour organiser les activités du projet, par exemple pour regrouper les serveurs en charges de travail, suivre les activités de remédiation et fournir l’état de la migration d’une charge de travail. | Azure DevOps, Excel et Microsoft Project |
| Guide de migration | Vous aide à identifier la fonctionnalité de migration à utiliser pour Azure Migrate. Le guide d’exécution de la migration est une ressource de projet qui peut vous guider pas à pas dans les décisions et l’implémentation de votre migration. | Guide d’exécution de la migration |
Bien que vous puissiez utiliser d’autres outils à la place d’Azure Migrate, nous vous recommandons d’utiliser une offre native, à moins qu’il n’y ait une raison identifiée. L’offre native Azure Migrate est conçue pour fonctionner en toute transparence avec la plateforme Azure et est continuellement mise à jour pour prendre en charge les fonctionnalités et capacités les plus récentes.
Remarque
Si vous utilisez un outil existant pour répliquer une charge de travail vers Azure, changer d’outil au cours de ce processus peut perturber et diminuer les performances. Dans ce cas de figure, continuez à utiliser l’outil existant. Par la suite, vous pouvez exécuter la promotion de la migration comme un scénario de basculement de la récupération d’urgence.
Backlog de migration initial
Les sections suivantes décrivent les activités préalables que vous devez effectuer pour générer un backlog de migration initial.
L’équipe de stratégie cloud est responsable de l’entretien et de la maintenance du patrimoine numérique. Toutefois, le traitement du backlog généré à partir du mappage d’une infrastructure numérique relève de la responsabilité partagée de tous les rôles impliqués dans le processus de migration. L’équipe de stratégie cloud et l’équipe d’adoption du cloud doivent examiner et comprendre le backlog de migration avant que les équipes commencent à planifier des activités de charge de travail individuelles. Au cours de la révision, les membres des deux équipes doivent acquérir suffisamment de connaissances pour articuler les points clés suivants concernant le backlog de migration.
Métriques et résultats métier
Chaque membre de l’équipe doit comprendre les résultats opérationnels recherchés. Les migrations prennent du temps. Il est facile pour les membres de l’équipe de se laisser distraire par des activités urgentes, mais moins importantes à différentes étapes de la migration. L’établissement et le renforcement des résultats escomptés aident les membres de l’équipe à comprendre l’ordre de priorité et l’importance relative des activités de migration, ce qui leur permet de prendre de meilleures décisions au fil du temps.
Le suivi des progrès de la migration est tout aussi important pour la motivation de l’équipe de migration que pour la prise en charge continue des parties prenantes. Suivez la progression via les KPI clés de migration et en surveillant les indicateurs. Quelle que soit la façon dont vous suivez l’effort, il est important que l’équipe ait connaissance de ces indicateurs clés afin qu’elle puisse évaluer le niveau de performance lors des itérations suivantes.
Priorités de l’entreprise
Parfois, donner la priorité à une charge de travail plutôt qu’à une autre peut ne pas sembler logique ou même bénéfique à l’équipe d’adoption du cloud. Comprendre les priorités de l’entreprise qui déterminent les décisions de hiérarchisation des charges de travail peut aider l’équipe à maintenir une motivation indispensable. Cela permet également à l’équipe d’apporter une contribution plus importante lors du processus de prise de décision concernant les priorités.
Hypothèses principales
La rationalisation de l’infrastructure numérique traite de l’impact sur l’agilité et le gain de temps qu’apporte le fait de travailler à partir d’hypothèses principales lors de l’évaluation d’une infrastructure numérique. Pour concrétiser pleinement ces valeurs, l’équipe d’adoption du cloud doit comprendre les hypothèses et les raisons pour lesquelles elles ont été établies. Ces connaissances permettent à l’équipe de mieux remettre en question les hypothèses en matière d’efficacité et d’économies.
Capturer le backlog
Capturez le backlog dans un emplacement que vous pouvez partager avec tous les membres de l’équipe d’adoption du cloud. À partir d’un emplacement partagé, différents membres de l’équipe peuvent aligner leurs connaissances et travailler sur le backlog, et vous pouvez conserver le backlog actuel tout au long du processus de migration.
Vous pouvez à la fois utiliser des outils qui sont familiers à votre organisation et vous appuyer sur les outils que vous utilisez pour mener à bien la rationalisation de votre infrastructure numérique.
Si vous recherchez des modèles prédéfinis, le Guide d’exécution de la migration contient des modèles de tableur qui peuvent vous aider à organiser votre backlog.
Il est important d’associer des charges de travail à des serveurs, afin de pouvoir suivre la charge de travail elle-même à travers les migrations de serveurs individuelles dans le backlog. Vous pouvez également utiliser le backlog pour présenter les dépendances entre les charges de travail à mesure que vous effectuez l’évaluation. Lorsque vous corrigez les ressources et effectuez des tests, vous fusionnez le backlog avec un plan de correction.
Le backlog est utilisé tout au long du processus de migration. Le maintien du backlog est essentiel.
Planifier le backlog pour plusieurs centres de données
Avant de commencer votre migration, vous devez créer des épopées dans l’outil de gestion de projet pour chaque centre de données que vous migrez. Dans une épopée de centre de données, vous pouvez regrouper le travail associé afin de pouvoir suivre l’état de chaque emplacement du centre de données.
Si vous n’utilisez pas d’épopées pour gérer votre migration, vous pouvez utiliser des objectifs de niveau supérieur ou des regroupements pour les centres de données. L’essentiel est que vous puissiez filtrer, organiser et suivre chaque centre de données comme s’il s’agissait d’un emplacement distinct.
Il est important de comprendre les résultats et les motivations opérationnels pour votre migration. Utilisez ces motivations pour classer par ordre de priorité la liste des épopées (ou centres de données). Par exemple, si l’intention de migrer à partir d’un centre de données local avant la fin de votre bail actuel motive votre migration, priorisez les épopées à l’aide de dates de renouvellement de bail.
Au sein de chaque épopée, gérez les charges de travail que vous évaluez et migrez en tant que fonctionnalités. Gérez chaque ressource de cette charge de travail en tant que récit utilisateur. Les tâches représentent le travail nécessaire pour évaluer, migrer, optimiser, promouvoir, sécuriser et gérer chaque ressource.
Un sprint ou une itération est une série de tâches requises pour migrer les ressources et les récits utilisateur validés par l’équipe d’adoption du cloud. Un sprint est généralement un segment de temps, comme un trimestre fiscal ou un mois calendaire. Une version représente une ou plusieurs charges de travail ou fonctionnalités promues en production.