La copie est rarement ce qui casse un déplacement WordPress. Ce qui le casse, c’est ce que personne n’a noté : un cron, un webhook, une extension qui a gravé l’ancien nom d’hôte dans une ligne, une boîte qui part encore de l’ancien serveur. Je traite l’inventaire comme la migration. Le transfert de fichiers est l’après-midi facile qui vient après.
Écrivez le système avant d’y toucher
Avant qu’un fichier ne bouge, j’écris une page qu’un inconnu pourrait utiliser. Version de PHP. Taille de la base. Les lignes de cron et les actions planifiées dans WordPress, qui ne sont pas la même liste. Courrier : qui envoie, par quoi, et si le SPF nomme déjà cet hôte. Chaque intégration qui appelle le site ou que le site appelle. Les webhooks de paiement et une synchro CRM sont les surprises habituelles, parce qu’elles vivent dans un réglage d’extension que personne n’a exporté.
J’écris aussi ce que « marcher » veut dire pour cette boutique-là. Le paiement d’un produit physique. Le paiement d’un produit virtuel. La connexion. Une réinitialisation de mot de passe. Le formulaire de contact, y compris le courriel qui doit arriver. La recherche, si le catalogue en dépend. Si je ne peux pas nommer le chemin, je ne suis pas prêt à changer le DNS.
| Ligne | Pourquoi c’est là |
|---|---|
| PHP, taille de la base, cache d’objets | Le nouvel hôte peut être « en ligne » et rester le mauvais runtime. |
| Cron et actions planifiées | Une tâche de nuit manquée a l’air correcte jusqu’à ce que le rapport du matin soit vide. |
| Chemin du courrier | Le site peut se charger pendant que chaque e-mail de commande meurt sur la nouvelle machine. |
| Webhooks et API sortantes | Ils ne sont en général pas documentés, et ils remarquent le nom d’hôte en premier. |
| Les cinq chemins qui rapportent | Un contrôle de l’accueil ne les parcourt pas. |
Baissez le TTL la veille
Réglez le TTL du DNS à 300 secondes la veille du basculement. Si vous sautez cette étape et que le nouvel hébergeur est mauvais, une partie du public garde l’ancien enregistrement pendant des heures. Vous ne pouvez pas presser un cache que vous n’avez pas raccourci. Je préfère attendre un jour exprès que découvrir l’attente pendant une panne.
Une URL de préproduction n’est pas le vrai nom
Je mets le nouveau serveur en ligne et je n’y pointe que ma propre machine, avec une exception dans le fichier hosts, pendant que le DNS public sert encore l’ancien hôte. Ensuite je parcours les chemins sur le vrai nom. Une URL de staging cache les extensions qui ont stocké le domaine de production dans la base. Elles se tiennent jusqu’à ce que le vrai nom soit dans la requête, c’est-à-dire exactement le moment où vous ne voulez plus de surprise.
Si le chemin critique n’a pas été parcouru sur le vrai nom d’hôte, la migration n’a pas été testée.
Gardez l’ancien hôte allumé
Je ne résilie pas l’ancien hébergement la semaine du déplacement. Il reste en ligne, en lecture seule, au moins deux semaines. Cela coûte peu. C’est le seul retour en arrière qui ne dépend pas d’une sauvegarde que je n’ai pas encore eu à utiliser. Si le nouvel hébergeur se comporte mal au troisième jour, l’ancien enregistrement veut encore dire quelque chose.
Le courrier est la vérification qu’on oublie
Le site peut avoir l’air fini pendant que chaque courriel de commande meurt sur la nouvelle machine. J’écris l’adresse From, le relais, et si le port 25 est seulement ouvert. Sur plus d’un hôte il ne l’est pas, et le seul chemin qui marche est un relais authentifié sur le 587. Le SPF a déjà un enregistrement. Je n’en ajoute pas un second. Deux enregistrements SPF ne fusionnent pas. Les deux deviennent invalides, et le courrier qui arrivait commence à disparaître la semaine après un déplacement qui, pour le reste, s’est bien passé.
J’envoie un vrai courriel de commande et une réinitialisation de mot de passe depuis le nouvel hébergeur, vers une boîte que je contrôle, avant d’appeler le déplacement terminé. Une ligne de journal qui dit “sent” n’est pas un message dans la boîte. Le second est le test.
HTTPS sur l’apex et sur www. Le certificat se renouvelle tout seul. Le courrier part encore. Les cinq chemins se terminent encore. Ensuite je regarde le journal d’erreurs pendant une journée, pas la page d’accueil. La page d’accueil, c’est ce pour quoi un moniteur vous félicite déjà. Le journal, c’est là qu’un webhook a commencé à renvoyer 404 à un prestataire de paiement.
Un déplacement fait ainsi est ennuyeux. C’est le but. Les histoires intéressantes sur les migrations sont presque toutes l’histoire d’une ligne qui manquait à l’inventaire.
