Migration Azure : bouger un workload critique sans interruption

Tous les patterns documentés (canary, blue-green, dark launch) supposent une chose : que vous puissiez router le trafic dynamiquement entre les deux versions. Sur un workload web stateless, c'est trivial. Sur un ERP avec des sessions longues, des transactions multi-tables et des batches de nuit, c'est une autre histoire.

Pattern blue-green pour un ERP

Le principe : vous montez l'environnement Azure cible (green) en parallèle de l'on-prem actuel (blue). Vous synchronisez les données via réplication SQL ou CDC. Au jour J, vous bascule le trafic en quelques minutes via DNS ou load balancer. Si problème, vous revenez sur blue en autant de minutes.

Le piège : la synchronisation bi-directionnelle pendant la fenêtre de bascule. Si une saisie part sur green et qu'on bascule entretemps, elle peut être écrasée par la dernière sync depuis blue. La parade : geler les écritures sur blue 30-60 minutes avant la bascule (idéalement la nuit), valider, basculer.

Pattern canary par sous-périmètre

Plus prudent encore : basculer un sous-périmètre métier d'abord (une filiale, une zone géographique, un type de transaction). Vous validez le comportement applicatif, performance, intégrations en aval pendant 2-4 semaines avant d'élargir.

Ce pattern multiplie le coût d'exploitation pendant la transition (deux environnements pleinement opérationnels) mais divise par 5-10 le risque opérationnel d'un go-live raté. Sur un workload représentant > 50 % du CA, le calcul est vite fait.

Le sujet sous-traité : les batchs de nuit

Sur les migrations Azure d'ERP, l'élément qui pose toujours problème ne sont pas les transactions interactives — c'est les batchs de nuit (clôture, calcul de stocks, génération de factures). Ils tournent souvent en chaîne, sur 4-8h, avec des dépendances fines à l'infrastructure (CIFS, ordonnanceur, fichiers plats). Migrez-les en dernier, et budgétez 30 % du temps total du projet uniquement pour eux.