Que sauvegarder avant une migration de site : la liste complète
Une sauvegarde de la base ne suffit pas : avant de migrer, il faut aussi garder les fichiers, la configuration du serveur, les redirections existantes, les données de mesure et les accès. Voici la liste, avec un lien vers chaque procédure.
Avant toute migration, on pense à sauvegarder la base de données. C'est nécessaire, mais loin d'être suffisant : une migration réussie a besoin de pouvoir revenir en arrière si la mise en ligne tourne mal, de comparer le nouveau site à l'ancien, et de savoir précisément ce que l'ancien site contenait, y compris ce que personne ne voit plus.
Cette page est la liste de contrôle de ce qu'il faut mettre de côté, à faire pendant la phase de préparation de la migration. Chaque élément renvoie, quand elle existe, à la procédure détaillée.
Pourquoi sauvegarder plus que la base
Une sauvegarde avant migration sert à trois choses :
- revenir en arrière : si la nouvelle version pose un problème grave le jour de la mise en ligne, il faut pouvoir remettre l'ancienne en service, avec ses fichiers, sa base et sa configuration ;
- comparer : les données de trafic et de visibilité d'avant la migration sont la référence qui dira, dans trois mois, si la migration a coûté des visites ;
- ne rien oublier : les anciennes URL, les redirections déjà en place et les métadonnées de chaque page sont la matière première du plan de redirection. Une fois l'ancien site éteint, on ne peut plus les relever.
La liste de ce qu'il faut sauvegarder
1. Les fichiers du site et les médias
Le code, le thème, les extensions ou modules, et surtout les médias : images, vidéos, documents téléchargeables (dans WordPress, le dossier wp-content). Copiez-les avec un client SFTP, ou demandez une archive complète à votre hébergeur. Les médias comptent doublement : ils sont souvent indexés dans Google Images et cités par d'autres sites, et leurs adresses devront être redirigées si elles changent (voir la redirection des images).
2. La base de données
Pages, articles, produits, comptes, commandes, réglages : sur un site dynamique, presque tout est dans la base. Un export SQL (par phpMyAdmin ou mysqldump) ne contient que la base : il se garde avec la copie des fichiers, les deux formant la sauvegarde complète. Les méthodes (manuelle, panneau d'administration, cloud, rsync, services automatisés) sont détaillées dans notre article sur la sauvegarde de la base de données.
3. La configuration du serveur et les redirections existantes
Ce qui ne figure ni dans les fichiers du CMS ni dans la base, et qu'on découvre manquant après coup :
- le fichier
.htaccessou la configuration Nginx, avec les redirections déjà en place. Elles doivent être reprises dans le nouveau plan, et mises à jour pour viser directement les nouvelles adresses : sinon, une ancienne URL redirigée en 2019 se retrouve au bout d'une chaîne de deux ou trois redirections ; - les redirections gérées par une extension (comme Redirection sous WordPress) ou dans l'administration du CMS, qui vivent en base et disparaissent avec lui ;
- le
robots.txtet les sitemaps XML, pour comparer ce qui était proposé à Google avant et après ; - les tâches planifiées (cron), les règles de cache et la zone DNS du domaine (enregistrements A, CNAME, MX pour la messagerie, TXT de validation), à relever avant tout changement d'hébergeur.
4. Les contenus et leurs métadonnées SEO
La base contient les textes, mais il est utile de garder aussi une photographie de ce qui est réellement en ligne : un crawl complet de l'ancien site, avec pour chaque URL son code de réponse, son title, sa meta description, sa balise canonical et ses liens internes. Ce relevé permet de vérifier, après la reprise, qu'aucune métadonnée ne s'est perdue en chemin. C'est le sujet de notre article sur la reprise des contenus éditoriaux.
5. Les données de mesure : Google Analytics et Search Console
L'historique de Google Analytics 4 et de la Google Search Console ne se migre pas : il se conserve et s'exporte. La Search Console ne garde que 16 mois de données, et Google Analytics 4 efface le détail des événements au-delà de la durée de conservation choisie. Les exports à faire, et les réglages à vérifier, sont dans notre article pour sauvegarder les données Google Analytics 4 et Search Console.
6. Les comptes et les accès
Une migration bloque plus souvent sur un accès perdu que sur une difficulté technique. Faites la liste, avec leur titulaire, des accès à l'hébergement, au bureau d'enregistrement du nom de domaine et à la zone DNS, à l'administration du CMS, à la Search Console, à Google Analytics, à Google Tag Manager, et aux services branchés sur le site (paiement, transporteurs, CRM, outil d'envoi de courriels). Vérifiez que chaque compte appartient bien à l'entreprise, et pas à un ancien prestataire ou salarié. Rangez ces accès dans un gestionnaire de mots de passe, jamais dans un document partagé en clair.
Où et combien de temps conserver les sauvegardes
Une sauvegarde rangée sur le serveur qu'on s'apprête à quitter n'en est pas une. Appliquez la règle dite du 3-2-1 : trois copies, sur deux supports différents, dont une hors du serveur et des locaux. Datez chaque sauvegarde et notez-la dans le journal de migration.
Conservez-les au-delà de la mise en ligne, le temps que le nouveau site soit stabilisé et que le trafic soit revenu à son niveau : plusieurs mois, pas quelques jours. Elles serviront aussi à retrouver une page ou une redirection oubliée.
Vérifier qu'une sauvegarde se restaure
Une sauvegarde jamais restaurée est un pari. Avant la migration, restaurez-la au moins une fois sur un environnement de test : le site doit s'afficher, la base doit répondre et les médias doivent être là. C'est aussi le meilleur moyen de chronométrer un éventuel retour en arrière, et donc de décider jusqu'à quand il reste possible le jour J.
Les procédures détaillées
Les anciennes URL et les redirections existantes sauvegardées ? Swan crawle l'ancien site et sa préproduction, et vous propose le plan de redirection.
