Hébergement : questions à se poser avant de migrer

Pourquoi tu veux migrer, exactement ? (le vrai problème n’est pas toujours l’hébergeur)

Avant de parler technique, la première question est très simple : qu’est-ce que tu veux améliorer ? Parce qu’un déménagement ne corrige pas tout. Et si tu ne sais pas ce que tu cherches, tu peux changer d’hébergeur et garder… exactement les mêmes soucis.

Voici les raisons “saines” pour lancer une migration hébergement WordPress :

• Ton site rame malgré un cache correct, et tu as des pics de lenteur aléatoires.
• Le support te balade ou répond à côté, et tu perds un temps fou à chaque incident.
• Tu es bloqué sur une vieille stack : version PHP trop ancienne, limites mémoire trop basses, base lente.
• Tu as des besoins concrets : staging, logs accessibles, Redis, sauvegardes automatiques, gestion multi-sites, emails séparés, etc.
• Tu as des coupures ou des erreurs 500 qui reviennent comme un boomerang.

À l’inverse, il y a des “fausses raisons” fréquentes :

• “Je veux 100/100 PageSpeed.” Un hébergeur peut aider, mais il ne va pas rendre léger un site qui charge trop de scripts ou un builder surchargé.
• “Je veux un site plus rapide sans toucher au contenu.” Si tu as des pages lourdes, elles resteront lourdes.
• “Je change parce que j’ai lu un avis.” Un avis n’a jamais migré ton site à ta place, et surtout pas ton DNS.

Le bon réflexe est donc de faire un mini état des lieux.

Exemple : si ton problème principal vient du cache, tu peux déjà y voir plus clair en comprenant cache serveur vs plugin de cache. Parfois, le souci n’est pas “l’hébergeur”,  c’est un cache mal piloté, ou deux systèmes de cache qui se marchent dessus.

Autre exemple : si tu envisages une migration parce que tu veux une version PHP plus récente, vérifie d’abord ce que ça change vraiment et comment le faire proprement. Ce guide de migration WordPress vers PHP 8.3 te donne une logique simple : tester en staging, valider, puis basculer.

Petit rappel utile : migrer, c’est une décision business. Si ton site tourne bien, que le support est fiable, et que ta stack est à jour, tu n’as pas besoin de “bouger pour bouger”. Par contre, si ton hébergement t’empêche d’avancer, là, oui, tu as un vrai sujet.

Migrer “pour voir”, c’est comme changer de voiture parce que le cendrier est plein. Ça marche, mais ça coûte un peu cher en logique.

La checklist technique avant migration (ce que ton futur hébergeur doit cocher)

Une migration réussie commence par une règle : tu ne choisis pas un hébergeur “par réputation”, tu le choisis sur des critères vérifiables.

1) La stack minimale WordPress

Avant tout, assure-toi que ton hébergeur est au niveau des prérequis recommandés. WordPress recommande, à ce jour,  notamment PHP 8.3+, MySQL 8.0+ ou MariaDB 10.6+ et le HTTPS sur sa page Prérequis. 

Même si ton site “tourne” sur une version plus ancienne, ce n’est pas une bonne nouvelle. C’est juste un répit. Et sur le long terme, ça te rattrape : sécurité, compatibilité, performance.

2) Les ressources et les limites réalistes

Pose ces questions, noir sur blanc :

• Quelle est la mémoire PHP par site ?
• Quelle est la limite d’exécution (max_execution_time) ?
• Quelleest la taille d’upload ?
• Quelle est la politique sur l’I/O (lecture/écriture disque), souvent la vraie cause des lenteurs ?
• Y a-t-il une isolation correcte (compte isolé, pas un gros serveur partagé “fourre-tout”) ?

3) Le cache, l’HTTP et la compression

Le trio gagnant côté serveur :

• cache serveur (ou au minimum une stack propre) ;
• HTTP/2 (voire HTTP/3 selon les environnements) ;
• compression Brotli/Gzip.

Et surtout : quel est le mode de purge ? Si tu dois vider le cache en panique après chaque changement, tu vas vite détester ton nouveau “gain de perf”.

4) Les outils “pro” qui changent la vie

• Staging simple (vrai staging, pas un clone bricolé).
• Accès aux logs (erreurs PHP, accès, blocages).
• Sauvegardes automatiques + restauration en 1 clic.
• Option de rollback rapide si une mise à jour ou une migration dérape.

5) Les emails et DNS, le duo qui casse les migrations

Beaucoup de migrations échouent… pas sur WordPress, mais sur les emails.

• Tes emails sont-ils chez l’hébergeur actuel ?
• Vas-tu les migrer, ou les laisser chez un fournisseur mail dédié ?
• Qui gère le DNS après migration : toi, l’hébergeur, ton registrar ?

Si tu te dis “on verra après”, tu viens de programmer un lundi compliqué.

Et oui, c’est pénible, mais c’est indispensable : un site qui marche avec des emails qui tombent dans le vide, c’est un site qui perd des demandes.

Quand les emails te lâchent, c’est toujours “bizarrement” le jour où tu reçois enfin un contact intéressant.

Le plan de migration sans casse (sauvegarde, staging, DNS, timing, et plan B)

Tu peux avoir le meilleur hébergeur du monde, si la migration est faite “au feeling”, ça reste risqué. Voilà un plan propre, avec des questions à te poser à chaque étape.

1) Tu peux vraiment restaurer ?

Avant toute chose : est-ce que tu as une sauvegarde complète, et est-ce que tu sais la restaurer ?

Ce guide sauvegarde et restauration complète WordPress rappelle les bases (fichiers + base + stockage externe + procédure).

Si tu veux un repère de “bon sens cybersécurité”, l’ANSSI a un document très clair sur les fondamentaux de la sauvegarde. C’est poussé, mais cela permet de comprendre les vrai bases.

Question simple : si ta migration foire, tu peux revenir en arrière en moins d’une heure ? Si la réponse est non, tu es en train de faire un saut en parachute avec un simple sac à dos.

2) Tu as un environnement de test ?

Le staging n’est pas un luxe, c’est un filet de sécurité.

Tu testes avant la migration, et tu vérifies :

• les pages clés ;
• les formulaires ;
• le paiement si e-commerce ;
• la performance basique ;
• les emails sortants ;
• les redirections.

3) Tu as identifié ce qui est “critique” sur ton site ?

Liste les parcours qui ne doivent absolument pas être casser :

• la page contact ;
• la demande de devis ;
• la prise de rendez-vous ;
• le checkout, si e-commerce ;
• l’espace membre ;
• le tracking essentiel.

Parce que tu veux une migration “sans coupure de business”, et pas “sans coupure de serveur”.

4) Le DNS (tu sais ce que tu changes, et quand)

La plupart des migrations se jouent sur le DNS. Pas besoin d’être ingénieur réseau pour le faire, mais tu dois savoir :

• si tu changes les nameservers ;
• si tu changes juste l’A record ;
• et combien de temps la propagation peut prendre.

Le guide o2switch “changer d’hébergeur” explique le principe d’un changement DNS et le fait que la prise en compte peut prendre du temps.

5) Le timing (choisis un créneau intelligent)

Tu dois éviter les périodes où ton site est le plus sollicité. Fais ça sur un créneau calme, avec du temps devant toi. Ne fais pas ça “entre deux rendez-vous”, “un vendredi soir parce que c’est tranquille”.

Un vendredi soir, c’est surtout le début du week-end, et ton site n’a rien demandé.

6) Un plan B clair

Si la migration ne se passe pas bien :

• tu repointes le DNS vers l’ancien hébergeur ;
• tu remets l’ancienne base ;
• tu restaurations les fichiers avec ta sauvegarde.

Au cas où, il te faut une marche arrière simple à mettre en oeuvre, pas un puzzle.

Après la migration (tests, contrôle, vérifie)

Une migration peut “sembler” réussie et pourtant laisser des problèmes invisibles… jusqu’au moment où quelqu’un te le signale.

Pour limiter les prblèmes, voici la checklist post-migration à ne pas zapper.

1) Vérifie les pages qui font le business

• la page d’accueil ;
• la page service ou offre ;
• la page contact ;
• la page tarifs si tu en as une ;
• et ton principal formulaire.

Fais un test simple : envoie un message avec ton formulaire. Vérifie la bonne réception, la réponse automatique si elle existe, et que ça ne part pas en spam.

2) Vérifie les erreurs et les logs

Même si tout marche, regarde les logs côté serveur si possible. Une migration peut révéler :

• des warnings PHP ;
• des appels obsolètes ;
• des erreurs silencieuses.

3) Vérifie le cache et le comportement “visiteur”

L’idée est d’éviter le classique :

• toi tu vois la page ;
• tes visiteurs voient une version en cache cassée.

Revois ton cache après la migration. Pour éviter les erreurs fréquentes, reviens sur cache serveur vs plugin de cache, c’est typiquement le sujet où un mauvais réglage peut donner l’illusion que “le nouvel hébergeur est nul”.

4) Vérifie les performances

Ne compare pas un score isolé. Compare un ressenti et des points concrets :

• le temps d’affichage ressenti ;
• la stabilité visuelle ;
• la réactivité au clic.

Pour garder une méthode simple, tu peux t’appuyer sur mesurer les performances d’un site WordPress. Pour que cela soit cohérent, il est important de comparer l’avant/après sur les mêmes pages.

5) Vérifie le SEO “basique”

• pas de noindex accidentel ;
• pas de redirections cassées ;
• sitemap OK ;
• pages stratégiques accessibles.

Une migration, ce n’est pas “quand le site s’affiche”. C’est “quand le site encaisse la vraie vie sans se plaindre”.

En conclusion

Une migration hébergement WordPress, c’est un levier puissant quand elle répond à un vrai besoin : performance plus stable, support plus sérieux, stack à jour, outils pro (staging, logs, sauvegardes). Mais c’est aussi un moment où un détail peut coûter cher, surtout sur les emails et le DNS.

La bonne approche est simple : clarifie le problème à résoudre, vérifie que le futur hébergeur coche les critères techniques essentiels, prépare un plan de migration avec sauvegarde restaurable et plan de retour, puis valide après coup avec une checklist orientée business. Pas besoin d’être expert, mais tu as besoin d’être méthodique.

Si tu veux sécuriser ta migration, éviter de perdre des demandes, et faire le bon choix d’hébergement sans te faire vendre du rêve, on peut échanger, réserve un appel et parle moi de ton projet.