Une migration d'application est l'un des projets les plus risqués en développement logiciel. Les données existantes doivent être préservées, le service ne peut pas être interrompu, et les utilisateurs ne doivent percevoir aucune dégradation.
Nticstudio gère des migrations techniques dans le cadre de l'offre Build : changements de stack, migrations de base de données, passage d'un hébergeur à un autre, et consolidation d'applications legacy.
Types de migrations et leurs complexités respectives
Migration de base de données : changer de SGBD (MySQL vers PostgreSQL, MongoDB vers PostgreSQL) ou faire évoluer le schéma d'une base volumineuse. Complexité : élevée si les données sont volumineuses ou si le schéma change en profondeur.
Migration d'infrastructure : passer d'un hébergeur à un autre, ou d'une architecture serveur à une architecture cloud. Complexité : modérée si l'application est correctement containerisée.
Migration de stack : réécrire une application dans un nouveau langage ou framework (PHP legacy vers Node.js, monolithe vers microservices). Complexité : très élevée, souvent équivalente à un redéveloppement complet.
Stratégie de migration sans interruption
La stratégie « strangler fig » consiste à remplacer progressivement les modules d'un système existant par la nouvelle implémentation, en faisant coexister l'ancien et le nouveau jusqu'à la migration complète. Elle réduit le risque mais allonge la durée.
La migration « big bang » migre tout en une seule opération, généralement lors d'une fenêtre de maintenance planifiée. Elle est plus risquée mais plus rapide. Elle est adaptée quand la coexistence est trop complexe à gérer.
Migration des données : script, validation et rollback
Tout script de migration de données doit être : idempotent (peut être rejoué sans créer de doublons ou d'incohérences), réversible (un script de rollback est écrit en parallèle), et validé sur une copie des données de production avant d'être exécuté en production.
La validation après migration couvre : intégrité référentielle (toutes les relations entre entités sont intactes), comptage des enregistrements (même volume avant et après), et tests fonctionnels sur les données migrées.
Plan de communication et fenêtre de maintenance
Même une migration sans interruption de service nécessite une communication préalable auprès des utilisateurs : date de la migration, risque d'instabilité temporaire, canal de signalement des anomalies. Les utilisateurs non informés deviennent des sources de tickets de support.
Pour les migrations qui nécessitent une fenêtre de maintenance, elle est planifiée en heures creuses, avec un rollback plan documenté et un critère de décision explicite (si X se produit dans les 2 premières heures, on rollback).