La migration cloud est probablement le projet le plus sous-estimé de la décennie. Tout le monde pense que c'est un déplacement. C'est une transformation. Et comme toute transformation, elle échoue quand on la traite comme un simple lifting.
McKinsey estime que 60% des migrations cloud ne livrent pas la valeur attendue. Ce n'est pas parce que le cloud est mauvais. C'est parce que la migration est mal préparée.
Le mythe du "lift and shift"
Le lift and shift — prendre votre serveur on-prem et le coller dans une VM cloud — est la stratégie de migration la plus commune et la plus dangereuse. Une base de données conçue pour un serveur avec 256 Go de RAM et un disque NVMe local ne se comporte pas de la même façon sur une instance cloud avec un stockage réseau EBS.
La latence de stockage change. Le réseau entre l'application et la base change. J'ai vu des requêtes qui mettaient 50ms on-prem passer à 800ms sur RDS — sans aucun changement de code. L'application faisait des allers-retours constants avec la base, invisible en local mais mortel sur le réseau cloud.
Les coûts invisibles qui vous attendent
- L'egress — Sortir vos données du cloud coûte plus que les y faire entrer. AWS facture $0.09/GB en sortie. Si vous synchronisez avec un data warehouse on-prem, la facture explose.
- Les snapshots — Sur une base de 500 Go avec 30 jours de rétention, vous payez pour 15 To de stockage de sauvegarde.
- Le NAT gateway — Pour que vos instances privées accèdent à Internet, vous passez par un NAT gateway qui facture au gigaoctet.
- Le support — Le support Business de AWS coûte 10% de votre facture mensuelle. Sur 50K€/mois, c'est 5 000€ de support.
Le jour J : ce qui se passe vraiment
1. La latence change. Vos utilisateurs qui étaient à 2ms de votre serveur on-prem sont maintenant à 50ms de votre instance cloud. Si votre application n'est pas conçue pour tolérer cette latence, le temps de chargement explose.
2. Le DNS se propage lentement. Vous changez votre enregistrement DNS. Mais les caches DNS des FAIs mettent jusqu'à 48h à se mettre à jour. Pendant ce temps, la moitié de vos utilisateurs sont sur l'ancien serveur, l'autre sur le nouveau.
3. Les connexions existantes se cassent. Les pools de connexions pointent vers l'ancienne IP. Les jobs planifiés ont l'ancienne chaîne en dur. Les rapports SSRS ont l'ancien serveur. Vous découvrez ces dépendances au fur et à mesure qu'elles cassent.
Le plan de rollback que personne ne teste
Tout le monde a un plan de rollback. Personne ne le teste. Un plan de rollback non testé n'est pas un plan — c'est un vœu pieux. Le rollback doit être testé en conditions réelles, avec le volume de données réel, avant le jour J. Si vous ne pouvez pas revenir en arrière en moins de 30 minutes, votre plan est insuffisant.
La méthode en 5 étapes
Étape 1 : Audit pré-migration. Cartographier toutes les dépendances. Mesurer les performances actuelles comme baseline. Identifier les requêtes qui font des allers-retours.
Étape 2 : Refactoring avant migration. Optimiser ce qui peut l'être avant de migrer. Réduire les allers-retours application-base. Mettre en cache ce qui peut l'être.
Étape 3 : Migration de test. Migrer une copie des données. Tester en conditions réelles. Comparer avec la baseline. Si quelque chose est 5x plus lent, le corriger avant la production.
Étape 4 : Run parallel. Faire tourner les deux systèmes en parallèle pendant 2 semaines. Comparer les résultats. Vérifier la cohérence des données.
Étape 5 : Cutover avec rollback testé. Le jour J, basculer. Mais avec un plan de rollback testé qui prend moins de 30 minutes.
Les 60% de migrations qui échouent ne sont pas des échecs techniques. Ce sont des échecs organisationnels. Le cloud n'est pas une destination. C'est un changement de modèle.
Préparer votre migration ?
Aprilium accompagne les entreprises dans leurs migrations cloud les plus critiques. Audit pré-migration, plan de rollback, tests de charge — nous couvrons tout.
Demander un audit gratuit