Migration et reprise de legacy

Toutes les entreprises que nous accompagnons ont, quelque part, une application dont le prestataire est parti, dont la technologie n'est plus maintenue, ou dont personne ne comprend plus une partie du code. La réécriture complète en un bloc est le réflexe — et la façon la plus fiable d'échouer : pendant dix-huit mois, plus rien n'avance côté métier, et le jour de la bascule on découvre les règles qu'on avait oubliées. Nous migrons écran par écran, avec l'ancienne et la nouvelle version qui coexistent, jusqu'à ce qu'il ne reste plus rien à migrer.

Ce que vous recevez

Les livrables

• check_circleL'inventaire de l'existant : ce qui sert, ce qui ne sert plus, ce qui est risqué
• check_circleLe plan de migration par lots, avec l'ordre et le retour arrière de chacun
• check_circleL'application migrée, à comportement identique et vérifié écran par écran
• check_circleL'ancienne version coupée, et sa documentation archivée

Questions fréquentes

Il faut arrêter l'activité pendant la migration ?

Non, c'est tout l'intérêt de migrer par morceaux. Vos équipes continuent de travailler, et basculent écran par écran. Nous menons actuellement plusieurs migrations de ce type, sur des applications utilisées tous les jours.

Vous reprenez du code écrit par quelqu'un d'autre ?

C'est une grande partie de notre travail. PHP, Symfony, WordPress, Node ancien : nous reprenons, nous stabilisons, puis nous décidons ensemble ce qui vaut la peine d'être migré et ce qui peut rester tel quel.

Combien de temps ça prend ?

Une migration sérieuse se compte en mois, parfois en années sur une grosse application. Mais l'activité n'attend pas la fin : dès le premier lot, vous récupérez des écrans plus rapides et plus faciles à faire évoluer.