Guide complet de migration vers AWS pour les entreprises en 2025

Pourquoi migrer vers AWS en 2025 ?

Selon IDC, 70 % des entreprises européennes auront migré au moins 50 % de leurs workloads vers le cloud d'ici fin 2026. Ce chiffre n'est pas le fruit du hasard : la fin de vie de Windows Server 2012/2012 R2 (octobre 2023), la pression sur les coûts d'infrastructure physique et la nécessité d'accélérer l'innovation poussent les DSI à franchir le pas. Mais une migration AWS sans méthode est une source de risques majeurs — dépassements de budget, indisponibilités, dettes techniques amplifiées. Ce guide vous donne la feuille de route complète.

Le cadre des 7R : choisir la bonne stratégie par application

AWS définit 7 stratégies de migration. Le choix dépend de la valeur attendue, de la complexité technique et des contraintes métier de chaque application.

Retire — Décommissionner

Entre 10 et 20 % du parc applicatif d'une entreprise est inutilisé ou redondant. L'identifier avant la migration génère une économie immédiate et réduit la surface de migration. Auditez les licences, les logs d'utilisation et interrogez les équipes métier : vous serez surpris du nombre d'applications que personne n'utilise plus.

Retain — Conserver on-premise

Certaines applications ne peuvent ou ne doivent pas migrer dans l'immédiat : contraintes réglementaires fortes (données de santé sous HDS, données classifiées), latence réseau incompatible avec le cloud (systèmes temps-réel industriels), ou fin de vie proche qui rend l'investissement migration injustifiable.

Rehost — Lift and Shift

Migration à l'identique vers EC2, sans modification du code ni de l'architecture. C'est la stratégie la plus rapide (quelques heures par serveur avec AWS MGN) et la moins risquée à court terme. Elle ne génère pas d'optimisation immédiate mais permet de sortir du datacenter rapidement. Le ROI cloud (rightsizing, réservations) est réalisé dans un second temps.

Relocate — VMware Cloud on AWS

Pour les entreprises fortement investies en VMware, cette stratégie permet de migrer des VMs VMware vers VMware Cloud on AWS sans réécriture ni changement d'outillage. Le même vCenter, les mêmes playbooks opérationnels — mais hébergés sur l'infrastructure AWS. Idéal comme première étape avant un éventuel replatforming.

Repurchase — Remplacer par du SaaS

Pourquoi migrer un CRM on-premise vers EC2 alors que Salesforce existe ? Cette stratégie consiste à abandonner une application propriétaire au profit d'un équivalent SaaS. Elle s'applique typiquement aux ERP, CRM, outils de collaboration et solutions RH. L'effort est principalement sur la migration des données et la conduite du changement.

Replatform — Lift, Tinker and Shift

Migration avec des optimisations légères qui tirent parti des services managés AWS sans réécrire l'application : MySQL auto-géré → Amazon RDS (plus de patches, backups automatiques), Tomcat sur VM → AWS Elastic Beanstalk, jobs cron → AWS Batch. Le rapport effort/bénéfice est excellent pour les applications stables à durée de vie longue.

Refactor / Re-architect — Cloud-Native

Réécriture partielle ou totale pour adopter les architectures cloud-native : microservices, event-driven, serverless. C'est la stratégie la plus coûteuse en temps et en effort, mais elle offre le maximum de valeur à long terme — scalabilité élastique, résilience native, time-to-market accéléré. À réserver aux applications stratégiques à fort enjeu business.

Arbre de décision simplifié

• Application non utilisée → Retire
• Contrainte réglementaire bloquante → Retain
• VMware, sortir vite → Relocate
• Equivalent SaaS disponible → Repurchase
• Application standard, pas de refonte prévue → Rehost
• Application stable, services managés disponibles → Replatform
• Application stratégique, dette technique → Refactor

Phase 1 : Discovery — Inventorier pour décider

Une migration réussie commence par une connaissance précise de l'existant. AWS propose deux outils complémentaires.

AWS Application Discovery Service (ADS)

ADS collecte automatiquement les données de performance et de configuration de vos serveurs on-premise via des agents légers (Windows et Linux) ou en mode agentless via VMware vCenter.

# Installation de l'agent ADS sur Linux
wget https://s3.amazonaws.com/aws-discovery-agent/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo ./install -r eu-west-1 -k ACCESS_KEY -s SECRET_KEY

# Lancer la collecte continue
aws discovery start-continuous-export --region eu-west-1

# Consulter les agents actifs
aws discovery describe-agents   --filters "name=agentHealthStatus,values=HEALTHY"

Après 2 semaines de collecte, vous obtenez pour chaque serveur : utilisation CPU/RAM/disque, connexions réseau actives, processus en cours d'exécution. Ces données alimentent automatiquement AWS Migration Hub.

AWS Migration Evaluator

Migration Evaluator analyse votre inventaire ADS et génère un business case chiffré : coût estimé on-premise vs AWS sur 3 ans, recommandations de dimensionnement, économies projetées. C'est le document que vous présenterez au COMEX pour valider le budget migration.

Cartographie des dépendances

ADS génère une carte des dépendances réseau entre vos serveurs (qui parle à qui, sur quel port). Cette cartographie est indispensable pour constituer vos vagues de migration : les applications fortement couplées doivent migrer ensemble pour éviter les problèmes de latence inter-datacenter.

Phase 2 : Planification — Migration Hub et Wave Planning

AWS Migration Hub centralise le suivi de toutes vos migrations depuis une console unique, quelle que soit la région ou l'outil utilisé (MGN, DMS, DataSync).

Construction des vagues de migration

Une vague (wave) est un groupe d'applications migrées ensemble lors du même sprint. Les critères de constitution d'une vague sont : dépendances communes, équipe applicative responsable, tolérance à la coupure de service, criticité métier.

• Vague 0 : Infrastructure (VPC, Transit Gateway, Direct Connect ou VPN, Landing Zone)
• Vague 1 : Applications non critiques — environnements de dev et de recette
• Vague 2 : Applications de support (monitoring, outils internes)
• Vagues 3 à N : Applications de production, par ordre de criticité croissante

Estimation des coûts avec AWS Pricing Calculator

Pour chaque application, estimez le coût AWS cible en utilisant les recommandations de dimensionnement d'ADS. N'oubliez pas d'inclure : les coûts de transfert de données (Data Transfer), le support AWS (Business ou Enterprise selon les SLA requis), les licences tierces (Windows Server, SQL Server, Oracle).

Phase 3 : Migration — Patterns et outils

Rehost avec AWS Application Migration Service (MGN)

AWS MGN (anciennement CloudEndure Migration) est l'outil de référence pour le lift-and-shift. Il réplique en continu les serveurs source vers AWS, permettant un basculement (cutover) avec un RPO inférieur à 1 seconde et un RTO inférieur à 1 heure.

# Flux de migration avec AWS MGN
# 1. Installer l'agent MGN sur le serveur source
#    (Windows ou Linux, 1 agent par serveur)

# 2. Configurer le Launch Template pour chaque serveur
#    - Type d'instance EC2 cible
#    - VPC et sous-réseau de destination
#    - Groupes de sécurité
#    - Tags obligatoires

# 3. Lancer le test de basculement (Test Cutover)
aws mgn start-test   --source-server-ids s-xxxxxxxxxx   --account-id 123456789012

# 4. Valider l'application sur l'instance de test
# 5. Lancer le basculement réel en fenêtre de maintenance
aws mgn start-cutover   --source-server-ids s-xxxxxxxxxx   --account-id 123456789012

# RTO typique : 45 minutes
# RPO : < 1 seconde (réplication continue)

Migration de bases de données avec AWS DMS et SCT

Les migrations de bases de données sont souvent le chemin critique d'une migration. AWS Database Migration Service (DMS) gère les migrations homogènes (MySQL vers RDS MySQL) et hétérogènes (Oracle vers Aurora PostgreSQL, SQL Server vers RDS).

Pour les migrations hétérogènes, commencez par AWS Schema Conversion Tool (SCT) qui analyse le schéma source, estime le niveau d'effort de conversion et génère automatiquement le DDL cible avec les conversions de types et de fonctions.

# Configuration d'une tâche DMS — Oracle vers Aurora PostgreSQL
# 1. Créer les endpoints source et cible

aws dms create-endpoint   --endpoint-identifier oracle-source   --endpoint-type source   --engine-name oracle   --server-name oracle-prod.internal   --port 1521   --database-name PRODDB   --username dms_user   --password "****"

aws dms create-endpoint   --endpoint-identifier aurora-target   --endpoint-type target   --engine-name aurora-postgresql   --server-name aurora-cluster.cluster-xxx.eu-west-1.rds.amazonaws.com   --port 5432   --database-name proddb

# 2. Créer la tâche de réplication (Full Load + CDC)
aws dms create-replication-task   --replication-task-identifier oracle-to-aurora   --source-endpoint-arn arn:aws:dms:...   --target-endpoint-arn arn:aws:dms:...   --replication-instance-arn arn:aws:dms:...   --migration-type full-load-and-cdc   --table-mappings file://table-mappings.json

Maintenez la réplication CDC (Change Data Capture) active pendant 2 à 4 semaines avant le basculement final. Cela vous donne le temps de valider la qualité des données et de corriger les éventuels problèmes de conversion.

Replatform : Conteneurisation vers ECS Fargate

Pour les applications Java, Python ou Node.js déployées sur des VMs, la conteneurisation offre un excellent rapport effort/bénéfice sans refonte applicative.

# Dockerfile type pour une application Java Spring Boot
FROM amazoncorretto:17-alpine
WORKDIR /app
COPY target/application.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# Build et push vers Amazon ECR
aws ecr create-repository --repository-name myapp --region eu-west-1

aws ecr get-login-password --region eu-west-1 |   docker login --username AWS   --password-stdin 123456789012.dkr.ecr.eu-west-1.amazonaws.com

docker build -t myapp .
docker tag myapp:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/myapp:latest
docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/myapp:latest

# Déploiement sur ECS Fargate (extrait Terraform)
resource "aws_ecs_task_definition" "myapp" {
  family                   = "myapp"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 512
  memory                   = 1024
  execution_role_arn       = aws_iam_role.ecs_execution.arn

  container_definitions = jsonencode([{
    name  = "myapp"
    image = "${aws_ecr_repository.myapp.repository_url}:latest"
    portMappings = [{ containerPort = 8080 }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"  = "/ecs/myapp"
        "awslogs-region" = "eu-west-1"
      }
    }
  }])
}

Phase 4 : Optimisation post-migration

Stratégie de tagging

Sans tagging rigoureux, l'attribution des coûts cloud devient rapidement impossible. Définissez un standard de tagging obligatoire avant la migration et appliquez-le via AWS Config Rules.

# Tags obligatoires sur toutes les ressources
Environment   = "production" | "staging" | "development"
Team          = "backend" | "frontend" | "data" | "infra"
CostCenter    = "CC-001" | "CC-002" | ...
Application   = "monapp" | "erp" | ...
MigrationWave = "wave-1" | "wave-2" | ...

Rightsizing avec AWS Compute Optimizer

Les instances migrées en lift-and-shift sont systématiquement surdimensionnées — elles ont été provisionnées pour des pics on-premise qui ne se manifestent plus de la même façon dans le cloud. Attendez 14 jours de métriques stables, puis appliquez les recommandations Compute Optimizer.

aws compute-optimizer get-ec2-instance-recommendations   --filters name=Finding,values=OVER_PROVISIONED   --region eu-west-1

En moyenne, nos clients réduisent leur facture EC2 de 25 % dans les 60 jours suivant la migration grâce au rightsizing.

Reserved Instances et Savings Plans

Une fois le parc stabilisé (2 à 3 mois post-migration), engagez-vous sur des Reserved Instances ou des Compute Savings Plans pour les workloads prévisibles. Un Compute Savings Plan sur 1 an génère 30 % d'économies par rapport à l'on-demand ; sur 3 ans, 50 %.

Les pièges classiques à éviter

Ignorer la latence réseau

Une application 3-tiers avec un front-end migré sur AWS et une base de données restée on-premise verra ses performances se dégrader si la connectivité n'est pas dimensionnée. Mesurez la latence actuelle entre les couches, calculez l'impact d'une latence supplémentaire de 20-50 ms, et migrez les couches fortement couplées ensemble ou mettez en place AWS Direct Connect (1 à 10 Gbps) avant de migrer les workloads sensibles.

Sous-estimer les coûts de transfert de données

Le data transfer out d'AWS vers Internet coûte 0,09 $/Go en eu-west-1. Pour une application qui exporte 10 TB de données par mois, cela représente 900 $/mois de transferts — une ligne de coût souvent absente du business case initial. Utilisez AWS Cost Estimator pour modéliser ces coûts avant la migration, et envisagez AWS CloudFront pour réduire les transferts directs.

Absence de plan de rollback

Chaque migration doit avoir une procédure de retour arrière documentée et testée. Avec AWS MGN, le serveur source reste actif pendant la période de validation post-cutover — conservez-le au moins 7 jours avant de l'éteindre. Pour les bases de données DMS, maintenez la réplication inverse active pendant la période de validation.

Migrer sans nettoyer la dette technique

Le lift-and-shift d'une application mal configurée produit une application mal configurée dans le cloud, plus chère à faire tourner. Identifiez les quick wins de nettoyage (logs non archivés, connexions DB orphelines, cron jobs redondants) et traitez-les avant ou pendant la migration.

La méthodologie Move2Cloud : 4+90 jours

Chez Move2Cloud, nous appliquons une approche structurée en deux temps.

Assessment de 4 semaines : déploiement des agents ADS, collecte des métriques, cartographie des dépendances, scoring 7R de chaque application, construction du business case et du plan de vagues. Ce livrable est la fondation de toute la migration.

Sprint de 90 jours : exécution des vagues 0, 1 et 2 (infrastructure, dev/recette, premières applications de production). À l'issue de ce sprint, les équipes client ont gagné en autonomie sur les outils AWS et les processus de migration sont industrialisés pour les vagues suivantes.

Nos clients constatent en moyenne une réduction de 30 à 40 % de leurs coûts d'infrastructure dans les 12 mois suivant la migration, en combinant rightsizing, réservations et suppression des ressources inutilisées.

Conclusion

Une migration AWS réussie n'est pas un événement technique — c'est un programme de transformation qui touche les équipes, les processus et les outils. La clé du succès est dans la préparation : une phase de discovery rigoureuse, un plan de vagues réaliste et une gouvernance cloud mise en place avant le premier workload. Move2Cloud accompagne les entreprises de A à Z, de l'assessment initial jusqu'à l'optimisation post-migration. Contactez-nous pour démarrer votre assessment gratuit.