Chaque organisation mature possède des systèmes legacy. La question n'est jamais de savoir s'il faut moderniser mais comment le faire sans arrêter la livraison de valeur métier. Le cimetière des réécritures "big bang" échouées est vaste. Les stratégies incrémentales gagnent.
Comparaison des patterns de migration
Pattern Approche Risque Durée Taille équipe Rollback Strangler Fig Remplacer pièce par pièce derrière une façade Faible Long (mois-années) Petite-Moyenne Par composant Branch by Abstraction Abstraire les interfaces, échanger les implem. Faible-Moyen Moyen Moyenne Par abstraction Parallel Run Ancien et nouveau en simultané, comparer Moyen Moyen Grande Instantané (garder l'ancien) Big Bang Rewrite Tout remplacer d'un coup Très élevé Long Grande Tout ou rien Lift and Shift Déplacer tel quel vers nouvelle infra Faible Court Petite Facile
tadata
PORTFOLIO: 9 applications retire 1 retain 1 rehost 1 relocate 1 replatform 2 repurchase 1 refactor 2 EFFORT BENEFIT APPLICATIONS (REASON) Retire (1) decommission: switch it off: nobody needs it any more Intranet wiki — replaced by SaaS docs, 3 users Retain (1) revisit: keep it where it is for now (not ready, recent upgrade, compliance) Mainframe billing — modernise in phase 2 Rehost (1) lift and shift: same servers moved to cloud VMs, no code change 40 Windows app VMs — data-centre exit in 9 months Relocate (1) hypervisor-level lift and shift: move the virtualised estate (e.g. VMware) as is vSphere analytics cluster — keep VMware tooling Replatform (2) lift, tinker and shift: a few cloud optimisations: managed database, containers Oracle ERP DB — RDS for Oracle, less DBA work MySQL on VMs — Aurora MySQL Repurchase (1) drop and shop: replace with a SaaS or another product On-prem CRM — move to SaaS CRM Refactor (2) re-architect: rebuild cloud-native: serverless, microservices, managed services Order service — peak scaling, serverless Batch reports — Glue + Athena on S3 Dots: effort (top row) and cloud benefit (bottom row), 0 to 4, relative to the other Rs. Rehost and relocate move fastest; refactor costs most and gains most.
PORTFOLIO: 9 applications retire 1 retain 1 rehost 1 relocate 1 replatform 2 repurchase 1 refactor 2 EFFORT BENEFIT APPLICATIONS (REASON) Retire (1) decommission: switch it off: nobody needs it any more Intranet wiki — replaced by SaaS docs, 3 users Retain (1) revisit: keep it where it is for now (not ready, recent upgrade, compliance) Mainframe billing — modernise in phase 2 Rehost (1) lift and shift: same servers moved to cloud VMs, no code change 40 Windows app VMs — data-centre exit in 9 months Relocate (1) hypervisor-level lift and shift: move the virtualised estate (e.g. VMware) as is vSphere analytics cluster — keep VMware tooling Replatform (2) lift, tinker and shift: a few cloud optimisations: managed database, containers Oracle ERP DB — RDS for Oracle, less DBA work MySQL on VMs — Aurora MySQL Repurchase (1) drop and shop: replace with a SaaS or another product On-prem CRM — move to SaaS CRM Refactor (2) re-architect: rebuild cloud-native: serverless, microservices, managed services Order service — peak scaling, serverless Batch reports — Glue + Athena on S3 Dots: effort (top row) and cloud benefit (bottom row), 0 to 4, relative to the other Rs. Rehost and relocate move fastest; refactor costs most and gains most.
Extrait de la fiche « SAP-C02 Migration 1: Assessment, 7 Rs and Tools » · Demander la fiche complète
Matrice d'évaluation des risques
Facteur de risque Faible (1) Moyen (2) Élevé (3) Complexité des données Schémas simples, peu de relations Schémas modérés, couplage partiel Schémas complexes, références croisées Nombre d'intégrations 0-3 systèmes en aval 4-10 systèmes en aval 10+ systèmes en aval Connaissance du domaine Bien documenté, équipe connaît Docs partielles, savoir tribal Pas de docs, équipe originale partie Criticité métier Outil interne Support du revenu Critique revenu, SLA lié Couverture de tests > 70% 30-70% < 30% ou inconnue Volume de données < 10Go 10Go-1To > 1To Contraintes réglementaires Aucune Piste d'audit nécessaire Certification conformité requise
Score : 7-10 = Strangler Fig ou Lift-and-Shift, 11-16 = Branch by Abstraction ou Parallel Run, 17-21 = commencer par une phase d'évaluation.
Le piège de la parité fonctionnelle
tadata
Problème Piège de la parité fonctionnelle : « encore une fonctionnalité » avant de pouvoir basculer. Le legacy continue d'évoluer, la cible bouge et la bascule prévue est ratée pendant que l'effort ne cesse de croître Solutions possibles Définir un ensemble de fonctionnalités GELÉ + Les nouvelles fonctionnalités vont uniquement au nouveau système − Accepter des manques temporaires
Problème Piège de la parité fonctionnelle : « encore une fonctionnalité » avant de pouvoir basculer. Le legacy continue d'évoluer, la cible bouge et la bascule prévue est ratée pendant que l'effort ne cesse de croître Solutions possibles Définir un ensemble de fonctionnalités GELÉ + Les nouvelles fonctionnalités vont uniquement au nouveau système − Accepter des manques temporaires Principes clés
Migrer les données en dernier . Déplacez le routage et le calcul d'abord. La migration de données est l'étape la plus risquée et la plus irréversible.
Mesurer la parité, ne pas la ressentir . Définissez des critères quantitatifs : latence P99, taux d'erreur, débit. "Ça semble marcher" n'est pas un critère de migration.
Budgéter la longue traîne . Les derniers 10% de la migration prennent 50% de l'effort. Les cas limites et comportements non documentés vivent dans cette traîne.
Ressources