Migration d’hébergeur

Une migration ratée, ça se voit tout de suite : site down, mails coupés, SEO qui dévisse

La plupart des migrations d’hébergeur que je reprends après coup ont le même scénario : quelqu’un a exporté les fichiers, importé la base, changé les DNS un vendredi soir, et découvert le lundi que les e-mails ne partent plus, que le certificat SSL est invalide, ou que la moitié des images ne s’affichent pas parce que les chemins absolus pointaient vers l’ancien serveur. Entre-temps, Google a eu le temps d’indexer une page d’erreur.

Une migration d’hébergeur n’est pas un simple transfert de fichiers. C’est une opération qui touche en même temps la base de données, les DNS, les certificats SSL, les comptes e-mail, les cron jobs et parfois le code lui-même quand il contient des chemins ou des configurations codés en dur. Chacun de ces éléments a son propre délai de propagation ou sa propre fenêtre de risque, et ils ne se synchronisent pas tout seuls.

Je fais ce type de mission pour des sites WordPress, PrestaShop et des applications sur mesure, en régie ou au forfait selon la complexité. L’objectif que je me fixe systématiquement : zéro coupure perçue par les visiteurs, zéro e-mail perdu, zéro perte de position SEO. Ce n’est pas une formule marketing, c’est un cahier des charges technique que je détaille plus bas.

Ce que j’audite avant de toucher à quoi que ce soit

Je ne migre jamais un site sans avoir d’abord compris pourquoi il faut migrer. Un hébergement lent, un support injoignable, un contrat qui explose au renouvellement, une infrastructure obsolète : la raison change la façon dont je prépare le transfert et le nouvel environnement que je recommande. C’est le même travail de diagnostic que je fais sur les missions de conseil en hébergement, quand la question posée n’est pas encore « comment migrer » mais « vers quoi ».

Avant la bascule, je vérifie l’état réel de l’existant : version de PHP et de la base de données, extensions serveur utilisées par le CMS ou l’application, taille du site et des médias, volume de trafic e-mail, présence de crons planifiés, certificats SSL en place et leur mode de génération. Je regarde aussi qui gère les DNS aujourd’hui — le registrar, l’ancien hébergeur, un tiers — parce que c’est souvent le point qui bloque le jour J.

Sur cette base, je prépare un environnement cible qui reproduit les mêmes versions logicielles, pour éviter les incompatibilités de plugins ou de dépendances qui apparaissent uniquement après la bascule. C’est cette étape de préparation, plus que le transfert lui-même, qui détermine si la migration se passe sans accroc.

Ma méthode pour migrer sans interruption de service

Je procède toujours dans le même ordre, en gardant l’ancien hébergement actif jusqu’à la validation complète du nouveau. C’est ce qui permet de revenir en arrière à tout moment si quelque chose ne fonctionne pas comme prévu.

Pour un site WordPress ou PrestaShop classique, cette séquence tient en une demi-journée à deux jours de travail effectif, étalée sur une semaine pour laisser la propagation DNS se faire tranquillement. Pour une application avec base de données volumineuse ou architecture spécifique, comme les projets Next.js et API que j’ai pu migrer, je prévois une fenêtre de maintenance courte et annoncée, généralement de nuit, pour synchroniser les dernières écritures en base.

DNS, certificats SSL, e-mails : les points qui cassent tout si on les néglige

La plupart des incidents de migration ne viennent pas du transfert du site en lui-même, mais de trois éléments périphériques qu’on oublie de traiter avec le même soin.

Les DNS d’abord : chaque enregistrement (A, MX, TXT, CNAME) doit être recensé avant la bascule, pas redécouvert après. Un enregistrement SPF ou DKIM mal recopié, et les e-mails partent en spam ou ne partent plus du tout. Le certificat SSL ensuite : s’il est généré automatiquement par l’ancien hébergeur, il ne se transfère pas avec le site, il faut le régénérer sur le nouvel environnement avant que le trafic HTTPS n’y arrive, sous peine d’alerte de sécurité dans le navigateur des visiteurs. Les e-mails enfin : si les boîtes sont hébergées chez le même prestataire que le site, la migration doit inclure leur transfert complet, avec une période de double routage pour ne perdre aucun message pendant la propagation.

Si votre site passe derrière un CDN ou un WAF, la migration doit aussi être coordonnée avec cette couche : c’est un point que je traite en détail sur la page Cloudflare & CDN quand le nouvel hébergement s’accompagne d’une mise en cache ou d’une protection anti-bot.

Les cas où je vous déconseille de migrer maintenant

Je ne facture pas une migration seulement parce qu’elle est demandée. Il y a des situations où je recommande d’attendre, ou de résoudre autre chose d’abord.

Si votre site tourne sur une version de CMS très ancienne, avec des plugins abandonnés, migrer l’hébergement sans mettre à jour le code revient à déplacer le problème sans le résoudre : vous retrouverez les mêmes failles de sécurité et les mêmes lenteurs sur un serveur plus cher. Dans ce cas, je préfère qu’on traite d’abord la mise à jour, quitte à migrer ensuite sur une base saine.

Si le motif de migration est une lenteur perçue mais que le diagnostic montre que le problème vient du code ou de l’absence de cache, changer d’hébergeur ne réglera rien — c’est arrivé sur des missions d’optimisation PrestaShop où le vrai gain venait de la configuration du cache et des requêtes, pas du serveur. Et si votre contrat d’hébergement actuel arrive à échéance dans plus de six mois sans urgence particulière, il n’y a souvent pas de raison de se précipiter : mieux vaut prendre le temps de bien choisir la cible plutôt que migrer dans l’urgence pour re-migrer un an après.

Tarifs d’une migration d’hébergeur

Une migration se facture le plus souvent en régie, parce que sa durée dépend directement de ce qu’on découvre pendant l’audit préalable : nombre de comptes e-mail, taille de la base, présence ou non de crons et d’intégrations tierces. Un site vitrine simple se migre en une demi-journée à une journée de travail facturé. Une application avec base de données volumineuse ou architecture multi-services peut demander plusieurs jours, notamment pour la phase de test et la fenêtre de bascule finale.

Si la migration s’accompagne d’une remise à plat plus large — mise en place d’une supervision, changement de stratégie de sauvegarde, configuration d’un CDN — je peux la chiffrer au forfait dans le cadre d’une mission plus globale d’hébergement. Une fois le site migré, je recommande dans la plupart des cas de mettre en place un suivi régulier : c’est l’objet de la page Supervision & sauvegardes, pour éviter de se retrouver dans la même situation d’urgence dans deux ans.