Stratégies de migration 6R / 7R : classer chaque application

Migrer 200 applications vers le cloud n’est pas un projet uniforme — chaque application a sa propre stratégie optimale de migration selon sa criticité, son architecture, son cycle de vie. Le cadre 6R (rebaptisé 7R depuis 2021) classe chaque application dans 7 stratégies : Rehost, Replatform, Refactor, Repurchase, Retain, Retire, Relocate. Cette page détaille chaque stratégie avec ses cas d’usage et ses pièges, présente la matrice effort × valeur, et défend une opinion : le « lift-and-shift universel » est le piège le plus coûteux des migrations — la rationalization honnête, application par application, est la discipline qui sépare les migrations réussies des échecs.

Ce que vous allez apprendre

Les 7 stratégies de migration : Rehost, Replatform, Refactor, Repurchase, Retain, Retire, Relocate
Les critères de choix pour chaque stratégie
La matrice effort × valeur pour visualiser les arbitrages
Comment classer 200 applications en quelques jours via la rationalization
Les anti-patterns classiques de migration

Prérequis : avoir compris les Cloud Adoption Frameworks. Si besoin, lisez d’abord Cloud Adoption Frameworks (CAF).

1. Origine et évolution

Le cadre 6R a été formalisé par Gartner en 2011, puis adopté et popularisé par AWS dans son AWS CAF. Les 6 R d’origine étaient : Rehost, Replatform, Refactor, Repurchase, Retain, Retire.

En 2021, AWS a ajouté un 7e R — Relocate — pour formaliser les migrations vers VMware Cloud on AWS et autres plateformes hybrides similaires. Le cadre 7R est devenu le standard depuis.

Microsoft Azure et Google Cloud ont adopté le même vocabulaire, avec des nuances mineures. Le vocabulaire est universel quel que soit le fournisseur.

2. Les 7 stratégies en détail

Stratégie 1 — Rehost (lift-and-shift)

Définition : déplacer l’application telle quelle vers le cloud, sans modification. La VM physique on-prem devient une VM cloud avec la même OS, les mêmes binaires, la même configuration.

Avantages :

Plus rapide : quelques jours par application.
Risque faible : l’application reste identique, peu de surprises fonctionnelles.
Compétences requises : faibles (juste un Ops capable de migrer une VM).

Inconvénients :

Pas d’optimisation cloud : on paye le cloud sans bénéficier de ses propriétés.
Coût souvent supérieur à l’on-prem si la VM est sur-dimensionnée 24/7.
Dette technique préservée : tous les anti-patterns on-prem migrent avec.

Cas d’usage typique : urgence (datacenter à fermer dans 6 mois), application stable sans roadmap d’évolution, première étape avant Replatform plus tard.

Outils : AWS Application Migration Service (MGN), Azure Migrate, Google Cloud Migrate to Virtual Machines.

Stratégie 2 — Replatform (lift-tinker-and-shift)

Définition : migrer l’application en adaptant légèrement sans refondre. Typiquement, remplacer un composant on-prem par un service managé équivalent.

Exemples concrets :

Base PostgreSQL on-prem → AWS RDS PostgreSQL (Replatform DB).
Serveur de mails on-prem → Office 365 (Repurchase) ou Postfix sur VM cloud (Replatform si on garde le code).
Cluster Apache → AWS Elastic Beanstalk (Replatform plateforme).

Avantages :

Bénéfices cloud immédiats sur le composant remplacé (HA managée, backups automatiques).
Effort modéré : adaptation de quelques jours à quelques semaines par app.
Retour sur investissement rapide.

Inconvénients :

Lock-in modéré : utilisation de services managés spécifiques au fournisseur.
Risque de régression : adaptation peut introduire bugs.

Cas d’usage typique : application active avec roadmap, base de données qui mérite une montée en gamme, composants stables qui peuvent être managés.

Stratégie 3 — Refactor (re-architect)

Définition : réécrire l’application en cloud-native pour exploiter pleinement les propriétés du cloud (élasticité, microservices, serverless).

Exemples concrets :

Monolithe Java → microservices conteneurisés sur Kubernetes managé.
Application web sur VM → Frontend statique CDN + API serverless.
Batch nuit → fonctions FaaS event-driven.

Avantages :

Bénéfices cloud maximaux : élasticité, scalabilité, coûts optimisés.
Modernisation technique : pile à jour, dette technique éliminée.
Vélocité accrue des équipes ensuite.

Inconvénients :

Effort très élevé : 6 à 24 mois par application.
Risque élevé : réécriture complète, fonctionnalités à re-tester.
Compétences requises : architectes cloud-native, dev expérimentés.
Coût initial important avant ROI.

Cas d’usage typique : application stratégique avec roadmap longue, croissance utilisateur attendue, dette technique forte qui freine l’innovation.

Stratégie 4 — Repurchase (drop-and-shop)

Définition : remplacer l’application par une alternative SaaS existante. Pas de migration au sens technique — on arrête l’ancienne et on adopte la nouvelle.

Exemples concrets :

ERP custom on-prem → SAP S/4HANA Cloud, Workday.
CRM custom → Salesforce, HubSpot.
Outil de tickets → Jira Cloud, Zendesk.
Email + collab → Microsoft 365, Google Workspace.

Avantages :

Plus de gestion technique : 100 % SaaS, le fournisseur gère tout.
Mise à jour continue des fonctionnalités.
Coût TCO souvent inférieur sur 5 ans.

Inconvénients :

Migration des données complexe et risquée.
Fonctionnalités custom parfois perdues — l’organisation doit s’adapter.
Lock-in SaaS fort — sortir d’un SaaS adopté est très coûteux.

Cas d’usage typique : application standard du métier (CRM, ERP, RH, ticketing), pas de différenciation concurrentielle, équipe technique non spécialiste de cette application.

Stratégie 5 — Retain (revisit)

Définition : garder l’application on-prem, ne pas migrer pour le moment. Décision assumée, pas par défaut.

Cas d’usage légitimes :

Contraintes réglementaires strictes : application traitant des données impossibles à mettre dans le cloud (défense, certaines données de santé).
Application en fin de vie : sera déprécée dans 18 mois, migration non rentable.
Coût de migration > bénéfice : le TCO cloud est plus élevé que l’on-prem actuel.
Latence critique : application industrielle exigeant < 1 ms vers des capteurs locaux.
Dépendance à du matériel spécialisé non disponible en cloud.

Cas d’usage problématique : « on retain parce qu’on n’a pas le temps de migrer » — c’est procrastiner, pas une décision Retain. La discipline exige de documenter pourquoi on retain.

Stratégie 6 — Retire (deprecate)

Définition : arrêter l’application, pas de migration du tout. La fonction est-elle encore utilisée ? Peut-elle être absorbée par un autre système ?

Découverte typique : l’inventaire applicatif révèle que 20 à 30 % des applications ont peu ou pas d’usage réel. Beaucoup ont été développées pour un besoin ponctuel et continuent à tourner par inertie.

Bénéfices :

Économie immédiate : licences, infrastructure, maintenance.
Réduction de la surface d’attaque : moins d’applications, moins de risques de sécurité.
Simplification du SI : moins à gérer.

Cas d’usage typique : applications « zombies » sans utilisateurs réels, fonctions remplacées par d’autres outils non décommissionnés, projets pilotes oubliés.

Stratégie 7 — Relocate (le 7e R, AWS 2021)

Définition : déplacer l’application vers une plateforme hybride qui réplique l’environnement on-prem dans le cloud, sans modification.

Exemples concrets :

VMware on-prem → VMware Cloud on AWS (mêmes outils VMware, même API).
VMware on-prem → Azure VMware Solution ou Google Cloud VMware Engine.

Avantages :

Migration ultra-rapide : copie des VMs sans transformation.
Aucune modification des outils ou processus existants.
Bridge entre on-prem traditionnel et cloud-native (étape transitoire).

Inconvénients :

Coût élevé : VMware Cloud est typiquement 30–50 % plus cher qu’EC2 équivalent.
Pas de bénéfice cloud-native : on paye le cloud sans en exploiter les services managés.
Lock-in double : à VMware et au fournisseur cloud.

Cas d’usage typique : large parc VMware on-prem à fermer rapidement, équipes formées exclusivement à VMware, étape transitoire avant Replatform/Refactor.

3. La matrice effort × valeur

Pour visualiser les arbitrages entre les 7 stratégies, la matrice effort × valeur business est l’outil de décision le plus utile.

Valeur business
    ↑
    │
    │  ┌──────────────┬──────────────┐
    │  │              │              │
    │  │   Refactor   │  Repurchase  │
    │  │   (élevée)   │              │
H   │  │              │              │
A   │  ├──────────────┼──────────────┤
U   │  │              │              │
T   │  │  Replatform  │   Rehost     │
E   │  │              │              │
    │  │              │              │
    │  ├──────────────┼──────────────┤
    │  │              │              │
B   │  │   Relocate   │   Retain     │
A   │  │              │              │
S   │  │              │              │
S   │  │  ─ Retire ─  │              │
E   │  │              │              │
    │  └──────────────┴──────────────┘
    │      Effort élevé    Effort faible    →
    └────────────────────────────────────────→

Lecture :

Refactor est haute valeur mais effort élevé : pour les applications stratégiques uniquement.
Rehost est faible valeur mais faible effort : pour gagner du temps, en sachant qu’on optimisera plus tard.
Retain est dans le quadrant bas : ne pas migrer une app qui n’a pas de valeur cloud.
Retire est encore plus bas : vraie économie quand on supprime.

4. Critères de choix par stratégie

Application	Stratégie recommandée
Stratégique, roadmap longue, croissance attendue	Refactor
Active mais stable, composants standards	Replatform
Standard métier (CRM, ERP, RH)	Repurchase (SaaS)
Stable, urgence de fermer le datacenter	Rehost
Légalement impossible à migrer	Retain (assumé)
Sans utilisateurs ou fonction obsolète	Retire
Large parc VMware, transition rapide	Relocate

Questions à se poser pour chaque application

📊 Quelle est sa valeur business ?

Si l’application est critique au métier ou différenciante par rapport à la concurrence, elle mérite Refactor. Sinon, Replatform ou Rehost suffit.

🛠️ Quel est l'effort de migration ?

Évaluer en jours-personnes : Rehost (10–30 j/h), Replatform (50–150), Refactor (300–2000+). Le ROI doit justifier l’effort.

📅 Quel est son cycle de vie restant ?

Une app qui sera dépréciée dans 18 mois ne mérite pas Refactor. Rehost ou Retire selon le besoin.

🔒 Y a-t-il des contraintes légales ?

Données réglementées (santé, défense, finance) peuvent imposer Retain ou un cloud souverain spécifique pour Refactor.

5. Le processus de rationalization — classer 200 applications en 4 semaines

Voici la méthode pratique pour appliquer 7R à un parc applicatif réel.

Étape 1 — Inventaire (semaine 1)

Lister toutes les applications avec leurs métadonnées : criticité business (1-5), nombre d’utilisateurs, technologie, dépendances, coût annuel actuel, équipe propriétaire, roadmap connue.

Sources : CMDB, équipes Ops, équipes produit, contrats de support.

Étape 2 — Pré-classification (semaine 2)

Première passe rapide pour classer chaque application avec 2 critères :

Valeur business : critique / standard / faible.
Cycle de vie : actif (roadmap) / stable / fin de vie.

Cette pré-classification donne une intuition forte de la stratégie probable. Une app faible valeur + fin de vie sera quasi-certainement Retire. Une app critique + active sera Refactor ou Replatform.

Étape 3 — Validation par workshop (semaines 3-4)

Sessions de 2 heures avec les équipes propriétaires par application. Validation de la stratégie pré-classifiée, ajustement selon les contraintes terrain. Cette étape ne peut pas être sautée — les équipes connaissent leurs apps mieux que les architectes centralisés.

Étape 4 — Priorisation et roadmap

Trier les applications par vague de migration :

Vague 1 (mois 1-6) : Retire (gain immédiat) + Rehost faciles (apps stables non critiques).
Vague 2 (mois 6-18) : Replatform + Repurchase.
Vague 3 (mois 18-36) : Refactor (apps stratégiques modernisées).

Cette séquence dans le temps est aussi importante que la stratégie individuelle.

6. Anti-patterns classiques de migration

Anti-pattern 1 — Lift-and-shift universel. « On migre tout en Rehost pour aller vite, on optimisera après ». Conséquence : facture cloud explose, aucun bénéfice, dette technique préservée. Le « après » n’arrive jamais. Discipline : 7R obligatoire app par app, pas un seul Rehost universel.

Anti-pattern 2 — Refactor partout. « Tant qu’à migrer, autant tout réécrire en cloud-native ». Conséquence : projet de 5 ans qui n’aboutit jamais, équipes épuisées, retour arrière coûteux. Discipline : Refactor uniquement sur les apps stratégiques avec ROI calculé.

Anti-pattern 3 — Pas de Retire. Aucun examen critique des apps : tout est gardé « au cas où ». Conséquence : 30 % de la facture cloud paye des apps zombies. Discipline : Retire systématiquement examiné en première option. Si on hésite, on Retire — on peut toujours redéployer ultérieurement.

Anti-pattern 4 — Ignorer Repurchase. Réécrire en cloud un CRM custom alors qu’un SaaS standard existe à 90 % du périmètre. Conséquence : 18 mois de développement pour reconstruire ce qui existe. Discipline : pour chaque app, demander s’il existe un SaaS alternatif avant de Refactor.

Anti-pattern 5 — Pas de séquencement temporel. Migrer toutes les apps en parallèle. Conséquence : équipes débordées, qualité dégradée, échecs en cascade. Discipline : vagues de migration ordonnées (Retire et Rehost faciles d’abord), montée en compétence progressive.

7. Bonnes pratiques pour conduire une migration 7R

Une migration 7R réussie repose moins sur la maîtrise individuelle de chaque stratégie que sur la discipline méthodologique appliquée à l’ensemble du parc. Trois axes structurent une démarche qui tient dans la durée.

Investir dans la phase de rationalization. Avant la première migration, prendre quelques semaines pour réaliser un inventaire complet du parc applicatif (criticité, dépendances, propriétaire métier, dette technique) et pré-classifier chaque application sur la grille 7R. Cet investissement initial évite des erreurs coûteuses en aval (Rehost d’applications qui auraient dû être retired, Refactor d’applications en fin de vie). Les organisations qui sautent cette étape y reviennent généralement plus tard, après avoir accumulé des décisions sous-optimales.

Examiner Retire en première option. La culture organisationnelle pousse souvent à conserver toutes les applications par défaut, par peur de perdre une donnée ou un cas d’usage marginal. En pratique, une part significative des applications d’un parc traditionnel n’apporte plus de valeur métier mesurable. Pour chaque application, demander au propriétaire métier de justifier sa conservation par un usage actuel. Sans justification, retirer l’application est souvent le bon choix — quitte à pouvoir la redéployer plus tard si un besoin réapparaît.

Calibrer la part de Refactor sur la valeur stratégique. Le Refactor (réécriture cloud-native) apporte les bénéfices les plus importants en termes d’élasticité, de scalabilité et de coût d’exploitation, mais c’est aussi la stratégie la plus coûteuse en temps et en risque. Réserver Refactor aux applications stratégiques (cœur métier, exposition forte, croissance attendue) évite de mobiliser les équipes sur des chantiers à faible ROI. Pour la majorité du parc, Replatform apporte une grande partie des bénéfices à un coût modéré.

Séquencer en vagues homogènes. Plutôt que de migrer toutes les applications en parallèle, organiser la migration en vagues par stratégie : d’abord les Retire (gain immédiat, libère des ressources), puis les Rehost simples (montée en compétence des équipes), ensuite les Replatform et les Repurchase, enfin les Refactor stratégiques. Cette progression permet de capitaliser sur les apprentissages de chaque vague.

À retenir

7R classifie chaque application : Rehost, Replatform, Refactor, Repurchase, Retain, Retire, Relocate.
Rehost = lift-and-shift rapide mais sans bénéfice cloud. Replatform = adaptation modérée, ROI rapide. Refactor = réécriture cloud-native, élevé.
Repurchase = remplacement par SaaS standard. Retain = garder on-prem (assumé). Retire = arrêter (souvent oublié). Relocate = VMware Cloud (transitoire).
La matrice effort × valeur guide les arbitrages : Refactor pour stratégique, Rehost pour rapide, Retire pour zombies.
Rationalization en 4 semaines (inventaire + pré-classification + validation + roadmap) économise 6 à 18 mois.
Anti-patterns : lift-and-shift universel, Refactor partout, pas de Retire, ignorer Repurchase, pas de séquencement.
Bonnes pratiques : investir dans la rationalization initiale, examiner Retire en première option, réserver Refactor aux applications stratégiques, séquencer la migration en vagues homogènes.

Prochaines étapes

Cloud Adoption Frameworks (CAF) Le framework de structuration globale de l'adoption cloud.

TCO cloud vs on-premise Le calcul de business case qui justifie le choix de stratégie 7R.

Modèles de déploiement Public, privé, hybride, sovereign : où placer chaque application migrée.

IaaS, PaaS, SaaS, FaaS, CaaS Le modèle XaaS qui correspond à chaque stratégie de migration.