Migrer de datacenter sans interruption : le plan en sept étapes
Changer de datacenter fait peur pour une raison : la coupure. Elle est pourtant évitable. Une migration réussie est un projet d'ingénierie qui se déroule par vagues, avec un retour arrière possible à chaque étape. Voici le plan.
Estimer mon coût →1. L'inventaire, y compris ce qu'on a oublié #
Tout commence par la liste exhaustive : machines, applications, flux entre elles, dépendances externes, certificats, tâches planifiées. Les migrations échouent rarement sur les serveurs connus ; elles échouent sur le vieux service oublié dont dépendait tout le reste. L'inventaire des flux réseau réels, mesurés, vaut mieux que la documentation.
2. La question des adresses IP, à trancher d'abord #
Si vos adresses appartiennent à l'opérateur, changer de site impose de renuméroter : c'est le premier facteur de coupure et de complexité. Avec vos propres adresses et votre numéro de réseau (ASN), elles vous suivent : la bascule devient un simple changement d'annonce, sans renumérotation. Si la migration est l'occasion d'acquérir vos ressources, faites-le avant, les délais s'y prêtent.
3. Préparer la cible, en parallèle #
Le nouveau site se prépare pendant que l'ancien tourne : baies câblées, énergie testée, liens opérateurs recettés, supervision en place. Le lien temporaire entre les deux sites, dimensionné pour la réplication, est la colonne vertébrale de la migration. Rien ne bouge tant que la cible n'est pas recettée.
4. Répliquer, puis faire tourner en double #
Les données se répliquent vers la cible jusqu'à l'écart minimal, puis les applications critiques tournent en double, l'ancien site servant toujours les utilisateurs. Ce run parallèle est votre filet : il prouve la cible en conditions réelles, sans risque pour le service. Abaissez aussi les TTL DNS à l'avance pour des bascules rapides.
5. Basculer par vagues, du moins critique au plus critique #
Jamais tout d'un coup. La première vague emporte ce qui tolère un incident : environnements de test, applications internes secondaires. Chaque vague valide la méthode et rode l'équipe. Le cœur critique part en dernier, avec la procédure la plus rodée et une fenêtre choisie.
6. Le jour J : une procédure écrite et un retour arrière #
Chaque bascule suit une liste de contrôle écrite : qui fait quoi, dans quel ordre, avec quels tests de validation, et surtout le critère et la procédure de retour arrière si un test échoue. Une bascule sans retour arrière préparé est un saut sans parachute. L'ancien environnement reste prêt à reprendre jusqu'à validation complète.
7. Le recouvrement, puis la sortie propre #
Gardez l'ancien site quelques semaines en filet de sécurité, le temps de voir passer les traitements mensuels et les cas rares. Puis sortez proprement : effacement certifié des supports, retrait des équipements et du câblage, résiliation dans les règles. Les conditions de sortie, préavis et frais de retrait se négocient à la signature du contrat, jamais au moment du départ.
Questions fréquentes #
De quelques semaines pour un parc simple à plusieurs mois pour un système d'information complet. La réplication et le run parallèle prennent l'essentiel du calendrier ; les bascules elles-mêmes se comptent en heures.
Pour l'essentiel des services, oui : adresses IP portables, réplication continue et bascule par vagues ramènent l'interruption à quelques instants de re-routage, invisibles pour la plupart des usages. Certains systèmes très anciens imposent une courte fenêtre, à planifier la nuit.
Par l'inventaire et par le chiffrage du projet : le parcours « externaliser ma salle » de DataColoc croise votre situation avec les sites et opérateurs disponibles, et donne une base chiffrée avant d'engager quoi que ce soit.
Rédigé le 1er septembre 2026.
Passer à la pratique : les datacenters à comparer
Estimer mon coût → Comparer les datacenters