01Pourquoi les réécritures s'enlisent
Une réécriture doit atteindre la parité fonctionnelle avec une décennie de comportements non documentés avant de livrer le moindre bénéfice. Pendant ce temps, l'ancien système continue de changer, et l'écart ne se referme jamais.
On demande à l'entreprise de financer deux systèmes et d'attendre. L'enthousiasme s'épuise avant la date de bascule.
02Étrangler plutôt que réécrire
Placez une couche de routage devant le système existant, déplacez une capacité à la fois derrière elle, et laissez chaque déplacement apporter sa propre valeur.
Commencez par une tranche à forte douleur et faible couplage — reporting, notifications, portail client — pour instaurer la confiance et prouver la méthode.
03La donnée est la partie difficile
Planifiez tôt l'écriture double ou la capture de changement de données, et décidez comment vous détecterez les divergences. La plupart des incidents de migration sont des écarts de données, pas des pannes de code.
Gardez un chemin réversible pour chaque étape. Si vous ne pouvez pas revenir en arrière sur une tranche en moins d'une heure, la tranche est trop grande.
04Documenter en avançant
Chaque capacité extraite est l'occasion d'écrire la règle qu'elle encode. Cette documentation est souvent l'artefact le plus précieux de tout le programme.
