Migrer un site WordPress à la main : la checklist pour ne rien oublier

Une migration de serveur qui « se passe mal » se résume presque toujours à la même cause : une étape oubliée, découverte trop tard. Les crons qui ne tournent plus, les emails transactionnels qui finissent en spam, le certificat SSL qui n’a jamais été régénéré. Cette checklist couvre l’ensemble du parcours, dans l’ordre où il faut l’exécuter, pour une migration manuelle d’un hébergeur à un autre.

Elle ne détaille pas la mécanique de remplacement des URLs en base — wp search-replace mérite son propre article — mais couvre tout ce qui l’entoure et qui, en pratique, fait échouer bien plus de migrations que la commande elle-même.

Avant la migration

1. Inventorier ce qui dépend du serveur actuel : tâches cron système (pas seulement WP-Cron), certificats SSL, redirections .htaccess ou nginx spécifiques, comptes email hébergés sur le même serveur.
2. Réduire la fenêtre de coupure en abaissant le TTL des enregistrements DNS 24 à 48 heures avant la bascule, pour que le changement se propage plus vite le jour J.
3. Sauvegarder les fichiers avec rsync ou une archive complète du dossier wp-content, en conservant les permissions d’origine.
4. Exporter la base de données proprement, avec verrouillage cohérent des tables : wp db export sauvegarde.sql via WP-CLI est plus fiable qu’un export manuel via phpMyAdmin sur une base volumineuse.

Préparer le nouveau serveur

1. Installer la même version majeure de PHP que sur l’ancien serveur, ou au minimum vérifier la compatibilité de toutes les extensions actives via wp plugin list --status=active.
2. Créer la base de données et l’utilisateur associé, en notant les identifiants dans un gestionnaire de secrets plutôt que dans un fichier texte temporaire.
3. Importer les fichiers et la base, puis lancer le remplacement d’URL si le domaine change.
4. Vérifier wp-config.php : clés de sécurité, préfixe de table, constantes WP_HOME et WP_SITEURL adaptées au nouvel environnement.

Les crons, angle mort classique

WP-Cron simule des tâches planifiées à chaque visite du site, mais de nombreux projets professionnels le désactivent au profit d’un vrai cron système déclenché par wp cron event run --due-now. Ce cron système, configuré au niveau du serveur (crontab), ne migre jamais automatiquement : il faut le recréer explicitement sur la nouvelle machine.

* * * * * cd /var/www/mon-site && wp cron event run --due-now --quiet >/dev/null 2>&1

Un site qui semble fonctionner normalement après migration mais dont les sauvegardes automatiques, les emails de relance panier ou les publications planifiées cessent de partir : neuf fois sur dix, c’est un crontab oublié.

Emails transactionnels et réputation du serveur

La fonction wp_mail() repose par défaut sur la fonction mail() de PHP, dont la fiabilité dépend directement de la réputation de l’adresse IP du serveur qui l’envoie. Un nouveau serveur, encore inconnu des filtres antispam, peut voir ses emails de réinitialisation de mot de passe ou de confirmation de commande finir en spam pendant plusieurs jours.

• Configurer un service SMTP transactionnel (dans la lignée de ce que faisait déjà l’ancien serveur) plutôt que de dépendre de mail()
• Vérifier les enregistrements SPF et DKIM du domaine, à mettre à jour si le nouveau serveur d’envoi change
• Tester un email réel de bout en bout avant d’annoncer la migration terminée

DNS, SSL et bascule finale

Le jour de la bascule, l’ordre des opérations conditionne la longueur de la coupure perçue par les visiteurs :

Étape	Point d’attention
Génération du certificat SSL sur le nouveau serveur	À faire avant la bascule DNS si le serveur accepte une validation par fichier, pour éviter tout écran de sécurité
Modification des enregistrements DNS (A, éventuellement MX)	Vérifier le TTL déjà abaissé en amont
Surveillance de la propagation	Un outil de vérification DNS externe confirme la bascule effective avant de couper l’ancien serveur
Redirection temporaire de l’ancien serveur	Utile le temps que 100 % du trafic ait basculé

Vérifications finales

Je ne considère jamais une migration terminée tant que je n’ai pas passé la fenêtre d’administration, testé un envoi d’email, vérifié un cron et navigué sur cinq pages au hasard avec les outils de développement ouverts, en traquant les ressources encore chargées depuis l’ancien domaine.

Points à confirmer avant de clôturer la migration : absence de ressources mixtes (http au lieu de https), fonctionnement des formulaires, sitemap XML accessible, redirection 301 correctement en place vers le nouveau domaine si celui-ci a changé, et suppression des identifiants temporaires utilisés pendant le transfert.

En résumé

Une migration manuelle réussie tient moins à la maîtrise technique de rsync ou de l’import SQL qu’à la rigueur de la checklist qui l’entoure. Les crons et les emails transactionnels sont les deux points qui échappent le plus souvent à l’attention, précisément parce qu’ils ne provoquent aucune erreur visible immédiatement — seulement un silence, découvert des jours plus tard.