Stratégie et feuille de route pour migrer une plateforme d'analyse : rehost, replatform ou refactor ?
Vous êtes CTO ou responsable data d'une PME/ETI et devez arbitrer une stratégie de migration de votre plateforme d'analyse tout en préparant une feuille de route opérationnelle. Cet article cadre les familles d'approches, les critères de décision workload‑par‑workload, les modèles d'exécution et le phasage projet pour préparer un business case et un calendrier priorisé.
À retenir
Comprendre le portefeuille IT et prioriser les applications et les données selon leur valeur métier et leur complexité de migration.
Comparer les indications d'AWS sur le rehost, le replatform et le refactor : coût, durée, exploitation et compétences nécessaires.
La migration factory se prête mal à une revue manuelle de chaque application ou à des changements importants de la chaîne CI/CD.
Dans le guide Azure, Plan, Prepare, Execute et Evaluate décrivent la planification, la préparation, l'exécution et l'évaluation de la migration.
Catalogue des options de migration (les « R ») et définition de la migration cloud
Les stratégies de migration se classent selon les « 7 R » : parmi elles, le rehost (lift‑and‑shift) déplace une application vers le cloud sans changements, le relocate effectue un lift‑and‑shift au niveau hyperviseur sans réécriture ni modification des opérations, et le replatform migre l'application en introduisant des optimisations ciblées pour tirer parti de capacités cloud. [1]
La migration cloud désigne le transfert planifié et non‑disruptif d'actifs numériques (données, applications, ressources IT) depuis un centre de données ou un environnement local vers l'infrastructure d'un fournisseur cloud, en priorisant, planifiant et testant les workloads pour déplacer progressivement l'exploitation vers le cloud. [2]
Critères pratiques pour choisir entre rehost, replatform et refactor (avantages, limites et compétences requises)
Le rehosting est généralement plus rapide et plus simple car il n'implique pas de changements de code ou d'architecture, il minimise les risques et les interruptions opérationnelles et facilite les migrations à grande échelle, mais il n'exploite pas pleinement les bénéfices cloud et laisse en place les problèmes de plateforme existants. [1]
La replatformation est souvent plus rentable que le rehost car elle permet d'automatiser et d'utiliser des capacités cloud (auto‑scaling, supervision, sauvegardes), ce qui réduit la charge opérationnelle, mais elle prend plus de temps et nécessite des compétences supplémentaires pour configurer l'automatisation et opérationnaliser la nouvelle plateforme. [1]
AWS présente le refactoring comme une approche cloud-native généralement la plus rentable pour la migration. Le découplage des composants permet aux applications de s'adapter rapidement à de nouvelles exigences et vise à améliorer leur résilience. Cette approche demande toutefois des compétences plus avancées en programmation et en automatisation, ainsi que davantage de temps puisqu'elle implique de reconstruire les applications. [1]
Évaluer et prioriser les workloads, puis examiner les contraintes de migration
Selon AWS, toutes les migrations cloud commencent par la compréhension du portefeuille IT actuel, notamment des applications, des workloads et des données qu'il comprend. [2]
AWS recommande de choisir les applications et les données à migrer en premier selon des facteurs comme la valeur métier et la complexité de migration. La phase d'évaluation pose ainsi les bases de la migration cloud. [2]
Selon Google Cloud, la migration factory se prête mal à un processus de gestion du changement qui impose une revue manuelle de chaque application : l'effort de revue et de contrôle des changements dépasse alors le temps gagné par la migration automatisée du code et des données. Il en va de même si des modifications importantes de la chaîne CI/CD sont nécessaires avant le déploiement cloud. L'intérêt commercial d'une migration à l'identique devient moins convaincant lorsque ce processus de changement est pris en compte. [3]
Migration factory et modernization factory : conditions et organisation
La migration factory consiste à copier ou déployer massivement VMs ou conteneurs et convient quand les applications sont suffisamment simples et similaires et que l'équipe peut agir de façon autonome, typiquement pour des sorties de datacenter pilotées par l'infrastructure, en s'appuyant sur des outils spécialisés pour accélérer les opérations. [3]
Google Cloud indique que la majorité des migrations observées chez ses clients comportent une certaine modernisation, application par application. Les pratiques de modernisation visent à améliorer la scalabilité, la disponibilité, la sécurité et la durabilité de l'application, tout en réduisant le travail répétitif lié à son déploiement et à son exploitation. Selon cette source, ces modernisations progressives permettent généralement aux clients de réaliser leurs économies de coût total de possession (TCO), tandis que l'amélioration des capacités DevOps accompagne l'adoption du cloud. [3]
Une modernization factory associe une petite équipe applicative transversale, qui connaît l'application concernée, à une équipe factory connaissant le portefeuille de services cibles et les tactiques de modernisation à employer dans les applications. L'équipe applicative entre dans la factory et en sort avec son application ; l'équipe factory reste en place et traite une application et son équipe à la fois. [3]
Exemple Azure : les phases Plan, Prepare, Execute et Evaluate
Dans le guide Microsoft consacré à Azure, la phase Plan consiste à évaluer le workload actuel, identifier ses dépendances, faire correspondre les services source à leurs équivalents Azure et définir les critères de réussite. Le résultat attendu est une documentation claire du périmètre de migration, des changements requis et des critères d'achèvement. [4]
Dans ce guide Azure, la phase Prepare comprend la configuration de l'environnement Azure, avec les landing zones, le réseau, l'identité et la gouvernance, ainsi que la conception de l'architecture cible. Le résultat attendu est un environnement Azure prêt à accueillir le workload, avec toutes les décisions architecturales résolues avant le début de la migration. [4]
Dans ce guide Azure, la phase Execute couvre la migration de l'infrastructure, des données et des composants applicatifs, avec des tests itératifs et la bascule. Le résultat décrit est la migration des composants du workload vers Azure, puis la redirection du trafic de production vers Azure après validation réussie du workload. [4]
Dans ce guide Azure, la phase Evaluate vérifie que le workload migré respecte les exigences fonctionnelles, de performance, de sécurité et de coût par rapport à la référence définie pendant la première phase. Le résultat attendu est la confirmation de la réussite de la migration et du bon fonctionnement du workload sur Azure. [4]
Conclusion
Pour préparer votre réflexion, vous pouvez rapprocher les repères AWS de votre portefeuille d'applications, puis examiner les conditions des modèles décrits par Google Cloud. Les quatre phases présentées ici illustrent la démarche du guide Microsoft pour Azure ; elles sont à lire dans ce contexte. Cet article propose une grille de lecture de ces sources, sans fixer de durée, de première vague ou de résultat pour votre propre projet.
Commentaires