| name | cloud-migration-planner |
| description | Planification de migration vers le cloud incluant assessment, stratégie, lift-and-shift et refactoring. Se déclenche avec "migration cloud", "lift and shift", "cloud migration", "on-premise vers cloud", "migration strategy", "6 R's. Also triggers on "migrate to the cloud", "lift and shift plan", "cloud migration assessment". |
Cloud Migration Planner
Workflow en 8 étapes
1. Inventaire applicatif
Cartographier chaque application : stack technique, dépendances inter-services, flux réseau, volumes de données, SLAs.
Outils recommandés :
- AWS : AWS Application Discovery Service (
aws discovery start-import-task)
- Azure : Azure Migrate (
az migrate project create)
- GCP : Migrate to Virtual Machines + Service Catalog
Livrable minimal : tableur avec colonnes App | Stack | Deps | Trafic (Go/mois) | RTO | RPO | Owner.
2. Assessment de compatibilité
Pour chaque application, évaluer sur 4 axes (noter de 1 à 5) :
| Axe | Questions clés |
|---|
| Complexité technique | Couplage fort ? API propriétaire ? OS obsolète ? |
| Criticité métier | Impact si down > 1h ? Régulé ? |
| Dépendances | Combien de services liés ? Dépendances cycliques ? |
| Portabilité | Stateless ? Containerisable ? Licences cloud-compatible ? |
Score ≤ 8/20 → candidat Retire/Retain. Score ≥ 15/20 → candidat Refactor.
3. Stratégie par application (6 R's)
| Stratégie | Quand choisir | Effort | Gain cloud |
|---|
| Rehost (lift-and-shift) | VM legacy, contrainte temps | Faible | Faible |
| Replatform | DB vers RDS/Managed, peu de code | Moyen | Moyen |
| Refactor | App stratégique, cloud-native cible | Élevé | Fort |
| Repurchase | Remplacer par SaaS (ex. CRM → Salesforce) | Moyen | Variable |
| Retire | App inutilisée ou redondante | Minimal | — |
| Retain | App réglementée ou trop risquée pour migrer | — | — |
Règle empirique 2026 : 40-50 % Rehost pour la 1ère vague, puis réduire à mesure que les équipes montent en compétence.
4. Architecture cloud cible
Concevoir avant de migrer. Points incontournables :
Réseau :
On-premise ──[ VPN IPSec / ExpressRoute / Direct Connect ]──► VPC/VNet
├── Subnet public (Load Balancer, Bastion)
├── Subnet privé (App Tier)
└── Subnet data (DB, Cache)
Sécurité :
- IAM : principe du moindre privilège, rôles par environnement
- Chiffrement at-rest (KMS/CMK) et in-transit (TLS 1.2+)
- WAF + DDoS protection dès la 1ère vague
Conformité RGPD : choisir une région EU (eu-west-*, westeurope, europe-west1). Activer audit logs.
5. Planification des vagues
Critères de priorisation d'une vague :
- Faible dépendance aux autres apps
- Criticité métier modérée (pas de cœur de métier en V1)
- Équipe applicative disponible pour les tests
Structure type :
Vague 1 (semaines 1-4) : apps Rehost stateless, non critiques
Vague 2 (semaines 5-10) : apps Replatform (DB managées, queues)
Vague 3 (semaines 11+) : apps Refactor, services critiques
Créer une fiche de vague avec : Apps migrées | Date bascule | Rollback deadline | Owner.
6. Connectivité hybride
AWS :
aws ec2 create-vpn-connection \
--type ipsec.1 \
--customer-gateway-id cgw-xxx \
--vpn-gateway-id vgw-xxx
Azure :
az network vpn-connection create \
--name onprem-to-azure \
--resource-group rg-migration \
--vnet-gateway1 vgw-prod \
--local-gateway2 lng-onprem \
--shared-key "ChangeMe!2026"
GCP :
gcloud compute vpn-tunnels create onprem-tunnel \
--peer-address=<IP_ONPREM> \
--shared-secret=<SECRET> \
--target-vpn-gateway=vpn-gw-prod \
--region=europe-west1
Valider avec un ping entre sous-réseaux avant toute migration de données.
7. Exécution et validation
Checklist par application avant bascule :
Bascule progressive recommandée : 5 % → 25 % → 100 % via weighted DNS ou load balancer rules.
8. Optimisation post-migration
Actions systématiques à J+30 :
- Right-sizing : analyser CPU/RAM réelle sur 2 semaines, redimensionner
- Reserved Instances / Savings Plans : committer sur les workloads stables (économies 30-60 %)
- Auto-scaling : remplacer les instances fixes par des groupes auto-scalants
- Désinstallation on-premise : décommissionner les serveurs migrés après 30 jours de stabilité cloud
aws compute-optimizer get-ec2-instance-recommendations \
--filters Name=Finding,Values=OVER_PROVISIONED
Garde-fous / Anti-patterns
| Anti-pattern | Risque | Correction |
|---|
| Migration big-bang de tout le SI | Incident majeur, rollback impossible | Toujours par vagues |
| Lift-and-shift d'une DB Oracle sans license check | Facture x10 | Vérifier BYOL vs License Included avant |
Ouvrir les security groups trop large (0.0.0.0/0) | Exposition critique | Principe du moindre privilège dès le départ |
| Ignorer les egress costs | Surprise de facturation | Chiffrer les flux inter-régions/inter-clouds |
| Migrer sans monitoring | Impossible de détecter régressions | Observability stack AVANT la 1ère vague |
| Oublier les secrets dans le code (env vars hardcodées) | Fuite de credentials | Scan automatique (GitGuardian, truffleHog) + Secrets Manager |
| Négliger la formation des équipes | Dette opérationnelle | FinOps + CloudOps training dès la vague 1 |
Bonnes pratiques 2026
- FinOps dès le jour 1 : tagging systématique (
env, team, app, cost-center) — sans tags, pas de chargeback possible.
- Infrastructure as Code obligatoire : Terraform ou Bicep pour tout ce qui est créé (pas de clic console en production).
- GitOps pour les déploiements : pipelines CI/CD cloud-native (GitHub Actions, Azure DevOps, Cloud Build) dès la vague 1.
- Zero Trust Networking : segmenter par workload, pas par périmètre réseau.
- Sustainability : choisir des régions à faible PUE / énergie renouvelable si SLA le permet (ex.
northeurope, us-west-2).
