Migration de serveur : comment migrer un site web sans perte de données

La migration de serveur consiste à transférer, de manière planifiée, les fichiers d’un site web, sa base de données, ses comptes e-mail, ses enregistrements DNS et ses paramètres applicatifs depuis l’hébergement actuel vers une nouvelle infrastructure. Pour migrer un site web sans perte de données, la méthode la plus sûre est la suivante : réaliser d’abord une sauvegarde complète, préparer le nouveau serveur avec des versions logicielles identiques ou plus récentes, transférer les fichiers et la base de données, tester le site via le fichier hosts ou une URL temporaire, modifier les DNS avec un TTL réduit, puis vérifier après la mise en ligne les logs, les formulaires, les paiements, la délivrabilité des e-mails et les signaux SEO.

Une migration de serveur n’est pas un simple copier-coller. Pour un site WordPress, une boutique WooCommerce, une application Laravel, un développement PHP sur mesure, un média à fort trafic ou une entreprise qui dépend de ses e-mails professionnels, une migration mal préparée peut entraîner des commandes perdues, des caractères accentués corrompus, des erreurs 500, des alertes SSL, une interruption des e-mails ou une baisse de visibilité dans les moteurs de recherche. C’est pourquoi tout projet de migration doit s’appuyer sur un plan clair, une checklist technique et un scénario de retour arrière.

Dans ce guide, nous allons voir étape par étape comment changer d’hébergement ou de serveur en respectant les attentes SEO et performance de 2026. Nous aborderons aussi différents cas de figure : migration cPanel, Plesk, VPS, serveur cloud ou transfert manuel. Vous trouverez également des conseils concrets sur le temps de propagation DNS, le périmètre des sauvegardes, la compatibilité des bases de données, l’installation SSL et les contrôles SEO à effectuer après la migration.

Quand faut-il envisager une migration de serveur ?

La migration d’un site vers un nouveau serveur répond généralement à un besoin de performance, de sécurité, de coût ou d’évolutivité. Par exemple, un site vitrine d’entreprise recevant 5 000 visites par mois peut fonctionner sans difficulté sur un hébergement mutualisé, tandis qu’une boutique en ligne qui reçoit 20 000 visites par jour peut rencontrer des limites CPU, des requêtes lentes ou des délais d’expiration sur la page de paiement. Dans ce cas, il devient pertinent de passer à une offre d’hébergement plus puissante, à un VPS ou à une infrastructure cloud.

Les signaux les plus fréquents qui indiquent qu’une migration serveur devient nécessaire sont les suivants :

• Le temps de chargement des pages dépasse 3 secondes et les métriques Core Web Vitals se dégradent.
• Les limites CPU, RAM, inode ou espace disque sont régulièrement atteintes dans le panneau d’hébergement.
• Le site a besoin de versions plus récentes de PHP, MySQL, MariaDB, Node.js, ionCube ou d’autres composants.
• Vous rencontrez souvent des problèmes de renouvellement SSL, de délivrabilité e-mail ou de gestion DNS.
• La qualité du support, le niveau de sauvegarde ou la sécurité du fournisseur actuel ne répondent plus à vos besoins.
• Le trafic augmente brutalement lors de campagnes publicitaires, d’opérations commerciales ou de périodes saisonnières.

Si votre site grandit et se rapproche des limites de son offre actuelle, mieux vaut préparer une migration contrôlée plutôt que de devoir agir dans l’urgence au moment d’une panne ou d’un pic de trafic. Selon vos besoins, vous pouvez comparer les solutions Paquets d'hébergement Web, Solutions de serveurs VPS ou Hébergement Professionnel afin de choisir l’infrastructure la plus adaptée.

Préparer la migration : l’étape la plus critique

La plupart des migrations qui se soldent par une perte de données échouent non pas pendant le transfert lui-même, mais à cause d’une préparation insuffisante. Avant de commencer, il faut dresser l’inventaire du site existant, identifier précisément les données à migrer et repérer les services sensibles à la moindre interruption.

1. Dressez l’inventaire technique du site

La première étape consiste à établir la cartographie technique du site. Il faut noter le CMS ou framework utilisé, la version de PHP, le type de base de données, la taille disque, les comptes e-mail, les tâches cron, les enregistrements DNS, le certificat SSL, les redirections spécifiques et les intégrations tierces. Pour un site WordPress, par exemple, transférer uniquement le dossier wp-content ne suffit pas ; les règles .htaccess, les paramètres wp-config.php, les préfixes de tables, les extensions de cache et les médias doivent aussi être vérifiés.

Pour un site e-commerce, il faut également contrôler la solution de paiement, l’intégration transporteur, la synchronisation des stocks, la connexion ERP, le service SMTP et les URL de webhooks. Lorsqu’aucune commande n’arrive après une migration, le problème ne vient pas toujours du transfert des fichiers : il peut s’agir d’une restriction IP oubliée côté API ou d’une règle de sécurité encore liée à l’ancien serveur.

2. Effectuez une sauvegarde complète et vérifiez-la

Dans une migration de serveur, faire une sauvegarde ne suffit pas : il faut aussi confirmer qu’elle peut être restaurée. Une sauvegarde complète doit couvrir les éléments suivants :

• Les fichiers du site : public_html, dossiers applicatifs, répertoires d’upload, thèmes et extensions.
• Les bases de données : MySQL, MariaDB, PostgreSQL ou toute autre base utilisée par l’application.
• Les données e-mail : boîtes aux lettres, redirections, filtres et répondeurs automatiques.
• Les enregistrements DNS : A, AAAA, CNAME, MX, TXT, SPF, DKIM et DMARC.
• Les configurations : .htaccess, nginx.conf, php.ini, tâches cron et fichiers d’environnement.
• Les certificats SSL et les règles de sécurité personnalisées.

En pratique, prévoyez au moins deux copies de sauvegarde avant la migration : l’une conservée sur l’ancien serveur, l’autre stockée dans un emplacement distinct. Pour les sites volumineux, rsync peut être utilisé pour les fichiers, tandis que mysqldump ou les outils de sauvegarde du panneau d’administration conviennent aux bases de données. Au-delà de 10 Go de base de données, il peut être plus sûr d’utiliser des sauvegardes compressées et fractionnées plutôt qu’un seul dump massif.

3. Réduisez le TTL DNS en amont

Pour accélérer la propagation du changement DNS, il est recommandé de réduire la valeur TTL environ 24 heures avant la migration. Par exemple, si le TTL est réglé sur 14400 secondes, certains utilisateurs peuvent continuer à arriver sur l’ancien serveur pendant plusieurs heures. En abaissant le TTL à 300 secondes avant le basculement, vous rendez la transition DNS beaucoup plus prévisible. Une fois la migration terminée et validée, vous pouvez remonter le TTL à 3600 ou 14400 secondes.

Une gestion propre du nom de domaine et des DNS joue un rôle direct dans la réussite d’une migration. Pour la configuration du domaine et des DNS, vous pouvez consulter les ressources Vérification de domaine et gestion de nom de domaine.

Comparatif des méthodes de migration serveur

La meilleure méthode de migration n’est pas la même pour tous les sites. Un petit site vitrine peut souvent être déplacé facilement depuis un panneau de contrôle, alors qu’une boutique e-commerce à fort trafic nécessite parfois une synchronisation progressive et une fenêtre de maintenance.

Lors du choix de la nouvelle infrastructure, se limiter à l’espace disque peut être trompeur. Le nombre de workers PHP, les cœurs CPU, la RAM, le stockage NVMe, la fréquence des sauvegardes, l’emplacement du centre de données, la prise en charge de LiteSpeed ou Nginx, le WAF et la protection DDoS influencent aussi fortement les performances. Passer à l’offre la moins chère sans analyse préalable peut donc créer un nouveau besoin de migration à court terme.

Comment effectuer une migration de serveur étape par étape ?

Étape 1 : Préparez le nouveau serveur

Sur le nouveau serveur, il faut installer le système d’exploitation, le serveur web, la version de PHP, le service de base de données et les modules nécessaires. Pour WordPress, PHP 8.2 ou 8.3, une version récente de MariaDB, OPcache et une valeur memory_limit adaptée sont recommandés. Pour des frameworks comme Laravel, il faut également configurer Composer, les tâches cron, les queue workers et les permissions du dossier storage. Si des extensions PHP utilisées sur l’ancien serveur manquent sur le nouveau, le site peut afficher une page blanche ou une erreur 500 après la migration.

Côté sécurité, il convient de définir la politique du port SSH, d’utiliser des mots de passe robustes, de configurer un pare-feu, d’activer l’analyse antimalware et de prévoir les mises à jour automatiques. Mettre en place cette base de sécurité sur un serveur encore vide est beaucoup plus simple que de corriger les choses après la mise en production. Si vous avez besoin d’un certificat SSL, intégrez impérativement installation du certificat SSL dans votre plan de migration.

Étape 2 : Transférez les fichiers

Selon la taille du site, le transfert des fichiers peut se faire via FTP, SFTP, SSH, rsync ou l’outil de sauvegarde du panneau d’hébergement. Pour les petits sites, il suffit souvent de créer une archive compressée puis de l’extraire sur le nouveau serveur. Pour les sites plus volumineux, il est préférable d’effectuer une première copie avec rsync, puis une seconde synchronisation juste avant la modification DNS. Cette approche fait gagner un temps précieux, notamment sur les sites où le dossier d’uploads change en permanence.

Après le transfert, vérifiez les permissions. En règle générale, les dossiers fonctionnent avec des permissions 755 et les fichiers avec 644, mais chaque application peut avoir ses propres exigences. Les fichiers sensibles comme wp-config.php, .env ou leurs équivalents ne doivent pas être lisibles par tout le monde. Assurez-vous également que les fichiers cachés, comme .htaccess et .user.ini, ont bien été copiés.

Étape 3 : Migrez la base de données

Le transfert de la base de données est la partie la plus sensible lorsqu’on veut éviter toute perte de données. Commencez par exporter un dump depuis l’ancien serveur, puis créez la base et l’utilisateur sur le nouveau serveur. Le jeu de caractères doit idéalement être configuré en utf8mb4. Pour éviter les caractères accentués cassés, il faut conserver la même structure de collation lors de l’export et de l’import.

Pour les sites qui génèrent des données en temps réel, comme WooCommerce ou les plateformes avec espace membre, l’utilisation d’un mode maintenance pendant la migration est fortement recommandée. Sinon, pendant la propagation DNS, certains utilisateurs peuvent écrire des données sur l’ancien serveur et d’autres sur le nouveau. Cela peut provoquer des incohérences dans les commandes, commentaires, formulaires ou inscriptions. Pour les sites critiques, le dernier dump de base de données doit être réalisé après l’activation du mode maintenance.

Étape 4 : Mettez à jour les fichiers de configuration

Le nom de la base de données, l’utilisateur, le mot de passe, l’hôte et les chemins de fichiers doivent être ajustés pour correspondre au nouveau serveur. Pour WordPress, on vérifie wp-config.php ; pour Laravel, le fichier .env ; pour les développements spécifiques, config.php ou les fichiers équivalents. Si d’anciens chemins absolus, adresses IP, paramètres SMTP ou répertoires de cache restent en place, le site peut sembler fonctionner en façade tout en générant des erreurs en arrière-plan.

Il faut aussi adapter les valeurs PHP comme memory_limit, upload_max_filesize, post_max_size et max_execution_time aux besoins de l’application. Par exemple, si un back-office charge régulièrement des visuels produits de 200 Mo mais que la limite d’upload reste à 32 Mo, la migration sera techniquement réussie, mais l’exploitation quotidienne du site sera bloquée.

Étape 5 : Testez avant de modifier les DNS

La bonne pratique la plus sûre consiste à tester le site sur le nouveau serveur avant toute modification DNS. Pour cela, vous pouvez associer votre nom de domaine à la nouvelle adresse IP dans le fichier hosts de votre ordinateur. Les visiteurs continuent alors à voir l’ancien serveur, pendant que vous testez le nouveau avec le vrai nom de domaine.

La checklist de test doit inclure les points suivants :

• La page d’accueil, les catégories, les produits, le blog et la page de contact s’ouvrent-ils correctement ?
• L’envoi de formulaires, la connexion membre, la réinitialisation du mot de passe et le tunnel de paiement fonctionnent-ils ?
• Les images, fichiers CSS et JavaScript se chargent-ils sans erreur ?
• Le panneau d’administration s’ouvre-t-il sans message d’erreur ?
• Le certificat SSL est-il installé pour le bon nom de domaine ?
• Existe-t-il des erreurs 404, 500, mixed content ou des boucles de redirection ?
• Le fichier robots.txt, le sitemap.xml et les balises canonical sont-ils corrects ?

Étape 6 : Installez le certificat SSL

Pour les sites modernes, le SSL n’est plus seulement une question de sécurité : il est indispensable pour le SEO et la confiance des utilisateurs. Si les DNS sont modifiés avant l’installation du SSL sur le nouveau serveur, les visiteurs peuvent voir une alerte de sécurité. Le certificat doit donc être préparé juste avant le basculement DNS ou au même moment. Les certificats gratuits comme Let’s Encrypt suffisent pour de nombreux sites ; pour des projets d’entreprise qui collectent des paiements ou des données sensibles, des certificats SSL avec un niveau de validation plus élevé peuvent être préférables.

Après l’installation SSL, vérifiez que les URL HTTP redirigent bien vers HTTPS en 301, qu’aucune erreur de contenu mixte n’apparaît et que le sitemap contient des URL HTTPS. Pour les produits SSL et les options d’installation, vous pouvez consulter certificats SSL.

Étape 7 : Modifiez les enregistrements DNS

Une fois les tests validés, l’enregistrement A côté DNS doit pointer vers l’adresse IP du nouveau serveur. Si le service e-mail est également migré sur ce serveur, les enregistrements MX, SPF, DKIM et DMARC doivent être mis à jour. Si les e-mails restent chez un autre fournisseur, il ne faut pas toucher aux enregistrements MX. L’une des erreurs les plus courantes consiste à vouloir migrer uniquement le site web, mais à modifier accidentellement les enregistrements e-mail et à couper le trafic de messagerie.

La propagation DNS prend généralement de quelques minutes à 24 heures. Si le TTL a été réduit en amont, la plupart des utilisateurs atteindront rapidement le nouveau serveur. Pendant cette période, ne coupez pas l’ancien serveur immédiatement. Le garder accessible pendant au moins 48 heures, idéalement 72 heures, est une pratique beaucoup plus sûre.

Étape 8 : Effectuez la dernière synchronisation et contrôlez les logs

Après le changement DNS, il faut vérifier si de nouvelles données ont été écrites sur l’ancien serveur. Les commandes, formulaires de contact, inscriptions utilisateurs et commentaires doivent être comparés. Les fichiers access log et error log du serveur web permettent de comprendre quelles adresses IP envoient encore des requêtes vers quel serveur.

Dans les 24 premières heures suivant la migration, surveillez les erreurs 500, l’augmentation des 404, les requêtes lentes, les pics CPU et les files d’attente e-mail. Sans ces contrôles, le site peut sembler fonctionner correctement alors que des pertes de conversion se produisent en arrière-plan.

Checklist professionnelle pour migrer un site sans perte de données

La checklist ci-dessous couvre les points qui posent le plus souvent problème en conditions réelles. La valider avant et après la migration réduit fortement les risques.

• La migration a été planifiée sur une plage horaire de faible trafic.
• Une sauvegarde complète des fichiers, bases de données, e-mails et DNS a été réalisée.
• La sauvegarde a été testée et confirmée comme exploitable et restaurable.
• Le TTL DNS a été réduit au moins 24 heures à l’avance.
• PHP, la base de données et les modules nécessaires ont été préparés sur le nouveau serveur.
• Les fichiers ont été transférés intégralement et les permissions ont été vérifiées.
• La compatibilité du jeu de caractères et de la collation de la base de données a été confirmée.
• Les fichiers de configuration ont été mis à jour avec les informations du nouveau serveur.
• Le site a été testé via le fichier hosts avant la mise en production.
• Le SSL a été installé et les redirections HTTPS ont été contrôlées.
• Les enregistrements DNS A, AAAA, MX et TXT ont été correctement mis à jour.
• L’ancien serveur est resté actif au moins 48 heures.
• Google Search Console, Analytics et les logs serveur ont été surveillés.

Contrôles post-migration pour éviter une perte SEO

En théorie, une migration de serveur ne devrait pas entraîner de perte SEO si la structure des URL ne change pas. En pratique, des lenteurs, des erreurs 404, un robots.txt incorrect, un SSL absent ou des erreurs de redirection peuvent affecter les positions. Les contrôles SEO après migration sont donc aussi importants que les vérifications techniques.

Contrôle des URL et des redirections

Si vous ne changez pas la structure des URL lors de la migration, le besoin en redirections 301 reste limité. En revanche, si vous modifiez en même temps le nom de domaine, la structure des permaliens ou l’arborescence des dossiers, chaque ancienne URL doit être redirigée en 301 vers sa nouvelle équivalence. Une redirection temporaire 302 n’est pas adaptée pour transférer durablement les signaux SEO. Par exemple, si l’ancienne page /urun/abc devient /magaza/abc, il faut créer une redirection page à page ; rediriger toutes les anciennes URL vers la page d’accueil dégrade l’expérience utilisateur et les performances SEO.

Contrôle du robots.txt et du sitemap

Si un Disallow a été ajouté dans robots.txt pendant les tests pour bloquer les moteurs de recherche, il doit être retiré au moment de la mise en production. C’est l’une des causes les plus classiques de perte d’indexation après une migration. Le fichier sitemap doit contenir les nouvelles URL en HTTPS et être renvoyé via Google Search Console.

Performance et Core Web Vitals

Même si le nouveau serveur est plus puissant, une mauvaise configuration du cache peut dégrader les performances. LiteSpeed Cache, Redis, OPcache, le CDN et l’optimisation des images doivent être paramétrés correctement. Durant la première semaine après la migration, surveillez PageSpeed Insights, Chrome UX Report et les logs serveur afin de détecter toute dégradation des métriques LCP, INP et CLS. Pour améliorer les performances de votre hébergement, vous pouvez vous appuyer sur les contenus Optimisation de la vitesse WordPress.

Points d’attention lors de la migration des e-mails

Dans de nombreuses migrations, les fichiers du site sont transférés correctement, mais la messagerie est oubliée. Si les e-mails sont hébergés sur l’ancien serveur, il faut migrer les boîtes aux lettres, les mots de passe utilisateurs, les redirections et les filtres. La synchronisation IMAP est une méthode fiable pour transférer les messages de l’ancienne boîte vers la nouvelle.

Côté DNS, l’enregistrement MX indique le serveur de messagerie, SPF définit les serveurs autorisés à envoyer des e-mails, DKIM ajoute une signature cryptographique et DMARC précise la politique du domaine. Si ces enregistrements sont mal configurés, les e-mails peuvent arriver en spam ou être complètement rejetés. Après la migration, il est recommandé d’envoyer des tests vers Gmail, Outlook et des comptes professionnels, puis de vérifier les en-têtes des messages.

Les erreurs les plus fréquentes lors d’une migration de serveur

Les migrations réussies ont un point commun : les erreurs simples sont anticipées avant le basculement. Les problèmes les plus courants sont les suivants :

• Lancer la migration sans sauvegarde ou sans tester la sauvegarde.
• Changer l’adresse IP sans avoir réduit le TTL DNS.
• Éteindre l’ancien serveur avant la fin de la propagation DNS.
• Importer la base de données avec un mauvais jeu de caractères et casser les caractères accentués.
• Oublier les règles de redirection .htaccess ou nginx.
• Rediriger le trafic HTTPS vers le nouveau serveur avant d’avoir installé le SSL.
• Modifier incorrectement les enregistrements MX et TXT des e-mails.
• Laisser une extension de cache pointer vers l’ancien chemin serveur.
• Ne pas surveiller Search Console et les logs après la migration.

Pour les sites qui réalisent des ventes en direct, la migration ne doit pas être effectuée en pleine journée de travail lorsque le trafic et les commandes sont élevés. Sur les gros projets e-commerce, prévoir une fenêtre de maintenance de 15 à 30 minutes permet d’éviter les incohérences de données qui pourraient se produire en arrière-plan.

Quand faire appel à un support professionnel pour la migration ?

Il est possible de migrer manuellement un simple site vitrine, mais dans certains cas, l’accompagnement professionnel est moins coûteux et plus sûr. Les boutiques en ligne générant un chiffre d’affaires élevé, les entreprises avec de nombreux comptes e-mail, les portails utilisant un logiciel spécifique, les médias à fort trafic et les organisations hébergeant des données soumises à réglementation entrent dans cette catégorie.

Un accompagnement professionnel suit généralement plusieurs étapes : audit initial, sauvegarde, mise en place d’un environnement de test, transfert, basculement DNS, validation et surveillance. Ainsi, ce ne sont pas seulement les fichiers qui sont déplacés, mais aussi la continuité de l’activité. Si vous envisagez de passer sur l’infrastructure Hostragons, vous pouvez consulter Solutions d'hébergement Hostragons afin d’évaluer ensemble les solutions d’hébergement, de domaine et de SSL adaptées à vos besoins.

Conclusion : une migration serveur planifiée évite les coupures et les pertes de données

Une migration de serveur n’a rien d’inquiétant lorsqu’elle est correctement préparée. La clé du succès est de ne pas négliger les étapes essentielles : sauvegarde complète, préparation du nouveau serveur, planification du TTL DNS, environnement de test, installation SSL, contrôle des e-mails et suivi post-migration. Pour les sites dont la base de données évolue en continu, la dernière synchronisation et le mode maintenance jouent un rôle déterminant.

En résumé, pour migrer un site web sans perte de données, ne vous précipitez pas, validez chaque étape et ne coupez pas l’ancien serveur trop tôt. Si vous souhaitez moderniser votre infrastructure pour offrir une expérience plus rapide et plus sécurisée, vous pouvez étudier les solutions d’hébergement, de domaine et de SSL proposées par Hostragons, puis construire un plan de migration serein et maîtrisé.

Foire aux questions

Combien de temps dure une migration de serveur ?

La durée dépend de la taille et de la complexité du site. Un petit site WordPress peut être migré en 30 à 60 minutes, tandis qu’un grand e-commerce ou un projet d’entreprise avec de nombreux comptes e-mail peut nécessiter 1 à 3 jours en incluant la préparation, les tests et la propagation DNS.

Mon site sera-t-il hors ligne pendant la migration ?

Avec une bonne planification, l’interruption peut être réduite à quelques minutes, voire passer inaperçue pour les utilisateurs. Pour cela, il faut réduire le TTL DNS à l’avance, tester le nouveau serveur avant la mise en ligne et garder l’ancien serveur actif jusqu’à la fin de la propagation DNS.

Quelle est l’étape la plus importante pour éviter la perte de données ?

L’étape la plus importante est la sauvegarde complète et vérifiée. Les fichiers, la base de données, les e-mails et les enregistrements DNS doivent être sauvegardés ; pour les sites qui génèrent des commandes ou des inscriptions, le dernier export de base de données doit être réalisé après l’activation du mode maintenance.

Une migration serveur peut-elle affecter le référencement SEO ?

Si la structure des URL est conservée, que le site reste rapide, que le SSL et les redirections sont correctement configurés, une migration de serveur ne provoque pas de perte SEO à elle seule. En revanche, des erreurs 404, un robots.txt mal réglé, un serveur lent ou des redirections 301 incorrectes peuvent nuire aux positions.

Les comptes e-mail sont-ils aussi transférés lors d’une migration serveur ?

Si les e-mails sont hébergés sur l’ancien hébergement, ils doivent être migrés séparément. Il faut contrôler les boîtes aux lettres, les redirections, les filtres ainsi que les enregistrements MX, SPF, DKIM et DMARC. Si la messagerie reste chez un autre fournisseur, les enregistrements MX ne doivent pas être modifiés.