Migration de Serveur Sans Coupure
Chaque mois que vous repoussez votre migration, c'est un mois de plus sur du hardware en fin de vie. Le RAID ne prévient pas toujours avant de lâcher. On migre vos serveurs sans que vos clients ne s'en aperçoivent.
Vous savez qu'il faut migrer. Mais vous repoussez depuis 6 mois.
Soyons honnêtes. Personne ne se réveille un matin en disant "super, aujourd'hui on migre le serveur de prod". La migration, c'est le truc qu'on repousse. Encore et encore. Parce que la peur du downtime est plus forte que la peur du disque qui lâche.
On connaît les excuses. On les entend chaque semaine :
- "On n'a pas le temps" : traduction : on a peur de casser quelque chose et de perdre 2 jours à réparer
- "Ça tourne encore" : oui, comme une voiture avec 300 000 km et un voyant moteur allumé depuis mars
- "Le dernier qui a essayé a tout planté" : parce qu'il n'avait ni plan de rollback ni synchronisation incrémentale
- "Les mails vont tomber" : la première chose qu'on teste. SPF, DKIM, DMARC, MX : tout est vérifié avant la bascule
Ces craintes sont légitimes. Mais l'immobilisme a un coût. Et il est bien plus élevé que celui d'une migration planifiée.
$ smartctl -a /dev/sda | grep Reallocated
Reallocated_Sector_Ct: 147 # seuil critique
$ uptime
up 1247 days # 3 ans sans reboot
$ cat /etc/os-release | grep VERSION
VERSION="18.04.6 LTS" # EOL depuis juin 2023
Si l'un de ces résultats vous parle, votre serveur vit en sursis. Un audit de sécurité vous dira exactement où vous en êtes.
Ce que vous coûte chaque mois de retard
Une migration repoussée n'est pas une migration évitée. C'est une dette technique qui accumule des intérêts. Ce que l'inaction vous coûte, chiffres à l'appui :
Risque matériel
Un disque dur en datacenter a une durée de vie moyenne de 4 à 6 ans. Au-delà, le taux de défaillance explose. Le RAID masque les problèmes jusqu'au jour où deux disques lâchent en même temps. Et là, il n'y a plus de migration, il y a une reconstruction. Si vous avez des sauvegardes.
Failles de sécurité
Un OS en fin de vie (Debian 10, CentOS 7, Ubuntu 18.04) ne reçoit plus de correctifs de sécurité. Chaque CVE publiée devient une porte ouverte permanente sur votre serveur. Les attaquants automatisent le scan de ces vulnérabilités connues. C'est une question de quand, pas de si.
Performance dégradée
Vos concurrents sont passés sur des serveurs NVMe avec la dernière stack logicielle. Leur TTFB est à 200ms, le vôtre à 1.8s. Google le voit. Vos visiteurs aussi. Chaque seconde de latence supplémentaire, c'est 7% de conversions en moins. Sur un CA de 500K, faites le calcul.
Surfacturation hébergeur
Votre hébergeur a augmenté ses tarifs. Ou votre ancienne gamme n'existe plus et le renouvellement se fait au prix fort. On voit régulièrement des PME payer 2 à 3 fois le prix du marché pour du hardware équivalent chez un concurrent. Chaque mois de retard, c'est de l'argent jeté.
Le pire scénario ? Votre serveur tombe un vendredi soir. Plus de site, plus de mails, plus d'application métier. Votre hébergeur annonce 48h pour remplacer le hardware. Vos clients appellent. Votre équipe ne peut pas travailler. Et la migration "qu'on fera quand on aura le temps" devient une reconstruction d'urgence au triple du prix.
Notre protocole de migration : 8 étapes, zéro improvisation
Chaque migration suit un processus éprouvé sur plus de 60 opérations. Pas de "on verra bien", pas de surprise à 2h du matin. Chaque risque est identifié et chaque étape est réversible.
Audit pré-migration
Inventaire exhaustif : services actifs, versions logicielles, ports ouverts, tâches cron, dépendances, certificats SSL, règles firewall, volumes de données. On cartographie tout avec Ansible et des scripts d'inventaire maison. Rien n'est laissé au hasard.
$ ansible all -m setup --tree /tmp/facts
342 paquets, 12 crons, 6 vhosts documentés
Environnement parallèle
Le nouveau serveur est provisionné et configuré à l'identique avant toute bascule. OS durci, sécurisation complète, services installés, configurations répliquées via Ansible. Votre serveur source continue de tourner normalement.
$ ansible-playbook setup-target.yml
PLAY RECAP: ok=54 changed=54 failed=0
Synchronisation données
Transfert incrémental via rsync avec delta-transfer. Les bases de données sont répliquées en temps réel (mysqldump + binlog relay pour MySQL, pg_basebackup + WAL shipping pour PostgreSQL). Vos utilisateurs ne voient rien.
$ rsync -avz --checksum --delete /data/ target:/data/
sent 18.2G, delta-sync. 0 erreurs
Stratégie DNS
48h avant la bascule, on abaisse les TTL DNS de 86400s à 300s. Le jour J, la propagation prend quelques minutes au lieu de 24 heures. On surveille la propagation en temps réel sur les principaux resolvers mondiaux.
$ dig +short @8.8.8.8 votre-domaine.fr
Nouvelle IP confirmée en 4 min
Bascule zero-downtime
Le moment critique est préparé, répété et chronométré. Dernière synchronisation rsync (delta uniquement), lock base de données, export final, bascule DNS, unlock. Les deux serveurs restent actifs en parallèle pendant toute la propagation.
$ time ./cutover.sh --execute
Bascule complète en 47 secondes
Monitoring post-migration
Pendant 48 heures après la bascule, votre serveur est sous surveillance intensive. CPU, RAM, I/O, temps de réponse, logs d'erreurs, files d'attente mail, certificats SSL. On détecte les anomalies avant vos utilisateurs.
$ ./post-migration-check.sh --full
HTTP 200 | SMTP OK | MySQL OK | SSL valid
Plan de rollback
L'ancien serveur reste actif et fonctionnel pendant 72 heures minimum. Si quoi que ce soit ne fonctionne pas comme prévu, on rebascule le DNS en moins de 5 minutes. Zéro prise de risque : on ne décommissionne l'ancien serveur que quand tout est validé par vous.
$ ./rollback.sh --status
Source server: STANDBY | Ready for instant rollback
Documentation complète
Vous recevez un runbook complet du nouvel environnement : architecture, services, configurations, accès, procédures de sauvegarde et de restauration. Votre infrastructure est documentée, reproductible et compréhensible. Pas de boîte noire.
$ ls docs/
runbook.md architecture.md access.md backup-procedure.md
Migration DIY vs. migration accompagnée : la différence concrète
| Aspect | Migration DIY | Migration accompagnée |
|---|---|---|
| Planification | "On copie et on verra" | Audit complet, plan détaillé, répétition générale |
| Downtime | 2h à 48h (si tout va bien) | 0 seconde, bascule transparente |
| Données | Export ponctuel, perte des dernières heures | Sync incrémentale continue, 0 perte |
| DNS | TTL à 24h, propagation chaotique | TTL abaissé J-2, propagation en 5 minutes |
| Emails | MX oubliés, mails perdus, SPF cassé | SPF/DKIM/DMARC validés, envoi et réception testés |
| Rollback | Aucun, ancien serveur déjà résilié | Serveur source en standby 72h, rollback en 5 min |
| Post-migration | "Ça a l'air de marcher" | Monitoring intensif 48h, 47 points de contrôle |
| Documentation | Aucune (ou un fichier notes.txt) | Runbook complet de l'environnement |
La migration DIY n'est pas forcément moins chère. Le temps passé par vos équipes internes, le risque de downtime, les problèmes post-migration qui traînent pendant des semaines, tout ça a un coût. Souvent supérieur à celui d'une migration professionnelle.
Migrations réussies : retours terrain
PME e-commerce, 3 boutiques WooCommerce sur un dédié OVH Kimsufi vieillissant (disques SATA, Debian 10 EOL). Migration vers un Hetzner AX52 avec NVMe. 45 Go de fichiers synchronisés via rsync incrémental, 3 bases MySQL migrées avec réplication binlog. Bascule DNS un dimanche à 23h après abaissement du TTL à 300s le vendredi. Lundi matin, les équipes n'ont rien remarqué. Sauf que tout allait deux fois plus vite.
SaaS B2B avec 400 utilisateurs actifs, stack Node.js + PostgreSQL + Redis sous Debian 10. Upgrade in-place impossible à cause de dépendances legacy (Node 14, Pg 11). Nouveau serveur provisionné sous Debian 12 via Ansible, applications migrées une par une avec pg_dump/pg_restore et tests de non-régression automatisés. Réplication WAL pour les dernières transactions. Le client a validé chaque étape en staging avant la bascule production.
Agence web avec 22 sites clients sur un VPS Scaleway Paris. Besoin de passer sur un dédié à Francfort pour la latence et la conformité RGPD client allemand. Migration de tous les vhosts Apache/Nginx, bases MariaDB, certificats Let's Encrypt et configurations Postfix. Chaque lot de sites basculé séparément avec monitoring individuel. Aucun client n'a subi la moindre interruption. Aucun ticket support.
Questions fréquentes : Migration serveur
Mon site sera indisponible pendant la migration ?
Non. C'est tout l'intérêt de notre protocole. La synchronisation des données se fait en continu via rsync incrémental pendant que votre serveur source reste actif et sert vos visiteurs normalement. La bascule DNS, préparée par un abaissement du TTL 48h avant, prend quelques minutes. Les deux serveurs fonctionnent en parallèle pendant la propagation. Et l'ancien serveur reste en standby 72h pour un rollback immédiat si nécessaire. Vos clients ne verront rien.
Et si quelque chose ne fonctionne pas après la bascule ?
C'est prévu. L'ancien serveur reste actif et opérationnel pendant 72 heures minimum après la bascule. En cas de problème non résolvable rapidement, on rebascule le DNS en moins de 5 minutes. Vous retrouvez votre ancien environnement fonctionnel instantanément. Dans la pratique, nos 47 points de contrôle post-migration détectent et corrigent les anomalies bien avant que quiconque ne les remarque.
Combien de temps prend une migration complète ?
Pour un serveur standard (site web + mail + base de données), comptez 3 à 7 jours de l'audit initial à la validation finale. Pour des infrastructures complexes (multi-serveurs, clusters, réplication), 2 à 3 semaines. La durée dépend du volume de données et du nombre de services. On vous fournit un planning détaillé avec des jalons clairs dès l'audit. Aucune surprise sur le calendrier.
Je risque de perdre des emails pendant la migration ?
Non, si c'est fait correctement , et c'est exactement pour ça qu'on suit un protocole strict. Les enregistrements MX sont migrés après validation complète du nouveau serveur mail. SPF, DKIM et DMARC sont configurés et testés avant la bascule. Pendant la propagation DNS, les deux serveurs acceptent les mails. On vérifie l'envoi et la réception sur les principaux fournisseurs (Gmail, Outlook, OVH) avant de considérer la migration terminée.
Combien coûte une migration et qu'est-ce qui est inclus ?
Le prix dépend du périmètre : nombre de sites, volume de données, services hébergés, complexité des configurations. On propose un diagnostic gratuit pour évaluer précisément votre cas et fournir un devis fixe avant de commencer. Ce devis inclut l'audit, la migration, le monitoring post-bascule 48h, le rollback garanti et la documentation. Pas de surcoût en cours de route , le prix est verrouillé.
Après la migration : on sécurise votre nouvel environnement
Un serveur bien migré mérite d'être bien géré. La migration est le point de départ , pas la ligne d'arrivée. On protège votre infrastructure sur la durée.
Sécurisation serveur dédié
Hardening, firewall nftables, fail2ban, WAF, certificats SSL. Votre nouveau serveur blindé dès le premier jour de production.
En savoir plusSupervision & monitoring 24/7
Monitoring continu après migration. CPU, RAM, I/O, services, SSL, sauvegardes , on détecte les anomalies avant vos utilisateurs.
En savoir plusPRA. Plan de reprise d'activité
Sauvegardes externalisées, procédures de restauration testées. Votre nouvel environnement protégé contre les scénarios catastrophe.
En savoir plusPrêt à migrer sans risque ?
Diagnostic gratuit de votre infrastructure. On identifie les risques, on chiffre la migration et on vous fournit un plan détaillé. Si on casse quelque chose, on rollback en 5 minutes. Mais en 60+ migrations, ça n'est jamais arrivé.
Réponse sous 24h · Diagnostic offert · Sans engagement