Votre site WordPress est lent, instable ou difficile à gérer ?
Migrer vers un hébergeur performant peut transformer l’expérience de vos visiteurs, améliorer votre SEO et booster vos conversions (et donc votre CA).
Mais il ne suffit pas de migrer vers un hébergeur performant sans définir l’objectif souhaité sinon vous risquez de continuer à migrer éternellement.
Une migration ou un transfert de site prend du temps.
L’étape d’optimisation prend du temps.
Si vous pensez migrer mais que vous ne pensez pas déléguer la maintenance, je vous conseille plutôt de rester chez votre hébergeur actuel, d’optimiser votre site en place et d’augmenter la puissance de l’hébergement.
Maintenant, si vous pensez que c’est le bon moment pour réfléchir à prendre une infogérance qui va régler la totalité du problème, alors nous allons étudier ce cas.
Avec une infogérance WordPress, vous déléguez la maintenance, les sauvegardes et la sécurité à des experts, libérant ainsi du temps pour développer votre activité.
Ce guide détaille comment le transfert de votre site va s’effectuer et à quel moment interviennent les optimisations et la sécurisation, pour un résultat sans failes.
La migration en elle-même ne sert à rien
Si on se contente de déplacer votre site sans savoir ce qu’il faut faire, vous allez être déçu.
La migration s’accompagne d’une expertise, du choix du serveur ainsi que son emplacement, une analyse générale des possibles points de blocage des performances, d’une planification et d’un temps de réglages fins après la migration.
Comptez environ 10 jours avant et 10 jours après migration pour l’opération totale.
1. Choisir le serveur
Nous utilisons les instances de serveurs du Public Cloud OVH.
Contrairement aux VPS (qui sont aussi des instances de ce même Public Cloud et dans la même gamme des instances modèles « discovery »), les autres instances ont un SLA (niveau de service garanti) de 99,99% du temps et un temps de ressources CPU garanti 100% du temps nécessaire.
Ces instances sont connectées à notre réseau privé pour les accès administrations systèmes, sauvegardes,…
Je vous suggère donc, si vous le faites seul, de prendre cette gamme.
Attention : si vous choisissez après coup de prendre une infogérance, il faudra réinstaller un autre serveur de zéro et migrer de nouveau le site. Si vous souhaitez rester propriétaire du serveur avec notre infogérance, le service sera facturé par ma micro-entreprise pour des raisons légales car ce cas est exclus de l’objet de la société.
2. Préparer le système
D’abord l’instance est raccordée à un réseau privé pour permettre son administration hors réseau public.
Seul le WordPress est accessible sur Internet. Nous n’installons aucun panel qui représente un risque inutile.
Le système du serveur (Debian) est entièrement maintenu par un serveur de configuration.
Tous les éléments de base sont préparés comme le service web NGINX, le service de base de données MariaDB, les sauvegardes, la sécurisation et la structure de répertoire de l’hébergement, le monitoring.
3. Pré-migration
Le futur hébergement peut être restreint pendant les tests : pas d’accès internet, pas de cron. L’idée est d’éviter une interaction ou un événement avec un service extérieur pouvant gêner le site en production.
Ensuite, nous préparer la méthode migration qui consiste à sauvegarder votre base de données et à transférer les fichiers, et importer la base de données sur le nouveau serveur.
Nous n’utilisons pas d’extension de migration ou autre parce que ça ne sera jamais aussi fiable qu’une méthode système qui existe depuis des années et qui n’est toujours pas obsolète.
Ensuite, nous testons le site en changeant localement notre résolution DNS.
Le site est testé pour vérifier que la page d’accueil fonctionne, qu’on peut se connecter en tant qu’administrateur.
Nous écrivons les lignes de commande de migration pour le faire rapidement lors de la migration réelle et cela permet de savoir combien de temps cela prend (15 minutes par exemple).
Nous changeons le TTL de votre nom de domaine dans votre zone DNS au minimum pour que la bascule du site soit plus rapide le jour J.
4. Planification de la migration
Le jour et l’horaire sont choisis en fonction du trafic et de votre disponibilité (il faudra changer une adresse IP dans le DNS et parfois c’est plus simple de le faire ensemble que de configurer une délégation).
Mais l’idéal peut être un jeudi soir ou vendredi soir après 21h (à voir).
5. Migration
Le site de production est mis en mode maintenance.
La migration est de nouveau exécutée.
L’hébergement de destination peut de nouveau accéder à internet et la cron est remise en route.
Puis juste après, nous changeons les DNS.
Et nous terminons le mode maintenance.
A ce moment, le site est comme l’origine, les optimisations ne sont pas faites. Cette étape sera faite dans les heures et jours qui suivent.
6. Optimisation et sécurisation
De là commence un travail de fond qui consiste à optimiser le fonctionnement à l’aide d’extension (WP Rocket, Redis) ou de sécurisation (SecuPress).
Le service de base de données et le service PHP ont déjà été partiellement optimisés avant migration.
Nous pouvons analyser les requêtes SQL lentes, étudier les extensions qui posent problème et à remplacer.
Un petit marathon démarre donc et va prendre 10 jours.
7. Maintenance régulière
Après la première étape épuisante, nous rentrons dans un fonctionnement régulier avec un monitoring, un suivi de la vitesse et des mises à jour (wordpress et système).
Nous recevons des alertes en cas de problèmes.
Et nous sommes disponibles pour des rendez-vous en ligne par téléphone ou visioconférence.
Un site internet est vivant et demande parfois des ajustements d’optimisation.
Essayez également de ne pas faire de grandes modifications pour garder une meilleure stabilité du service.
Nous proposons de fournir un 2ème serveur pour les tests (qu’il faut louer en plus) ou pour du développement (avec ouverture SSH/FTP pour celui-ci).
Pour en savoir plus, contactez-vous.