Migration legacy vers moderne : réécriture sans tout casser

La dette technique n'est pas une fatalite

Votre produit marche. Il a des clients, du chiffre d'affaires, une equipe. Mais la codebase est un heritage : PHP procedural, jQuery spaghetti, base MySQL non normalisee, deploiement manuel en FTP. Chaque nouvelle feature est un calvaire. Chaque bug critique est une crise.

Vous avez deja envisage de tout recrire. Mais le risque est trop grand : 6 mois d'immobilisation, des bugs invisibles, une equipe qui ne connait pas le nouveau stack. Le CEO vous dit que le produit ne peut pas s'arreter.

Le paradoxe : Le code legacy rapporte de l'argent aujourd'hui mais empeche d'en gagner demain. Le recrire entierement est trop risqué. Ne rien faire est suicidaire a moyen terme.

Une migration par couches, pas par big bang

La seule facon de moderniser sans risquer la faillite technique : remplacer le legacy couche par couche, en parallele du produit en production. Voici l'approche qu'on utilise.

Phase 1 - Audit et strangle pattern

On commence par cartographier la codebase actuelle : quel code est critique, quel code est mort, quelles sont les dependances reelles. On identifie les points d'entree (routes API, pages) qu'on peut intercepter un par un.

Le pattern : on met un proxy (nginx, Cloudflare) devant l'existant. Chaque route est progressivement basculee vers le nouveau service sans que l'utilisateur ne voit rien.

Principe : Une route a la fois. Zero downtime. Possibilite de rollback instantane.

Phase 2 - Nouvelles briques, meme donnees

On construit les nouveaux services cote a cote avec l'ancien systeme. Meme base de donnee (pour commencer), meme authentification, meme session. On ajoute une couche API moderne (TypeScript, Hono/Express) qui consomme les memes donnees que le legacy.

Chaque nouvelle route est deployee, testee en parallele, puis le trafic est bascule. Si quelque chose cloche, on revient sur l'ancienne implementation en quelques secondes.

Phase 3 - Base de donnees

Une fois que les services sont migres, on s'attaque a la couche donnees. Migration progressive du schema : nouvelles tables, normalisation, indexation. On utilise des vues ou des triggers pour maintenir la compatibilite avec le legacy tant que tout n'est pas migre.

Phase 4 - Decommission

Quand tout le trafic passe par le nouveau stack, on eteint l'ancien. On conserve les donnees historiques en lecture seule pendant 6 mois, puis on archive.

Stack type pour une migration

Voici la stack qu'on met en place pour une migration propre :

• Hono ou Express : API layer moderne, compatible Cloudflare Workers ou Node.js.
• Drizzle ORM : migrations type-safe, compatibilite avec la base existante.
• Zod : validation des entrees/sorties pour eviter les regressions silencieuses.
• Vitest : tests de non-regression sur chaque route migree.
• OpenTelemetry : tracing distribue pour comparer les performances avant/apres.
• Feature flags : basculer les fonctionnalites individuellement sans deploiement.

Un exemple concret

Prenons un cas frequent : une plateforme e-commerce PHP/MySQL vieille de 8 ans, qui genere 2M€/an.

L'approche en retainer :

1. Mois 1 : Audit, mise en place du proxy, migration du catalogue produits (API read-only en TypeScript). Zero impact pour les clients.
2. Mois 2 : Migration du panier et du checkout. Tests de non-regression avec des donnees de production.
3. Mois 3 : Migration de l'admin et du back-office. Les equipes internes decouvrent le nouvel outil.
4. Mois 4-5 : Optimisation base de donnees, migration du schema, mise en place CI/CD.
5. Mois 6 : Decommission du legacy, monitoring, documentation.

Resultat : le site continue de tourner pendant toute la migration. Les clients ne voient rien. L'equipe interne decouvre progresivement le nouveau stack sans pression.

Resultat : Zero incident critique. Temps de reponse divises par 10. Deploiement en continu (vs 1 deploiement manuel par mois). Equipe interne capable de contribuer au nouveau stack des le mois 3.

Pourquoi le retainer est le meilleur format pour une migration

Une migration legacy, ce n'est pas un projet avec une date de fin. C'est un processus continu :

• Continuite : le meme developpeur connait votre codebase legacy et la nouvelle. Pas de transfert de connaissance perdu.
• Priorisation dynamique : un bug critique sur le legacy en production ? On stoppe la migration, on repare, on reprend.
• Budget previsible : X heures par mois. Pas de devis qui double parce qu'on a decouvert un probleme cache.
• Pas de rush final : on avance a rythme soutenable. Chaque mois est une etape qui tient seule.

Le meilleur investissement technique que vous puissiez faire : mettre votre codebase sur des bases saines sans mettre votre produit en danger.