La recette de vérification après une migration, en douze points
Un site migré qui s'affiche n'est pas un site migré. Les douze points à vérifier après une bascule, dont ceux qui ne se voient qu'au troisième jour.
La page d'accueil s'affiche, donc la migration est réussie. C'est l'erreur qui coûte le plus cher, parce que les défauts d'une migration ne se déclarent pas tous le même jour : certains attendent la première commande, d'autres le premier e-mail, d'autres le renouvellement du certificat.
Voici l'ordre dans lequel je vérifie. Les quatre premiers points se font dans l'heure, les quatre suivants dans la journée, les quatre derniers dans la semaine.
Dans l'heure
1. Le site répond sur les deux formes du domaine. Avec www et sans. L'une des deux doit rediriger vers l'autre, en 301, jamais afficher les deux versions. Deux versions accessibles, c'est du contenu dupliqué pour les moteurs de recherche.
2. Le HTTPS est valide, et il redirige. Le cadenas ne suffit pas : tapez l'adresse en http:// et vérifiez qu'elle bascule bien en https://. Un certificat généré avant la bascule DNS est souvent émis pour l'ancien serveur et cesse de fonctionner au renouvellement, trois mois plus tard, quand personne ne fait plus le lien.
3. Une page profonde s'ouvre. Pas l'accueil : un article, une fiche produit, une page à trois niveaux. C'est ce qui teste les règles de réécriture d'URL. Un accueil qui marche et des pages internes en 404 est le symptôme d'un .htaccess non repris.
4. Le formulaire de contact envoie vraiment. Envoyez-vous un message et vérifiez sa réception. Un formulaire qui affiche « Merci » sans rien envoyer est le défaut le plus silencieux d'une migration.
Dans la journée
5. Les e-mails partent et arrivent. Dans les deux sens, sur chaque boîte. Vérifiez aussi où ils atterrissent : boîte de réception ou indésirables. Si c'est le second, votre SPF désigne encore l'ancien serveur.
6. Le back-office fonctionne en écriture. Publiez un brouillon, modifiez un produit, téléversez une image. Une base migrée avec les mauvais droits laisse tout consulter et rien enregistrer.
7. Les images téléversées s'affichent. Pas celles du thème, celles du dossier de téléversement. C'est là que se voient les problèmes de droits et de chemins absolus stockés en base.
8. Le tunnel de commande va jusqu'au bout. Sur une boutique, passez une vraie commande de test avec un moyen de paiement réel de faible montant, puis annulez-la. Un paiement configuré sur l'ancien domaine échoue à l'étape de retour, et cette étape ne se teste pas autrement.
Dans la semaine
9. Les tâches planifiées tournent. Sauvegardes, envois programmés, synchronisations. Elles ne se migrent presque jamais toutes seules, et leur absence ne se voit qu'au moment où l'on a besoin de ce qu'elles produisaient.
10. Les sauvegardes automatiques existent sur le nouveau serveur. Vérifiez qu'un fichier a bien été produit. Un site migré sans sauvegarde active est un site à un incident de la perte totale.
11. Les redirections des anciennes URL fonctionnent. Si la structure des adresses a changé, chaque ancienne URL doit rediriger en 301 vers la nouvelle. C'est ce qui préserve le référencement acquis.
12. Les performances sont au moins équivalentes. Mesurez le temps de réponse et comparez à l'ancien serveur. Une migration qui divise la vitesse par deux est une migration ratée, même si tout fonctionne.
Ce que je garde après la bascule
L'ancien serveur reste allumé une semaine, en lecture seule. Ce n'est pas de la prudence excessive : c'est votre porte de retour si un problème apparaît au troisième jour, et le seul moyen de récupérer un fichier oublié sans tout redéployer.
La sauvegarde complète prise avant la bascule se garde trois mois, hors du serveur. Pas sur le nouvel hébergement, où elle disparaîtrait avec lui.
Le point qu'on découvre toujours trop tard
Les identifiants de paiement, les clés d'API et les jetons de services externes sont souvent liés à une adresse IP ou à un domaine déclaré. Ils continuent de fonctionner quelques jours, puis s'arrêtent au premier renouvellement de jeton.
Faites la liste de tous les services tiers connectés à votre site, et vérifiez pour chacun si l'adresse IP du serveur y est déclarée. C'est vingt minutes qui évitent un paiement bloqué un samedi.
Cette recette est celle que j'applique sur chaque transfert. Si vous avez migré seul et que quelque chose vous inquiète, la passer en revue prend une demi-heure et vous dira exactement où vous en êtes.
Toujours bloqué ?
Décrivez-moi la panne, j'analyse et je vous dis exactement ce qui ne va pas, sans engagement.
Demander mon diagnostic gratuit →