Changer d’hébergeur fait partie de ces tâches que l’on reporte pendant des mois. La crainte est toujours la même : que le site tombe, que des e-mails se perdent, que les clients atterrissent sur une page blanche. La bonne nouvelle, c’est qu’une migration bien planifiée est invisible pour vos visiteurs. La mauvaise, c’est qu’une migration improvisée peut vous coûter deux jours de ventes. La différence ne tient pas à la compétence technique, mais à l’ordre des opérations.
Voici la checklist que nous suivons à chaque migration, dans l’ordre exact d’exécution.
Deux jours avant : préparer le terrain
La première étape ne touche pas au serveur, elle touche au DNS. Chaque enregistrement DNS possède un TTL, un nombre en secondes qui indique combien de temps Internet peut le mémoriser avant de redemander. Si votre TTL est de 24 heures, tout changement peut mettre une journée entière à se propager dans le monde.
Abaissez-le à 300 secondes au moins 48 heures avant la migration. Ainsi, le jour du basculement, la propagation se termine en quelques minutes. Cette étape coûte un clic et transforme une migration de plusieurs jours en une affaire de minutes.
La deuxième étape est un inventaire honnête de ce que vous avez. Fichiers, base de données, comptes de messagerie avec leurs mots de passe, tâches planifiées, certificats SSL, enregistrements DNS personnalisés, et toute intégration externe qui pointe vers votre serveur par adresse IP. Ce dernier point réserve le plus de surprises : passerelles de paiement, systèmes de facturation ou applications mobiles qui dialoguent directement avec une IP qui va changer.
La sauvegarde qui sert vraiment
Faites une sauvegarde complète et, surtout, vérifiez qu’elle se restaure. Une sauvegarde jamais testée est une supposition. Restaurer la base dans un environnement de test et vérifier que le site démarre prend vingt minutes et évite le pire des scénarios.
La veille : monter et tester en parallèle
Voici l’astuce que peu de gens connaissent. Vous pouvez faire tourner votre site sur le nouveau serveur et le tester à fond avant de changer le DNS, grâce au fichier hosts de votre ordinateur. Ajoutez une ligne avec la nouvelle IP et votre domaine, et votre navigateur ira sur le nouveau serveur alors que le reste du monde voit encore l’ancien.
Vous pouvez ainsi parcourir tout le site, passer une commande de test, envoyer un formulaire, vérifier que les images chargent et que les permissions de fichiers sont bonnes. Sans qu’aucun client ne s’en aperçoive. Si quelque chose casse, vous le corrigez calmement.
Profitez-en pour vérifier la version de PHP. Beaucoup de migrations échouent non pas à cause des données, mais parce que le nouveau serveur embarque une version plus récente qui casse un vieux plugin. Autant le découvrir maintenant.
Le jour du basculement : la fenêtre courte
Choisissez l’heure la plus calme, généralement la nuit ou tôt le dimanche. La séquence est :
- Gelez les modifications du site. Pas de publication, pas de commandes manuelles, pas de base de données.
- Synchronisez une dernière fois ce qui a changé depuis la sauvegarde initiale : surtout la base et les fichiers envoyés.
- Pointez le DNS vers le nouveau serveur.
- Vérifiez depuis plusieurs réseaux différents, y compris votre mobile en données, que le site répond au nouvel emplacement.
Avec le TTL bas préparé deux jours avant, cette partie se règle en quelques minutes.
La messagerie mérite une attention à part
Le site est la partie visible, mais c’est la messagerie qui génère les appels mécontents. Pendant la propagation, certains messages peuvent arriver sur l’ancien serveur et d’autres sur le nouveau. Gardez les comptes actifs des deux côtés pendant quelques jours, et relevez l’ancienne boîte avant de la fermer. Ne supprimez jamais de comptes le jour même de la migration.
La semaine suivante : filet de sécurité
N’annulez pas l’ancien serveur tout de suite. Gardez-le une semaine au minimum, hors DNS mais avec les données intactes. Si un problème que personne n’avait vu apparaît, vous avez l’original sous la main.
Pendant ces jours, examinez les journaux d’erreurs du nouveau serveur : ils révèlent souvent des chemins mal configurés ou des permissions incorrectes qu’une navigation normale ne montre pas. Remontez le TTL à une valeur élevée quand tout est stable, pour soulager vos serveurs DNS.
Les trois erreurs les plus fréquentes
Migrer le vendredi après-midi. Si ça se complique, votre week-end y passe. Le meilleur jour est mardi ou mercredi, avec la semaine entière devant soi.
Oublier les tâches planifiées. Les cron qui génèrent des rapports, envoient des rappels ou synchronisent des stocks ne migrent pas tout seuls. C’est la panne découverte trois semaines plus tard, quand quelqu’un réclame un rapport jamais arrivé.
Ne prévenir personne. Même invisible, la migration doit être connue de votre équipe. Si quelqu’un repère une anomalie, il doit pouvoir la relier au changement au lieu de perdre une matinée à enquêter.
Quand vous préférez ne pas le faire vous-même
Une migration standard d’un site avec sa messagerie représente quelques heures pour qui en fait souvent, et un week-end entier pour qui s’y attelle la première fois. Dans nos offres d’hébergement web en Andorre, la migration est incluse : nous gérons tout le processus, phase de tests en parallèle comprise, et nous confirmons que tout fonctionne avant de toucher à votre DNS.
Et si votre inquiétude porte sur ce qui arriverait en cas de problème à n’importe quel moment, pas seulement pendant une migration, jetez un œil à nos services de sauvegarde : deux centres de données en propre en Andorre et un test de restauration réel et documenté chaque année.