Exporter la base sans la casser en route
Ou : le fichier SQL voyage bien, c’est l’arrivée qui pose problème.
La réponse courte : on exporte la base depuis le phpMyAdmin de l’ancien hébergeur au format SQL, on crée chez le nouveau une base vide et son utilisateur, on importe le fichier, puis on reporte le nom de la base, l’utilisateur, le mot de passe et le serveur dans le fichier de configuration du site, wp-config.php pour WordPress. Deux obstacles reviennent dans presque toutes les migrations. Le premier est la taille : l’import passe par PHP, dont les limites figurent en tête de la FAQ de phpMyAdmin sur les gros fichiers. Le second est la compatibilité entre MySQL et MariaDB, qui se joue souvent sur une seule collation. C’est l’étape où la migration vers un nouvel hébergeur casse le plus souvent sans prévenir.
Rien de tout cela ne demande un accès SSH. Tout se fait dans le panneau de l’hébergeur et dans phpMyAdmin, l’outil que proposent couramment les panneaux d’hébergement, et c’est pour ce cas que cette page est écrite.
Migrer une base de données MySQL vers un autre hébergeur sans erreur d’import
Avant d’exporter, relevez deux informations sur la page d’accueil de phpMyAdmin, chez l’ancien comme chez le nouvel hébergeur : le type de serveur, MySQL ou MariaDB, et sa version. Elles disent à l’avance si l’import passera tel quel.
| Obstacle | Symptôme à l’import | Parade sans accès serveur |
|---|---|---|
| Fichier trop gros | Taille maximale dépassée, ou page blanche | Exporter en .sql.gz, que phpMyAdmin importe directement ; découper le fichier avec BigDump |
| Délai d’exécution | Import arrêté en cours de route | Importer en plusieurs fichiers, table par table ; demander au support un import côté serveur |
| Collation MySQL 8 inconnue | Unknown collation: 'utf8mb4_0900_ai_ci' | Remplacer la collation dans le fichier SQL, ou choisir un serveur MariaDB récent |
| Mauvais jeu de caractères | Accents transformés en « é » | Exporter et importer en UTF-8, sans conversion |
Les limites de taille et de durée viennent de PHP, pas de phpMyAdmin. La FAQ en cite quatre : max_execution_time, upload_max_filesize, memory_limit et post_max_size, cette dernière devant dépasser la précédente. Le délai propre à phpMyAdmin, ExecTimeLimit, vaut 300 secondes par défaut. Sur un mutualisé, ces valeurs se règlent parfois dans le panneau, parfois pas du tout. La documentation d’import et d’export précise que le formulaire d’envoi accepte les fichiers compressés en gzip ou bzip2, ce qui réduit fortement la taille d’un export SQL, un texte très répétitif. Au-delà, la FAQ mentionne BigDump, un script tiers qui découpe l’import, et le dossier d’envoi UploadDir, que seul l’hébergeur peut activer.
La collation, c’est la règle de tri et de comparaison des textes. MySQL 8 utilise par défaut le jeu utf8mb4 et la collation utf8mb4_0900_ai_ci, comme l’indique la documentation de MySQL. MariaDB n’accepte ces noms, comme alias de ses propres collations, que depuis sa version 11.4.5, selon le ticket MDEV-20912 de son suivi de bugs. Un export venu d’un MySQL 8 échoue donc sur un MariaDB plus ancien. La parade courante consiste à remplacer, dans le fichier SQL ouvert avec un éditeur de texte, utf8mb4_0900_ai_ci par utf8mb4_unicode_ci, que les deux serveurs connaissent, avant d’importer.
Dernier piège, l’encodage. La même documentation de MySQL rappelle que l’ancien utf8, devenu utf8mb3, stocke trois octets par caractère au plus et ne peut pas enregistrer les caractères dits supplémentaires, émojis compris, que utf8mb4 accepte. Une base ancienne en latin1 ou en utf8mb3 se migre sans conversion, telle quelle : c’est la conversion improvisée pendant l’import qui fabrique les « é ».
La base de WordPress, avec ses URL dedans
Pour WordPress, la base contient aussi l’adresse du site, et parfois des milliers de liens vers ses propres images. Tant que le domaine reste le même, rien n’est à modifier. S’il change, un remplacement naïf dans le fichier SQL casse les données sérialisées des extensions. Les outils qui s’en chargent proprement, et les extensions qui déplacent base et fichiers d’un coup, sont comparés dans les deux méthodes de migration d’un WordPress.
Vérifier la base avant que les visiteurs ne la voient
Un import qui se termine sans erreur ne prouve pas que le site fonctionne : un mot de passe mal reporté dans la configuration suffit à afficher une erreur de connexion. Avant de basculer le DNS, ouvrez le site chez le nouvel hébergeur, connectez-vous à l’administration, publiez puis supprimez un contenu de test. La méthode pour le voir avant tout le monde est décrite dans le test par le fichier hosts.
Laisser l’hébergeur faire l’import
Quand la base pèse plusieurs centaines de mégaoctets, la solution la plus simple est souvent de demander au nouvel hébergeur d’importer le fichier lui-même, depuis le serveur, sans passer par les limites de PHP. Certains le font dans le cadre d’une migration offerte, avec des conditions qui varient beaucoup d’une maison à l’autre. Elles sont relevées dans ce que recouvre une migration gratuite.