Changer d’hébergeur en cours de vie d’un site est un exercice différent d’une simple mise en ligne : il faut faire coexister brièvement deux environnements, garantir qu’aucune commande ou aucun message ne se perde dans la transition, et s’assurer que les visiteurs ne remarquent jamais qu’un changement a eu lieu. Une migration mal préparée se traduit par des heures d’indisponibilité, ou pire, par des données perdues entre l’ancien et le nouveau serveur.
La méthode qui fonctionne consiste à traiter la migration comme une opération réversible à tout moment, jusqu’au dernier instant possible, plutôt que comme une bascule irréversible décidée à l’avance sans filet de sécurité.
Préparer le nouveau serveur en parallèle
Le nouveau serveur doit être entièrement configuré et prêt avant que la migration ne commence réellement : version de PHP identique ou supérieure à l’ancien environnement, base de données créée, certificat TLS obtenu à l’avance pour un sous-domaine ou une adresse IP temporaire. Rien ne doit être improvisé le jour de la bascule elle-même.
Synchroniser les fichiers et la base
Le transfert des fichiers se fait généralement via rsync, qui permet de relancer la synchronisation plusieurs fois en ne transférant que les différences, plutôt qu’un transfert complet à chaque fois :
rsync -avz --delete /var/www/exemple.fr/ utilisateur@nouveau-serveur:/var/www/exemple.fr/
La base de données s’exporte avec mysqldump et s’importe sur le nouveau serveur, en incluant une dernière synchronisation juste avant la bascule finale pour capturer les commandes ou commentaires publiés pendant la préparation :
mysqldump --single-transaction -u utilisateur -p exemple_db > export.sql
mysql -u utilisateur -p exemple_db_nouveau < export.sql
Tester le nouveau serveur avant de toucher au DNS
Avant de modifier le moindre enregistrement DNS, le site doit être testé sur le nouveau serveur via son adresse IP directe, en modifiant temporairement le fichier hosts de la machine de test pour simuler la résolution du domaine sans attendre la propagation réelle :
203.0.113.20 exemple.fr www.exemple.fr
Cette étape permet de valider l'affichage complet du site, le fonctionnement des formulaires, et la connexion à l'administration, dans les conditions réelles de production, sans le moindre risque pour les visiteurs actuels qui continuent d'être servis par l'ancien serveur.
Abaisser le TTL avant la bascule
Comme pour toute migration DNS, le TTL de l'enregistrement A du domaine doit être abaissé plusieurs jours avant la bascule effective, généralement à 300 secondes. Ce réglage préalable garantit que le vrai changement de serveur, une fois effectué, se propage en quelques minutes plutôt qu'en plusieurs heures.
Le jour de la bascule
- Mettre le site en mode maintenance sur l'ancien serveur pour figer les écritures en base pendant la synchronisation finale.
- Effectuer une dernière synchronisation des fichiers et de la base vers le nouveau serveur.
- Modifier l'enregistrement A pour pointer vers la nouvelle adresse IP.
- Vérifier la propagation avec
digdepuis plusieurs résolveurs différents. - Retirer le mode maintenance sur le nouveau serveur une fois la propagation confirmée.
Garder un filet de sécurité
Il est tentant de résilier immédiatement l'ancien hébergement une fois la migration terminée. Nous conservons systématiquement l'ancien serveur actif au moins une semaine, sans le mettre à jour ni y écrire quoi que ce soit, uniquement en lecture, au cas où un problème inattendu imposerait un retour arrière rapide en repointant simplement le DNS.
Une migration réussie ne se mesure pas à la rapidité de la bascule, mais à l'absence totale d'incident visible pour les visiteurs. Le temps investi en préparation se rembourse toujours en tranquillité le jour J.
En résumé
Migrer un site WordPress sans coupure repose sur un principe simple : ne jamais rendre une étape irréversible avant d'avoir validé la précédente. Préparation en parallèle, synchronisation répétée, test avant bascule DNS, et filet de sécurité pendant quelques jours composent une méthode qui a fait ses preuves sur des dizaines de migrations sans incident client visible.
