L'environnement : une architecture quatre niveaux sur deux sites
Avant la migration, l'équipe de Software Projects exploitait une architecture unique et bien définie dans deux régions IBM Cloud, dimensionnée pour la résilience : un site principal plus important et un site secondaire plus réduit. Chaque site suivait le même schéma à quatre niveaux :
- Répartition de charge : une petite flotte d'instances HAProxy en frontal, traitant séparément le trafic de production, de développement et de tracking.
- Application : des serveurs web et de tracking, un exécuteur de tâches planifiées, un serveur de qualité de code (SonarQube) et une passerelle VPN (présente uniquement sur le site principal).
- Orchestration de conteneurs : des clusters Docker Swarm autogérés, exploités en clusters de production et de développement distincts sur le site principal, et un cluster unique sur le site secondaire.
- Données : une paire MySQL primaire/réplica accompagnée d'un cluster Cassandra à trois nœuds, répliqués sur les deux sites.
Le plan de migration de DoiT prévoyait un lift-and-shift fidèle, à l'identique (1:1), de cette topologie vers un VPC AWS unique dans us-east-1 — en conservant les mêmes empreintes de 24 et 16 nœuds, mais en les répartissant sur plusieurs zones de disponibilité au sein d'une seule région AWS, plutôt que dans deux régions IBM Cloud indépendantes et géographiquement séparées. Le tableau ci-dessous montre comment la composition, niveau par niveau, a été reprise sans modification :

Ces chiffres sont restés constants de part et d'autre de la bascule — les mêmes 24 et 16 nœuds, dans les mêmes proportions niveau par niveau, simplement relocalisés. Cette rigueur a compté : Software Projects a ainsi hérité sur AWS d'un environnement au comportement identique à celui que son équipe connaissait déjà, tandis que DoiT supprimait discrètement une couche de complexité d'infrastructure en consolidant deux régions de datacenters en une seule région AWS répartie sur plusieurs zones de disponibilité. Cela a également préparé proprement la phase Modernize, la feuille de route prévoyant déjà le retrait des clusters Docker Swarm autogérés au profit d'une plateforme de conteneurs managée, une fois l'environnement stabilisé sur AWS.
L'approche : AWS MAP, livré de bout en bout
DoiT a mené la mission sur les trois phases d'AWS MAP, chaque phase posant les fondations techniques et financières de la suivante — le tout livré de bout en bout par l'équipe Forward Deployed Engineers de DoiT.

1. Assess : construire un budget de migration solide
Avant de déplacer le moindre workload, l'équipe de Software Projects avait besoin d'une vision claire, service par service, du coût du stockage et du calcul sur AWS. DoiT a élaboré une ventilation détaillée des coûts couvrant EBS et EFS — en modélisant les coûts mensuels de stockage, d'IOPS et de débit selon les types de volumes et les classes de stockage — afin que Software Projects puisse prévoir ses dépenses à court et moyen terme dans le cadre de sa feuille de route de migration. DoiT a également travaillé la stratégie de remises pour le calcul des bases de données de Software Projects, en comparant DoiT Flexsave (un équivalent des Compute Savings Plans avec remise, sans engagement initial) aux tarifs des Reserved Instances standard et convertibles, et en expliquant les arbitrages de chaque option dans la perspective d'un éventuel passage futur à un service de base de données managé.
2. Mobilize : résoudre la connectivité inter-cloud
La connectivité entre IBM Cloud et AWS constituait le chemin critique de toute la migration, et il n'existait pas de solution clé en main. DoiT a mené une évaluation structurée des options — AWS Direct Connect, un circuit dédié IBM Direct Link, des appliances de routage virtuel et un VPN maillé léger — en pesant pour chacune le coût, la stabilité et la complexité de mise en œuvre :
- Évaluation d'AWS Direct Connect et d'IBM Direct Link Dedicated (y compris les contraintes BGP, de plages IP et de facturation) comme option de circuit dédié.
- Expérimentation d'un overlay VPN maillé comme solution de repli rapide et gratuite, le temps d'évaluer les options à plus long terme.
- Accompagnement de Software Projects dans le déploiement et le réglage d'une appliance de routage virtuel côté IBM, y compris le comportement du routage VLAN et le dépannage de couche 2 avec le support IBM.
- Assistance au passage de Software Projects d'IBM Classic Infrastructure à IBM VPC pour bénéficier d'un réseau plus flexible, puis mise en place d'un VPN site à site IPSec entre IBM VPC et un VPC AWS.
- Diagnostic et résolution d'un chevauchement de sous-réseaux et d'un défaut de routage entre IBM Classic et AWS, via l'allocation d'une plage IP dédiée sans chevauchement et l'ajustement des routes statiques — le correctif qui a enfin débloqué le trafic bidirectionnel entre les trois environnements.
Le résultat : un chemin réseau privé stable et vérifié reliant IBM Classic Infrastructure, IBM VPC et AWS — la fondation qui a permis à l'équipe de Software Projects de déplacer ses workloads à son propre rythme, sans perdre la connectivité avec les systèmes encore hébergés chez IBM.
Préserver la stabilité de la production pendant la transition
Pendant la fenêtre de migration, DoiT a également fourni un support opérationnel réactif côté AWS. Dans un cas, une instance EC2 a perdu de manière inattendue sa connectivité SSM, sans repli SSH disponible. En s'appuyant sur les diagnostics de sortie console, DoiT a identifié la cause racine — le volume racine était saturé, ce qui empêchait le démarrage de l'agent SSM — et a fourni un plan de remédiation étape par étape (extension du volume et redimensionnement du système de fichiers), ainsi que des alarmes CloudWatch proactives sur l'utilisation disque et des notifications SNS pour éviter toute récidive, avec une attention particulière à la protection des systèmes de production contre ce même mode de défaillance.
3. Modernize : conteneurs et optimisation continue des coûts
La migration achevée, la mission est entrée dans la phase Modernize. Les environnements de production et de développement de Software Projects fonctionnaient encore sur des clusters Docker Swarm autogérés — fonctionnels, mais avec la charge opérationnelle de managers et de workers corrigés manuellement. DoiT aide désormais l'équipe de Software Projects à retirer ces clusters Swarm au profit d'une plateforme de conteneurs managée sur AWS (Amazon EKS), en s'appuyant directement sur la fondation VPC multi-AZ consolidée établie durant Mobilize, plutôt que de repartir d'une feuille blanche.
Dans le cadre de cette même dynamique de modernisation, DoiT veille à la discipline des dépenses cloud à mesure que l'environnement évolue. À l'aide de DCI Insights, DoiT a passé en revue la configuration AWS Detective et GuardDuty de Software Projects et constaté que les coûts des outils de sécurité représentaient désormais une part significative des dépenses globales, principalement en raison d'une ingestion volumineuse de flow logs plutôt que de la valeur de sécurité réellement apportée. DoiT a quantifié les arbitrages — y compris quels types de détections de sévérité élevée dépendaient de quelles sources de données — et a fourni à Software Projects un ensemble d'options claires et étayées pour un right-sizing de la couverture de sécurité, sans perdre les détections les plus précieuses. Cette même approche disciplinée, fondée sur les faits, se poursuit dans le chantier de conteneurisation : un dimensionnement juste dès le départ, plutôt qu'une optimisation après coup.
La solution : propulsée par DoiT Cloud Intelligence™ (DCI)
En parallèle de l'accompagnement technique, Software Projects a tiré parti de plusieurs fonctionnalités de DoiT Cloud Intelligence™ (DCI) tout au long de la mission — en associant une équipe de delivery expérimentée à une visibilité en libre-service sur son propre environnement AWS :

Les deux dernières fonctionnalités sont actives au quotidien : à mesure que l'équipe de Software Projects modernise son environnement vers les conteneurs, DCI AWS Intelligence et DCI Datadog Insights lui offrent une visibilité continue sur l'ensemble des dépenses cloud et d'observabilité, sans attendre qu'une facture mensuelle révèle un problème.