Migrer une application legacy vers le cloud sans interruption
Déménager une application ancienne vers un hébergement cloud n'a rien d'un saut dans le vide, à condition de ne jamais couper le chemin du retour. Inventaire, sauvegardes restaurées, environnement miroir, bascule progressive : la méthode tient en six étapes.
Sommaire
Une application qui tourne depuis dix ans sur le même serveur finit toujours par devoir déménager. Le matériel arrive en fin de vie, l’hébergeur arrête une offre, le système d’exploitation n’est plus mis à jour, ou vous avez simplement besoin de pouvoir absorber une hausse d’activité sans racheter une machine.
La crainte est toujours la même : la coupure. Un week-end sans facturation, un lundi matin où les commerciaux n’accèdent plus à leurs fiches clients. Cette crainte est légitime, mais la coupure n’a rien d’inévitable. Une migration sans interruption repose sur un principe unique : à chaque étape, on doit pouvoir revenir en arrière.
Avant tout : déménager n’est pas moderniser
La première erreur consiste à profiter de la migration pour tout changer à la fois : nouvelle infrastructure, nouvelle version du langage, nouvelle base de données, nouvelles fonctions. Quand un incident survient, plus personne ne sait lequel de ces changements en est la cause.
La règle que nous appliquons : on déménage d’abord, on modernise ensuite. L’application est installée dans le nouvel environnement aussi proche que possible de l’ancien, on vérifie qu’elle s’y comporte à l’identique, et seulement après on engage les transformations. Le choix entre réécriture et modernisation progressive fait l’objet d’un article à part : il se pose mieux une fois l’application installée sur une infrastructure saine.
Étape 1 — L’inventaire
On ne migre bien que ce que l’on connaît. L’inventaire doit répondre à des questions très concrètes :
- Les composants. Le serveur web, la base de données, les tâches planifiées qui tournent la nuit, les scripts déposés à la main sur le serveur il y a des années.
- Les flux. Qui appelle l’application, et qui l’application appelle-t-elle ? Un logiciel comptable, une banque, un transporteur, un service d’envoi d’e-mails. Chacun de ces partenaires peut avoir autorisé l’adresse de votre serveur actuel, et refusera le nouveau tant qu’on ne l’a pas prévenu.
- Les dépendances cachées. Un certificat installé à la main, un fichier de configuration jamais versionné, une adresse IP écrite en dur dans le code.
- Les accès. Qui détient les identifiants de l’hébergeur actuel, du nom de domaine, de la base de données. Si la réponse est « l’ancien prestataire », c’est le premier chantier.
Ce travail est fastidieux. C’est aussi celui qui évite la plupart des mauvaises surprises du jour J.
Étape 2 — Des sauvegardes réellement restaurées
Avant de toucher à quoi que ce soit, on vérifie que l’on peut reconstruire l’application à partir de ses sauvegardes. Pas qu’elles existent : qu’elles se restaurent, sur une machine vierge, et que l’application redémarre avec des données cohérentes.
Cet exercice est d’ailleurs la meilleure répétition de la migration elle-même : restaurer une sauvegarde dans un nouvel environnement, c’est exactement ce que l’on fera au moment de la bascule. Nous avons consacré un article entier aux sauvegardes qui n’en sont pas : la plupart des défauts se découvrent à cette étape.
Étape 3 — L’environnement miroir
On construit ensuite le nouvel environnement dans le cloud, en parallèle de l’ancien, sans que les utilisateurs le voient. On y installe l’application, on y restaure une copie récente des données, et l’on teste :
- les parcours principaux, écran par écran, par des personnes qui utilisent l’application au quotidien ;
- les tâches planifiées, en vérifiant qu’elles produisent les mêmes résultats que sur l’ancien serveur ;
- les échanges avec chaque partenaire identifié dans l’inventaire ;
- les performances, sur un volume de données réaliste.
Cet environnement miroir doit être décrit par des fichiers de configuration plutôt que construit à la main. Le jour où il faudra le reconstruire, ou en créer un second pour les essais, il suffira de rejouer ces fichiers.
Étape 4 — Le DNS, préparé plusieurs jours avant
Les utilisateurs atteignent votre application par un nom de domaine, que le système DNS traduit en adresse de serveur. Chaque réponse DNS porte une durée de vie, le TTL, pendant laquelle elle peut être gardée en mémoire avant d’être redemandée à la source. La norme qui définit le DNS exprime cette durée en secondes.
Conséquence pratique : si votre TTL est d’une journée, une partie des utilisateurs continuera d’arriver sur l’ancien serveur jusqu’à une journée après la bascule. On abaisse donc le TTL plusieurs jours avant la migration, pour que l’ancienne valeur, plus longue, ait le temps d’expirer partout. Le jour J, le changement d’adresse se propage en quelques minutes. Une fois la migration stabilisée, on remonte le TTL à une valeur normale.
Étape 5 — La bascule progressive
Quand l’architecture le permet, on ne bascule pas tout le monde d’un coup. On envoie d’abord vers le nouvel environnement une petite part du trafic, ou un groupe d’utilisateurs internes, puis on élargit par paliers en surveillant les erreurs et les temps de réponse.
Le point délicat reste la base de données. Tant que l’ancien et le nouveau système écrivent chacun dans la leur, les deux divergent. Deux options :
| Approche | Principe | Quand l’utiliser |
|---|---|---|
| Gel court des écritures | On fige l’application en lecture seule le temps de copier les dernières données, puis on bascule | Application peu sollicitée la nuit ou le week-end |
| Réplication continue | La nouvelle base reçoit en permanence les modifications de l’ancienne, puis on inverse le sens | Activité continue, coupure inacceptable |
Dans les deux cas, on choisit le moment avec les équipes métier, pas avec le planning technique : ni un jour de clôture comptable, ni la veille d’un salon.
Étape 6 — Le plan de retour arrière
C’est l’étape la plus souvent oubliée, et celle qui rend toutes les autres sereines. Le plan de retour arrière est un document écrit, qui répond à quatre questions :
- Qui décide du retour, et qui doit être joignable pendant la bascule ?
- À partir de quel signal : un taux d’erreur, un parcours métier cassé, une lenteur au-delà d’un seuil fixé à l’avance ?
- Comment revient-on : remettre l’ancien enregistrement DNS, réactiver l’ancien serveur, qu’on n’a surtout pas éteint ?
- Que deviennent les données écrites dans le nouvel environnement entre la bascule et le retour ?
L’ancien serveur reste en service, intact, pendant une période définie à l’avance. On ne l’arrête qu’une fois la nouvelle installation éprouvée sur un cycle d’activité complet, fin de mois comprise.
Où héberger : la question à trancher avant
Migrer est l’occasion de choisir son hébergeur en connaissance de cause. Le lieu physique des serveurs ne suffit pas à protéger vos données : ce qui compte, c’est le droit auquel obéit l’entreprise qui les exploite. Nous détaillons ce point, et les questions à poser à un hébergeur, dans notre article sur le Cloud Act et l’hébergement souverain.
Une migration bien menée ne se remarque pas. Les utilisateurs se connectent un lundi matin comme les autres, et rien ne leur signale que l’application a changé de maison pendant le week-end. C’est l’objectif de nos missions d’infrastructure cloud : un déménagement préparé, réversible à chaque étape, et une application qui gagne en solidité sans que personne n’ait eu à s’en inquiéter.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préféréesQuestions fréquentes
Peut-on migrer une application ancienne vers le cloud sans la réécrire ?
Oui, dans la plupart des cas. On commence souvent par la déplacer telle quelle, dans un environnement qui reproduit fidèlement l'ancien, puis on la modernise une fois installée. Mélanger le déménagement et la réécriture dans le même chantier multiplie les causes possibles de chaque incident.
Combien de temps dure la coupure lors d'une migration ?
Avec une bascule préparée, elle peut se réduire à quelques minutes, voire disparaître si l'application le permet. Ce qui reste incompressible, c'est le moment où les données cessent d'être écrites dans l'ancien système et commencent à l'être dans le nouveau : tout l'enjeu est de le rendre court et de le placer au bon moment.
Pourquoi baisser la durée de vie des enregistrements DNS avant la bascule ?
Parce que les serveurs DNS gardent en mémoire l'adresse de votre application pendant la durée indiquée dans l'enregistrement. Si cette durée est longue, une partie des utilisateurs continuera d'arriver sur l'ancien serveur bien après la bascule. On la réduit donc plusieurs jours avant, pour que le changement d'adresse se propage vite.
Qu'est-ce qu'un plan de retour arrière ?
C'est la procédure écrite, testée et datée qui permet de revenir à l'ancien hébergement si la bascule tourne mal. Il précise qui décide du retour, à partir de quel signal, en combien de temps, et comment on récupère les données écrites entre-temps. Sans lui, une migration devient un aller simple.
Faut-il choisir un hébergeur européen pour migrer ?
Ce n'est pas une obligation générale, mais c'est une question à trancher avant la migration et non après. Le lieu des serveurs ne suffit pas : ce qui compte, c'est le droit auquel obéit l'entreprise qui les exploite, en particulier si vous hébergez des données sensibles.
