Découvrez comment réussir une migration cloud AWS avec l'approche lift-and-shift. Guide technique étape par étape pour migrer votre application monolithique.

La migration lift-and-shift (ou réhébergement) consiste à déplacer votre application monolithique vers AWS sans modification de son architecture. Cette approche prend entre 2 et 8 semaines selon la complexité, coûte 30 à 50% moins cher qu'une refactorisation complète, et vous permet de bénéficier immédiatement des avantages de l'infrastructure cloud.** Si votre application fonctionne correctement aujourd'hui et que vous cherchez une transition rapide avec un risque minimal, le lift-and-shift est la stratégie à adopter.

Le cauchemar silencieux : quand votre data center vous coûte plus cher que prévu

En 2023, une entreprise industrielle française que je accompagnée a découvert que son infrastructure on-premise lui coûtait 340 000 € par an en factures d'électricité, refroidissement et maintenance. Son application ERP monolithique tournait sur des serveurs Dell PowerEdge achetés en 2018 — des machines qui, honnêtement, méritaient leur retraite depuis longtemps. Le projet de migration vers AWS qu'ils avaient repoussé pendant deux ans leur a permis de réduire ces coûts de 62% tout en améliorant la disponibilité de 99,5% à 99,95%.

Ce cas n'est pas isolé. Selon une étude Flexera 2024, 61% des entreprises françaises déclarent que leurs coûts cloud sont supérieurs aux prévisions, mais paradoxalement, 78% reconnaissent que leurs charges on-premise leur reviennent encore plus cher lorsqu'on intègre tous les coûts cachés.

Si vous hésitez encore à franchir le pas, cet article vous explique concrètement comment réussir une migration vers le cloud avec une approche lift-and-shift, en minimisant les risques et en maximisant le retour sur investissement.

Lift-and-shift : de quoi parle-t-on exactement ?

Le lift-and-shift (ou réhébergement) est une stratégie de migration cloud qui consiste à déplacer une application d'un environnement on-premise vers AWS sans modification significative de son code ou de son architecture. Vous « soulevez » votre application de son infrastructure actuelle et vous la « déposez » sur des ressources cloud équivalentes.

Concrètement, cela signifie :

  • Votre application monolithique reste inchangée
  • Vous remplacez vos serveurs physiques par des instances EC2
  • Votre base de données SQL Server sur Windows Server migre vers RDS for SQL Server
  • Votre stockage SAN devient des volumes EBS ou un bucket S3
  • Vous recréez votre réseau virtuel avec un VPC

Cette approche contraste avec le « replatforming » (qui implique quelques optimisations) ou la « refactorisation » (qui redesign entièrement l'application pour le cloud natif).

Quand choisir le lift-and-shift plutôt qu'une autre approche ?

Avantages du lift-and-shift

Réponse rapide : Vous pouvez migrer une application simple en 2 à 4 semaines. Une refactorisation容器isée prendrait 3 à 6 mois minimum.

Risque minimal : Zéro modification de code signifie zéro regression fonctionnelle. Votre application qui tourne aujourd'hui fonctionnera identique sur AWS.

Coût prévisible : Vous payez des instances EC2 à prix fixe, sans les surprises d'une architecture microservices complexe.

Équipe，无需重新培训 : Vos développeurs connaissent l'application telle qu'elle est. Pas besoin d'investir dans une formation Kubernetes intensive.

Inconvénients à considérer honnêtement

Pas d'avantages cloud natif : Vous n'exploitez pas Lambda, ECS, ou les services managés qui différencient vraiment AWS.

Coût potentiellement plus élevé : Une instance EC2 avec Windows Server coûte environ 0,138 $ par heure (t3.medium). Si votre application a des pics d'utilisation, une architecture event-driven serait plus économique.

Dette technique reportée : Le monolithique reste un monolithique. Vous avez reporté — mais pas résolu — les problèmes de scalabilité.

Mon recommandation : Le lift-and-shift est idéal pour les applications « matures et stables » qui ne nécessitent plus de développement intensif. Si votre ERP a 10 ans et fait son job, migrez-le tel quel. Si vous devez le faire évoluer rapidement, préférez un'approche hybride avec modernisation progressive.

Préparation : les 5 étapes critiques avant la migration

1. Inventaire complet de votre environnement

Avant de créer une seule instance EC2, vous devez savoir exactement ce que vous migrez. Cette étape prend généralement 1 à 2 semaines mais évite les surprises unpleasant pendant la migration.

Documents à produire :

  • Liste exhaustive des serveurs avec specifications (CPU, RAM, stockage)
  • Cartographie des dépendances applicatives (qui parle à qui ?)
  • Inventaire des licences logicielles et leur compatibilité AWS
  • Identification des données sensibles et exigences de conformité (RGPD, ISO 27001)
  • Liste des intégrations externes (VPN, API tierces)

Outils recommandés :

  • AWS Application Discovery Service : Agentless pour les environnements VMware, avec agent pour les machines physiques ou virtuelles
  • AWS Migration Hub : Centralise les données de découverte et suit l'avancement de la migration

2. Dimensionnement cible sur AWS

Ne vous contentez pas de « prendre la même chose ». Profitez-en pour optimiser.

Méthodologie de right-sizing :

  1. Analysez l'utilisation réelle sur 30 jours (CPU moyen, pic, RAM)
  2. Identifiez les périodes de sous-utilisation (souvent la nuit et le week-end)
  3. Calculez le coût d'instances réservation vs on-demand

Exemple concret : Un serveur SQL Server avec 64 Go de RAM et 16 vCPU qui fonctionne à 30% d'utilisation moyenne peut migrer vers une instance r6g.2xlarge (64 Go RAM, 8 vCPU) au lieu de surprovisionner. Économie annuelle : environ 4 200 $ en choix d'instance appropriée.

3. Conception du VPC

Votre réseau AWS doit reproduire — puis améliorer — votre topologie on-premise.

Architecture VPC recommandée pour lift-and-shift :

  • VPC principal : 10.0.0.0/16 (adjustable selon vos besoins)
  • Sous-réseaux publics : Pour les load balancers et services exposés
  • Sous-réseaux privés : Pour les instances applicatives (minimum 2 AZ pour la haute disponibilité)
  • Sous-réseaux pour les données : RDS, ElastiCache dans des sous-réseaux isolés
  • VPC Endpoints : Pour les accès S3, SQS, Secrets Manager sans passer par Internet

4. Gestion des licences

C'est souvent le point de friction le plus important. Vérifiez impérativement :

  • Windows Server : AWS propose des licences incluses (License Mobility) ou BYOL (Bring Your Own License) via AWS License Manager
  • SQL Server : Amazon RDS for SQL Server inclut les licences. Pour SQL Server Enterprise, utilisez Software Assurance et la mobilité des licences via AWS.
  • Oracle : Complexe — AWS ne propose pas Oracle sur RDS BYOL facilement. Nécessite une License Mobility Agreement avec Oracle.

5. Plan de reprise d'activité (PRA)

Définissez votre RTO (Recovery Time Objective) et RPO (Recovery Point Objective) avant la migration.

Questions à se poser :

  • Quelle interruption maximale pouvez-vous absorber ?
  • Quelle perte de données est acceptable ?
  • Avez-vous besoin de restaurer sur un site secondaire ?

La migration pas à pas : comment procéder concrètement

Phase 1 : Infrastructure as Code (semaine 1-2)

Ne migrez jamais manuellement. Utilisez Terraform ou AWS CloudFormation.

# Exemple de configuration pour un serveur d'application .NET
resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"  # Windows Server 2022 FR
  instance_type = "t3.medium"
  
  subnet_id              = aws_subnet.private_app_1.id
  vpc_security_group_ids = [aws_security_group.app_sg.id]
  
  root_block_device {
    volume_size = 100
    volume_type = "gp3"
  }
  
  tags = {
    Name        = "AppServer-PROD"
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

Phase 2 : Déploiement de l'infrastructure cible (semaine 2)

Créez votre environnement parallèle :

  1. Déployez le VPC avec tous les sous-réseaux
  2. Configurez les security groups (ne les ouvrez pas trop !)
  3. Provisionnez les instances EC2
  4. Déployez RDS avec le même moteur de base de données
  5. Configurez les Elastic Load Balancers
  6. Mettez en place les règles de scaling si nécessaire

Phase 3 : Réplication des données (semaine 2-3)

Pour les bases de données volumineuses, utilisez AWS Database Migration Service (DMS) :

  • Configuration continue avec réplicationCDC (Change Data Capture)
  • Support de plus de 50 sources cibles
  • Coût : environ 0,021 $ par Go de données migrées + instance de réplication

Important : Pour une base de 500 Go, prévoyez 3 à 5 jours de réplication initiale, puis synchronisation continue jusqu'au jour J.

Phase 4 : Tests et validation (semaine 3)

Environnement de test obligatoire :

  • Clonez votre environnement de production vers un environnement de staging
  • Exécutez tous les tests fonctionnels
  • Vérifiez les performances (latence, throughput)
  • Testez les connexions applicatives
  • Validez les backups et restaurations

Phase 5 : Migration finale (week-end ou nuit)

Checklist de basculement :

  1. Arrêtez les écritures sur l'application source
  2. Attendez la fin de la réplication DMS
  3. Appliquez les derniers changements manuels
  4. Mettez à jour les DNS (Route 53 avec TTL bas au préalable)
  5. Démarrez l'application sur AWS
  6. Vérifiez les logs et monitors
  7. Gardez l'environnement source « froid » pendant 48h

Les services AWS essentiels pour votre lift-and-shift

Calcul

Amazon EC2 : Le pilier de votre migration. Pour une application monolithique Windows :

  • Instances M5 : Bon équilibre CPU/mémoire pour la plupart des workloads
  • Instances R5 : Optimisées mémoire, idéales pour SQL Server
  • Instances T3 : Burst capable, économiques pour les environnements de dev/test

AWS Elastic Beanstalk : Alternative intéressante si votre application supporte un déploiement via WAR/ZIP. Gère automatiquement le capacity provisioning, le load balancing, et la surveillance.

Base de données

Amazon RDS : Service managé pour MySQL, PostgreSQL, SQL Server, Oracle, MariaDB.

Avantages concrets :

  • Patching automatique (fenêtre de maintenance configurable)
  • Sauvegardes automatisées avec rétention configurable
  • Haute disponibilité avec Multi-AZ (surveillance et failovers en 60-120 secondes)
  • Coût Multi-AZ : environ 2 fois le prix de l'instance single-AZ

Pour SQL Server : Version 2019 disponible, stockage jusqu'à 16 To par instance.

Stockage

Amazon EBS : Disques persistants pour vos instances EC2.

  • gp3 : 3 000 IOPS garanties, 125 Mo/s throughput —性价比最高
  • io2 : 99,999% durabilité, jusqu'à 64 000 IOPS par volume

Amazon S3 : Pour le stockage de fichiers, backups, logs. Coût : 0,023 $ par Go par mois (eu-west-1).

Réseau

Amazon VPC : Réseau virtuel isolé. Inclus dans le prix AWS standard.

Elastic Load Balancer (ALB/NLB) : Distribution du trafic, SSL termination, santé des instances.

Amazon Route 53 : Service DNS. 0,50 $ par zone hébergée + 0,40 $ par million de requêtes.

Optimisation des coûts post-migration

La migration n'est que le début. Optimiser vos coûts est essentiel pour justifier le projet.

Reserved Instances vs On-Demand

Pour une charge de travail permanente, les Reserved Instances (RI) offrent des économies de 30 à 72%.

Exemple : Une instance t3.medium Linux on-demand coûte 0,0416 $ par heure (≈ 365 $ par an). Une RI d'un an avec paiement intégral coûte 0,026 $ par heure (≈ 228 $ par an) — soit 37% d'économie.

Stratégie recommandée :

  1. Commencez en On-Demand pour valider les besoins réels
  2. Après 30-60 jours, achetez des RI pour la capacité de base
  3. Utilisez des Savings Plans pour plus de flexibilité

Right-sizing continu

AWS Compute Optimizer : Service gratuit qui analyse vos métriques CloudWatch et recommande des调整 de dimensionnement. Je l'active systématiquement sur tous mes projets post-migration.

Éteindre les environnements non productifs

  • Environnements de dev/test : Utilisez AWS Instance Scheduler pour éteindre automatiquement la nuit et le week-end
  • Économie potentielle : 65% sur ces environnements

Pièges courants et comment les éviter

1. Sous-estimer la bande passante de réplication

Pour une base de données de 2 To, une connexion de 100 Mbps prendra ~48 heures. Prévoyez une connexion plus rapide ou utilisez AWS Snowball si la bande passante est limitée.

2. Ignorer les dépendances cachées

J'ai vu des migrations échouer parce que l'équipe avait oublié :

  • Serveurs NTP pour la synchronisation temporelle
  • Serveurs LDAP/Active Directory pour l'authentification
  • Liens VPN vers des partenaires

Solution : Documentez TOUTES les connexions réseau sortantes avant la migration.

3. Mal gérer les secrets et credentials

Ne codez jamais les mots de passe en dur. Utilisez AWS Secrets Manager (0,40 $ par secret par mois) ou AWS Systems Manager Parameter Store (gratuit pour les paramètres standards).

4. Oublier la compatibilité applicative

Certaines applications anciennes (Windows Server 2003, SQL Server 2008 R2) ne sont pas supportées par AWS ou nécessitent des licences spéciales. Vérifiez avant de planifier.

Mesurer le succès de votre migration

KPIs à suivre

Indicateur Cible lift-and-shift
Disponibilité ≥ 99,95%
Temps de migration < 8 semaines
Coût vs on-premise -30% à -50%
Performance applicative Latence < référence on-premise
Incidents post-migration < 5 dans les 30 premiers jours

Retour d'expérience clients

Secteur manufacturier : Migration d'un ERP SAP ECC6 sur 12 serveurs. Coût annualisé réduit de 280 000 € à 145 000 € (48% d'économie). Temps de migration : 6 semaines.

Santé : Réhébergement d'une application de gestion patient (HIPAA required). Mise en conformité via encryption au repos et VPC isolés. Migration validée par un audit externe.

Prochaine étape : êtes-vous prêt pour la modernisation ?

Le lift-and-shift est une étape, pas une destination. Une fois stabilisé sur AWS, vous pouvez progressivement moderniser :

  1. Containerisation : Déployez votre monolithique sur ECS ou EKS
  2. Découpage incrémental : Extrayez les modules les plus critiques en microservices
  3. Passage aux services managés : Remplacez vos instances EC2 par des services comme Lambda, Fargate, ou RDS

Ciro Cloud accompagne les entreprises françaises dans leur parcours de migration cloud, de la stratégie lift-and-shift jusqu'à la modernisation complète. Notre équipe d'architectes certifiés AWS dispose de plus de 10 ans d'expérience en projets de migration complexes.

Vous souhaitez évaluer le potentiel de migration de votre infrastructure actuelle ? [Contactez nos experts pour un assessment gratuit] — nous livrons un rapport détaillé sous 5 jours ouvrés.

Insights cloud hebdomadaires — gratuit

Guides pratiques sur les coûts cloud, la sécurité et la stratégie. Sans spam.

Comments

Leave a comment