Migration de serveur et d'hébergement sans interruption

Nous transférons sites en ligne, boutiques, bases de données, services en arrière-plan et e-mail vers un nouveau serveur ou un nouvel hébergeur. Le nouveau serveur tourne en parallèle jusqu’à ce que chaque site passe ses vérifications, et la bascule elle-même se résume à un changement DNS réversible.

Quand une migration vous tombe dessus

Personne ne change de serveur pour le plaisir. En général, la date est fixée par quelqu’un d’autre, et le serveur contient plus de choses que personne ne s’en souvient.

Votre hébergeur arrête l'offre, et le serveur héberge l'e-mail, cinq sites et une tâche cron que personne n'a documentée
La facture d'hébergement a encore augmenté, et déménager semble plus risqué que payer
Le système d'exploitation ou le panel ne reçoit plus de mises à jour, et la personne qui l'a installé est partie
Vous voulez regrouper plusieurs vieux serveurs en un seul, ou passer à des serveurs ARM moins chers
L'e-mail de vos domaines est sur la même machine, et personne ne sait de quels enregistrements DNS il dépend
Une précédente tentative de migration s'est soldée par des images cassées, des commandes perdues ou des e-mails rejetés

Ce que nous transférons

D'abord l'inventaire

Avant de copier quoi que ce soit, nous listons ce qui tourne réellement : sites, bases de données, tâches cron, processus en arrière-plan, boîtes mail et redirections, comptes FTP, certificats et enregistrements DNS. La liste révèle en général quelques éléments dont le propriétaire ignorait l’existence.

Stack web et bases de données

nginx et Apache, plusieurs versions de PHP côte à côte, MySQL et PostgreSQL, et des panels comme aaPanel et FastPanel. Les sites sont transférés avec leurs réglages, leurs utilisateurs et leurs droits sur les fichiers, pas seulement leurs fichiers.

Node, Docker et services

Applications Node.js sous PM2 ou systemd, conteneurs Docker et processus qui tournent en arrière-plan. Les dépendances sont reconstruites sur la nouvelle machine, ce qui compte quand l’architecture du processeur change.

E-mail

Boîtes mail avec leurs mots de passe et leur historique, alias et redirections, filtrage antispam et DKIM, SPF et DMARC. Quand un hébergeur bloque le port 25 sortant, l’e-mail sortant passe par un relais pour que rien ne soit rejeté.

DNS et Cloudflare

Les zones sont reconstruites à partir des enregistrements du panneau du registraire ou de Cloudflare, pas devinées à partir de requêtes DNS. Le TTL est abaissé à l’avance, et les serveurs de noms ne sont changés chez le registraire qu’une fois la nouvelle zone complète.

Sauvegardes et supervision

Le nouveau serveur reçoit des sauvegardes vers un stockage séparé avec une politique de rétention et une restauration testée, ainsi qu’une supervision de la disponibilité, des certificats et de l’espace disque. Un serveur sans cela n’est qu’à moitié migré.

Une migration préparée pour que la bascule soit la partie ennuyeuse

Chaque site tourne d’abord sur le nouveau serveur à une adresse temporaire. Nous ouvrons ses pages, envoyons ses formulaires, passons une commande test là où il y a un paiement, envoyons et recevons des e-mails et attendons que les tâches cron s’exécutent. Juste avant la bascule, les données sont synchronisées une dernière fois, pour que les commandes et commentaires arrivés depuis la première copie ne soient pas perdus. Ensuite, le DNS bascule zone par zone. L’ancien serveur reste intact jusqu’à ce que le nouveau ait tourné un certain temps : revenir en arrière tient en un seul changement d’enregistrement.

Un inventaire écrit de tout ce qui tourne sur l'ancien serveur
Chaque site vérifié sur le nouveau serveur avant tout changement DNS
Une dernière synchronisation des données juste avant la bascule
L'ancien serveur conservé en secours jusqu'à votre confirmation

Les problèmes que nous avons déjà rencontrés

Nous avons transféré dix projets et vingt-trois sites entre serveurs, y compris un passage complet de machines x86 à ARM64, et noté chaque problème rencontré en chemin. Sur ARM, les dépendances Node doivent être réinstallées plutôt que copiées, et PHP peut planter avec certains réglages JIT. MySQL peut se mettre à traiter les noms de tables en respectant la casse et casser des requêtes qui fonctionnaient depuis des années. Une version plus récente ou plus ancienne de nginx refuse des parties de l’ancienne configuration, et des bases de données arrivent avec la mauvaise collation. Une zone Cloudflare peut rester bloquée en activation, le filtre antispam peut ne pas signer l’e-mail tant qu’il n’est pas redémarré dans le bon ordre, et une règle de pare-feu peut bannir tout un bureau qui partage une seule adresse IP. Les outils de migration des panels peuvent annoncer un succès sur une copie incomplète, et les certificats peuvent cesser de se renouveler sans bruit. Chacun de ces points se vérifie désormais en quelques minutes au lieu de se découvrir en plusieurs heures.

Une liste de contrôle issue de vraies migrations, pas de la documentation
Les changements d'architecture, comme de x86 à ARM64, traités de façon délibérée
Les écarts de version de PHP, MySQL et nginx vérifiés avant la bascule
E-mail, certificats et règles de pare-feu testés, pas supposés

Après la migration : un suivi plutôt qu'un dossier de passation

Une migration est le moment où une équipe connaît enfin le serveur dans son ensemble : ce qui y tourne, pourquoi, et ce qui dépend de quoi. Il serait dommage de perdre cette connaissance le lendemain de la bascule. La plupart de nos clients de migration restent en infogérance mensuelle, où les mêmes personnes appliquent les mises à jour, surveillent les sauvegardes et la supervision, renouvellent les certificats et gèrent le changement suivant. Si vous préférez gérer le serveur vous-même, vous recevez la documentation de la nouvelle installation et l’accès à tout.

Comment se déroule une migration

Inventaire

Nous obtenons un accès en lecture à l’ancien serveur, aux domaines et au DNS. Vous recevez la liste de ce qui y tourne et de ce que la migration implique.

Plan et nouveau serveur

Nous convenons de l’hébergeur cible et de la taille du serveur, puis installons la nouvelle machine avec des versions logicielles identiques ou plus récentes. Vous recevez un plan de bascule par site et par domaine.

Copie et tests

Sites, bases de données, services et e-mail sont copiés et vérifiés à des adresses temporaires. Les problèmes sont corrigés pendant que l’ancien serveur sert encore tout le monde.

Bascule

Après une dernière synchronisation des données, le DNS bascule zone par zone au moment que vous choisissez. Nous suivons le trafic, les logs et l’e-mail en direct.

Observation et décision

Le nouveau serveur tourne sous observation pendant que l’ancien reste disponible en secours. Ensuite, l’ancien serveur est arrêté, et vous choisissez entre une infogérance mensuelle et une passation documentée.

Ce que nous transférons, et vers quoi

Panels et serveurs web

Bases de données et applications

E-mail et DNS

Infrastructure

Formats de collaboration

Projet de migration

Un périmètre fixe convenu après l’inventaire : quels sites, services et domaines sont transférés, et vers où.

Migration et infogérance mensuelle

Nous transférons le serveur, puis continuons à nous en occuper : mises à jour, sauvegardes, supervision et changements suivants.

Aide à l'heure

Un inventaire et un plan de migration pour votre propre équipe, ou de l’aide sur une partie délicate comme l’e-mail ou le DNS.

Témoignages

Nous traitons chaque client et son projet avec attention.

L’équipe Revol continue de renforcer les capacités de développement du client grâce à un travail de grande qualité et à un support fiable. Elle communique efficacement et fait preuve d’une solide compréhension des besoins et de l’activité du client.

Tomas

PDG (Yukon, Canada)

Le travail de Revol a pleinement répondu aux attentes et a satisfait le client. Leur approche nouvelle et leur disponibilité pour le support ont été de vrais atouts. On peut faire appel à eux pour disposer d’une équipe communicative et orientée client, qui aide à atteindre ses objectifs.

Andrey

PDG, Stellium (États-Unis)

Questions fréquentes

Nos sites seront-ils hors ligne pendant la migration ?

Ils ne devraient pas l'être. Le nouveau serveur tourne en parallèle et ne reçoit le trafic qu'une fois chaque site vérifié dessus. Pendant la propagation du DNS, certains visiteurs arrivent encore brièvement sur l'ancien serveur, c'est pourquoi il reste allumé jusqu'à ce que le changement se soit propagé.

Que deviennent les commandes et les formulaires envoyés pendant la bascule ?

Nous synchronisons les données une dernière fois juste avant la bascule, il ne reste donc qu'une courte fenêtre. Pour les boutiques très fréquentées, nous convenons de la façon de la fermer : basculer à une heure creuse, suspendre le paiement quelques minutes ou reprendre à la main les dernières commandes depuis l'ancienne base.

Pouvez-vous aussi transférer notre e-mail ?

Oui. Les boîtes mail sont transférées avec leurs messages et leurs mots de passe quand l'ancien système le permet, ainsi que les alias et les redirections. Nous reconstruisons DKIM, SPF et DMARC pour le nouveau serveur et vérifions que l'e-mail sortant est bien distribué, pas seulement envoyé.

Nous sommes sur des serveurs x86. Pouvons-nous passer à ARM64 ?

En général, oui, et les serveurs ARM sont souvent moins chers pour la même charge. La plupart des charges PHP, WordPress, Node et bases de données tournent sur ARM une fois leurs dépendances reconstruites. L'inventaire montre tôt si un élément n'existe qu'en x86, comme une vieille image Docker ou un binaire propriétaire, et nous gardons alors cette partie sur x86.

Avez-vous besoin d'un accès à notre registraire de domaines ?

Un accès en lecture au DNS suffit pour la planification. Pour la bascule, il faut modifier des enregistrements ou changer les serveurs de noms, ce que vous pouvez faire vous-même selon nos instructions ou nous confier pour la journée.

Et si quelque chose casse après la bascule ?

L'ancien serveur est toujours là : la correction la plus rapide consiste à faire repointer le DNS vers lui pendant que nous cherchons la cause. Nous surveillons les logs, les files d'attente de l'e-mail et la supervision pendant les premiers jours après chaque bascule, quand apparaissent les problèmes que les tests n'ont pas révélés.

Pouvons-nous abandonner notre panel d'administration ?

Oui. Nous pouvons transférer les sites d'un panel à un autre, ou vers un serveur nu sans panel, géré par fichiers de configuration et scripts. Nous recommandons ce qui convient aux personnes qui s'occuperont du serveur ensuite.

Vous occupez-vous du serveur après la migration ?

Si vous le souhaitez. La plupart des clients de migration continuent en infogérance mensuelle, où la même équipe gère mises à jour, sauvegardes, supervision et changements ultérieurs. Sinon, vous recevez la documentation et un accès complet, et le serveur est à vous.