Migrer vers le cloud sans interrompre l’activité

Migrez par étapes, en gardant l’ancien système actif jusqu’à ce que le nouveau ait fait ses preuves. L’ordre qui fonctionne est toujours le même : inventaire, conteneurisation, environnement parallèle, migration des données en dernier, et un plan de retour arrière écrit avant de commencer.

La migration d’infrastructure fait partie de ces projets où la réussite est invisible, personne ne remarque rien, et où l’échec se transforme en réunion de direction. La différence entre les deux tient rarement au choix du fournisseur.

D’abord, l’inventaire honnête

Toute migration qui tourne mal commence par quelqu’un qui croit savoir ce qui tourne sur le serveur. Prenez le temps de recenser :

• Chaque processus actif, y compris ce cron que quelqu’un a configuré en 2016 et que personne ne comprend, mais qui produit le rapport utilisé par la comptabilité tous les 5 du mois.
• Chaque répertoire écrit sur disque. Les fichiers téléversés causent plus de problèmes de migration que tout le reste, parce qu’ils disparaissent du schéma et réapparaissent en production.
• Chaque adresse figée : une IP dans la règle de pare-feu d’un tiers, un certificat, une intégration qui fait confiance à votre IP sortante.
• Les versions réelles du langage, de la base et des bibliothèques. « Sans doute la 12 » ne compte pas. Vérifiez.

Ce relevé prend deux à cinq jours et évite les trois surprises les plus coûteuses de la phase finale.

Conteneurisez avant d’orchestrer

La tentation est d’aller directement à Kubernetes. N’y allez pas. La première étape est de faire tourner l’application dans un conteneur, n’importe où.

Cet exercice met au jour tout le couplage avec le serveur actuel : chemins absolus, dépendances installées à la main, variable d’environnement qui n’existe que sur cette machine, fuseau horaire du système. C’est un travail ingrat et c’est là que se trouve la moitié de la valeur de la migration, car vous obtenez au final un système que n’importe qui peut démarrer n’importe où.

Si ensuite deux conteneurs derrière un répartiteur suffisent à votre volume, tant mieux : vous n’avez pas besoin d’orchestrateur. Kubernetes est excellent et comporte un coût d’exploitation bien réel. Adoptez-le quand le problème le justifie.

Un environnement parallèle, pas un remplacement

Montez le nouvel environnement en entier pendant que l’ancien continue de servir. Pointez une copie de la base dessus. Laissez tourner une à deux semaines avec du trafic dupliqué ou l’usage interne de l’équipe.

C’est là qu’apparaissent les écarts subtils. Un délai d’expiration différent. Une bibliothèque d’images qui produit un résultat légèrement différent. Une requête rapide sur l’ancien disque et lente sur le nouveau stockage. Découvrir cela avec l’ancien système encore actif est gênant. Le découvrir la nuit de la bascule, c’est autre chose.

Les données en dernier, et répétées

La base de données est toujours la dernière pièce et la seule sans annulation confortable. La procédure qui fonctionne :

1. Faites le chargement complet à l’avance et maintenez une réplication continue de l’ancien vers le nouveau.
2. Répétez la bascule entière en environnement de test, chronomètre en main. Vous devez savoir si la fenêtre est de huit minutes ou de deux heures avant de promettre quoi que ce soit à qui que ce soit.
3. Le jour J : passez le système en lecture seule, attendez que la réplication se vide, basculez le DNS et validez avec un scénario de test écrit à l’avance.
4. Gardez l’ancien environnement intact et éteint pendant deux semaines au minimum.

Le plan de retour arrière doit être écrit

Ce n’est pas du pessimisme, c’est une procédure. Avant la bascule, le document répond à : quel est le critère objectif d’abandon, qui prend cette décision, quelles commandes exécuter, combien de temps cela prend, et ce qu’il advient des données écrites dans le nouvel environnement pendant qu’il était actif.

Si personne ne sait répondre à cette dernière question, la fenêtre de bascule doit être assez courte pour que la réponse soit « aucune donnée significative ». C’est pour cela que l’on migre de nuit, pas par tradition.

Ce qui rentabilise réellement l’opération

Le gain vient rarement de la facture serveur. Beaucoup d’entreprises migrent et dépensent davantage. Le vrai retour apparaît ailleurs.

Un environnement reproductible, d’abord : monter une copie identique pour tester cesse d’être un projet et devient une commande. Livrer sans crainte, car avec l’intégration continue publier un correctif devient une routine plutôt qu’un événement. Une restauration testée, puisqu’une sauvegarde que personne n’a restaurée n’est pas une sauvegarde, et que dans le cloud restaurer pour vérifier coûte quelques euros. Et l’élasticité, si votre charge est irrégulière. Si elle est constante, un serveur dédié peut revenir moins cher, et il n’y a aucune honte à le reconnaître.