Comment migrer un site Drupal vers WordPress : un guide technique complet

Migrer de Drupal vers WordPress implique le transfert du contenu de votre base de données, des fichiers médias, de la structure des URL et des comptes utilisateurs de l’architecture CMS basée sur les entités de Drupal vers le modèle de types de publication de WordPress — sans perdre l’équité SEO, casser les liens internes ou provoquer des temps d’arrêt. Le processus implique une importation de contenu au niveau de la base de données via le plugin FG Drupal to WordPress, suivie d’un mappage des permaliens, d’une configuration des redirections 301 et d’une reconstruction du thème.

Ce guide couvre chaque phase de cette migration avec des détails techniques précis : stratégie de sauvegarde pré-migration, configuration de l’environnement, extraction des identifiants de base de données, importation pilotée par plugin, réconciliation de la structure des URL et validation post-lancement. Que vous utilisiez Drupal 7, 9 ou 10, le flux de travail ci-dessous s’applique.

Pourquoi migrer de Drupal vers WordPress

Drupal est un framework puissant, mais sa complexité entraîne un coût opérationnel réel. Les mises à jour de modules introduisent fréquemment des changements incompatibles, la création de thèmes nécessite une expertise des templates Twig, et les modifications de contenu courantes requièrent l’intervention d’un développeur. WordPress, en revanche, offre une courbe d’apprentissage plus douce, un écosystème de plugins bien plus vaste et un coût total de possession plus faible pour les sites à fort contenu qui ne nécessitent pas le contrôle d’accès granulaire ou la modélisation de contenu complexe de Drupal.

L’argument de performance est également important. Une installation WordPress sur un environnement VPS Hosting correctement configuré avec LiteSpeed, la mise en cache des objets et un stockage NVMe surpassera systématiquement une pile Drupal surchargée sur une infrastructure partagée.

Principales motivations de migration par cas d’utilisation :

• Les équipes éditoriales frustrées par l’UX d’administration de Drupal et les flux de publication lents
• Les agences qui consolident les sites clients sur un seul CMS gérable
• Les développeurs qui réduisent la charge de maintenance liée aux chaînes de dépendances des modules Drupal
• Les équipes SEO qui recherchent une intégration plus étroite avec les outils natifs WordPress comme Yoast ou Rank Math

Drupal vs. WordPress : comparaison d’architecture

Comprendre les différences structurelles entre les deux plateformes est essentiel avant de commencer. Les hypothèses incorrectes sur la façon dont le contenu est stocké sont la principale cause d’échecs ou de migrations incomplètes.

L’écart architectural le plus critique est le modèle d’entités de contenu. Drupal stocke les paragraphes, les champs personnalisés et les références de taxonomie dans plusieurs tables jointes. Le plugin FG Drupal to WordPress mappe ces éléments vers les métadonnées de publication et les termes de taxonomie WordPress, mais les mises en page complexes basées sur des paragraphes nécessiteront une reconstruction manuelle.

Liste de contrôle pré-migration

Avant de toucher à l’un ou l’autre environnement, complétez chaque élément de cette liste. Sauter des étapes ici est la principale cause de perte de données et de temps d’arrêt prolongés.

• Auditez votre inventaire de contenu Drupal : types de nœuds, vocabulaires de taxonomie, nombre d’utilisateurs, nombre de fichiers et taille totale de la base de données
• Identifiez les modules Drupal sans équivalent WordPress (par exemple, Rules, logique complexe Webform, Commerce)
• Confirmez que votre serveur WordPress répond aux exigences minimales : PHP 8.1+, MySQL 8.0+ ou MariaDB 10.6+, limite de mémoire PHP de 256 MB
• Décidez d’une fenêtre de migration — idéalement une période de faible trafic
• Activez le mode maintenance sur Drupal pendant la passe d’importation finale pour éviter la dérive du contenu
• Vérifiez que le serveur WordPress peut atteindre l’hôte de la base de données Drupal (même serveur, hôte distant ou tunnel SSH)

Étape 1 : Sauvegarder votre site Drupal

Une sauvegarde complète et vérifiée est non négociable. Vous avez besoin à la fois du dump de la base de données et du répertoire des fichiers.

Sauvegarde de la base de données via Drush

Si vous avez Drush installé (standard pour Drupal 9/10), c’est la méthode la plus rapide :

drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzip

Sauvegarde de la base de données via mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Sauvegarde du répertoire des fichiers

tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/

Sauvegarde phpMyAdmin (méthode GUI)

1. Connectez-vous à phpMyAdmin via votre panneau de contrôle d’hébergement
2. Sélectionnez la base de données Drupal dans la barre latérale gauche
3. Cliquez sur Exporter, choisissez la méthode d’exportation Rapide, format SQL
4. Cliquez sur Exécuter pour télécharger le fichier .sql

Stockez toutes les archives de sauvegarde hors du serveur — téléchargez-les vers un stockage distant ou téléchargez-les localement via SFTP. Une sauvegarde qui ne réside que sur le même serveur que le site en cours de migration n’est pas une vraie sauvegarde.

Étape 2 : Configurer WordPress sur votre serveur cible

Installez une instance WordPress propre sur votre environnement cible. N’importez pas le contenu Drupal dans un site WordPress existant à moins d’avoir explicitement planifié la fusion de contenu — l’importateur ne dédupliquera pas.

Exigences du serveur

Pour les grands sites Drupal (10 000+ nœuds, bibliothèques médias de plusieurs Go), un VPS avec cPanel vous donne un accès direct à la configuration PHP, aux paramètres de réglage MySQL et à la gestion des tâches cron — tout ce dont vous aurez besoin lors d’une migration intensive.

Installation de WordPress via WP-CLI

cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.com

Installation en un clic via cPanel

Si votre hébergeur fournit cPanel, accédez à Softaculous Apps Installer, sélectionnez WordPress, renseignez les identifiants de base de données et d’administration, puis cliquez sur Installer. Le processus prend moins de deux minutes.

Après l’installation, configurez immédiatement ces paramètres PHP dans php.ini ou via .htaccess :

php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128M

Étape 3 : Installer et configurer le plugin FG Drupal to WordPress

Le plugin FG Drupal to WordPress (version gratuite disponible ; Premium recommandé pour les grands sites) gère la migration au niveau de la base de données des nœuds, des termes de taxonomie, des utilisateurs et des fichiers médias.

Installation

1. Dans votre administration WordPress, allez dans Extensions > Ajouter
2. Recherchez FG Drupal to WordPress
3. Cliquez sur Installer maintenant, puis sur Activer

Vous pouvez également installer via WP-CLI :

wp plugin install fg-drupal-to-wp --activate

Comparaison des fonctionnalités Gratuit vs. Premium

Pour tout site de production fonctionnant sous Drupal 8 ou version ultérieure, la version Premium vaut le coût. Tenter de reconstruire manuellement le contenu basé sur des paragraphes est bien plus coûteux en temps de développement.

Étape 4 : Récupérer les identifiants de la base de données Drupal

Le plugin FG Drupal to WordPress se connecte directement à votre base de données Drupal. Vous avez besoin de quatre valeurs : nom de la base de données, nom d’utilisateur, mot de passe et hôte.

Trouver les identifiants dans le fichier settings.php de Drupal

grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.php

La sortie contiendra un bloc comme celui-ci :

$databases['default']['default'] = [
  'database' => 'drupal_db_name',
  'username' => 'drupal_db_user',
  'password' => 'drupal_db_password',
  'host' => 'localhost',
  'port' => '3306',
  'driver' => 'mysql',
];

Considérations relatives à l’accès distant à la base de données

Si WordPress et Drupal sont sur des serveurs différents, la base de données Drupal doit accepter les connexions distantes. Sur le serveur de base de données Drupal :

GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Assurez-vous également que le port 3306 est ouvert dans le pare-feu uniquement pour l’IP du serveur WordPress — n’exposez jamais MySQL à 0.0.0.0.

Si vous ne pouvez pas ouvrir un port MySQL direct, utilisez un tunnel SSH :

ssh -L 3307:localhost:3306 user@drupal_server_ip -N -f

Définissez ensuite l’hôte de base de données du plugin sur 127.0.0.1 et le port sur 3307.

Étape 5 : Lancer l’importation du contenu

Accédez à Outils > Importer dans votre tableau de bord WordPress, faites défiler jusqu’à la section Drupal et cliquez sur Lancer l’importateur.

Configuration des paramètres de l’importateur

Onglet connexion à la base de données :

• Hôte de la base de données : localhost (ou IP distante / adresse du tunnel SSH)
• Port : 3306 (ou votre port personnalisé)
• Nom de la base de données : valeur issue de settings.php
• Nom d’utilisateur / Mot de passe : valeurs issues de settings.php
• URL des fichiers Drupal : l’URL publique de votre répertoire sites/default/files/ Drupal — requise pour le téléchargement des médias

Cliquez sur Tester la connexion avant de continuer. Un échec de connexion à cette étape est presque toujours causé par l’un de ces trois problèmes : identifiants incorrects, un pare-feu bloquant le port MySQL, ou l’utilisateur de la base de données Drupal ne disposant pas des privilèges SELECT sur la base de données cible.

Onglet comportement — paramètres recommandés pour la plupart des migrations :

• Importer les articles : Oui
• Importer les pages : Oui
• Importer les catégories et les étiquettes : Oui
• Télécharger les images et les pièces jointes : Oui (requis pour copier les médias dans le répertoire de téléchargement WordPress)
• Supprimer les données WordPress avant l’importation : Oui (sur une installation vierge uniquement — cela tronque wp_posts et les tables associées)

Démarrage de l’importation

Cliquez sur Démarrer / Reprendre l’importateur. Le plugin traite le contenu par lots. Pour les grands sites, l’importation peut expirer et nécessiter plusieurs cycles de reprise — c’est un comportement attendu, pas une erreur. Cliquez simplement sur Reprendre à chaque fois.

Surveillez le journal d’importation affiché à l’écran. Soyez attentif à :

Error downloading file — indique que l’URL des fichiers Drupal est incorrecte ou que le répertoire des fichiers n’est pas accessible publiquement
Les erreurs Duplicate entry — généralement sans conséquence, indiquant que le plugin ignore les enregistrements déjà importés lors d’une reprise
MySQL server has gone away — indique que wait_timeout est trop faible sur le serveur MySQL ; augmentez-le à au moins 600 secondes

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Étape 6 : Réconcilier la structure des URL et configurer les redirections
C’est l’étape que la plupart des guides sous-estiment. Les incompatibilités de structure d’URL entre Drupal et WordPress sont la principale cause de chutes de classement SEO après migration.
Modèles d’URL Drupal (courants)




Modèle d’URL Drupal
Description




/node/123
Chemin de nœud par défaut (sans alias)


/about-us
Alias de chemin (le plus courant)


/taxonomy/term/5
Page de terme de taxonomie


/user/1
Profil utilisateur


/content/article-title
Alias préfixé par type de contenu




Configuration des permaliens WordPress
Allez dans Réglages > Permaliens et sélectionnez une structure qui correspond le plus possible à vos alias de chemin Drupal. Pour la plupart des sites Drupal utilisant des alias propres, /%postname%/ est le bon choix.
/%postname%/
Si votre site Drupal utilisait des URL préfixées par catégorie comme /blog/article-title, utilisez :
/%category%/%postname%/
Mise en place des redirections 301
Installez le plugin Redirection (par John Godley) pour gérer les règles de redirection. Pour les redirections en masse, exportez vos alias de chemin Drupal depuis la base de données :
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Importez ensuite le CSV résultant dans le plugin Redirection, en mappant chaque alias Drupal vers son équivalent WordPress. Pour les URL de style /node/123 qui n’ont jamais été aliasées, créez des redirections basées sur des expressions régulières :
/node/([0-9]+)$ → /?p=$1
Cela mappe les ID de nœuds Drupal aux ID de publications WordPress — mais ne fonctionne que si le plugin FG a préservé les ID de nœuds originaux comme ID de publications, ce qu’il fait par défaut.
Critique : Testez chaque redirection avec curl -I avant la mise en ligne :
curl -I https://yourdomain.com/old-drupal-path
Vérifiez que la réponse est HTTP/2 301 avec l’en-tête Location correct, et non un 302 ou un 200 avec une redirection logicielle.
Étape 7 : Migrer les thèmes et reconstruire le design
Les thèmes Drupal (basés sur Twig) n’ont pas d’équivalent direct dans WordPress. Vous devez reconstruire le design visuel en utilisant un thème WordPress comme base.
Stratégie de sélection de thème

Thèmes basés sur les blocs (FSE) : Utilisez l’éditeur de site WordPress pour un contrôle total de la mise en page sans constructeurs de pages. Idéal pour les développeurs à l’aise avec le balisage de blocs.
Thèmes classiques avec constructeur de pages : Des thèmes comme Astra ou GeneratePress associés à Elementor ou Bricks Builder offrent l’équivalent le plus proche du Layout Builder de Drupal.
Thème enfant personnalisé : Si votre site Drupal avait un design fortement personnalisé, créez un thème enfant basé sur un parent minimal (Underscores, Blocksy) et répliquez le CSS.

Reconstruction des menus de navigation
Les menus Drupal ne migrent pas automatiquement. Reconstruisez-les sous Apparence > Menus (thèmes classiques) ou le bloc Navigation de l’éditeur de site (thèmes FSE). Référencez-vous à votre structure de menu Drupal :
drush eval "print_r(menu_tree_all_data('main', NULL));"
Ou interrogez directement la base de données :
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Widgets et blocs
Les blocs Drupal correspondent approximativement aux widgets WordPress et aux blocs Gutenberg. Reconstruisez les régions de la barre latérale et du pied de page sous Apparence > Widgets ou directement dans l’éditeur de site. Les types de blocs Drupal personnalisés avec une logique PHP devront être reconstruits en tant que shortcodes WordPress ou blocs personnalisés.
Étape 8 : Audit du contenu post-migration
Ne sautez pas cette phase. Les outils de migration automatisés gèrent bien le contenu structuré mais échouent silencieusement sur les cas particuliers.
Vérifications de l’intégrité du contenu

Médias intégrés : Les références de fichiers en ligne de Drupal utilisent un format de jeton personnalisé ([file:123] ou <drupal-media uuid="..."/>). Ceux-ci ne s’afficheront pas dans WordPress. Recherchez ces jetons dans la base de données :

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';

Shortcodes et Views : Les Views Drupal n’ont pas d’équivalent WordPress. Toute page qui affichait une View (par exemple, une liste de contenu filtrée) sera vide. Reconstruisez-les en utilisant WP_Query, des archives de types de publications personnalisés ou un plugin comme Posts Table Pro.


Champs personnalisés : Les données de champs Drupal migrées via le plugin Premium se retrouvent dans wp_postmeta. Vérifiez que les valeurs des champs sont présentes :

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;

Comptes utilisateurs : Si vous avez migré des utilisateurs, vérifiez le mappage des rôles. Le rôle authenticated user de Drupal correspond au rôle Subscriber de WordPress. Le rôle editor de Drupal correspond au rôle Editor de WordPress. Le rôle administrator de Drupal correspond au rôle Administrator de WordPress. Auditez le mappage et ajustez si nécessaire.

Détection des liens brisés
Installez Broken Link Checker ou effectuez une exploration avec Screaming Frog sur votre environnement de staging avant le basculement DNS. Corrigez tous les 404 internes avant la mise en ligne — ne comptez pas sur la surveillance post-lancement pour les détecter.
Étape 9 : Renforcement des performances et de la sécurité
Un site WordPress fraîchement migré nécessite un renforcement avant d’être prêt pour la production.
Configuration du cache
Installez LiteSpeed Cache (si sur un serveur LiteSpeed) ou W3 Total Cache / WP Rocket pour les environnements Apache/Nginx. Configurez :

Le cache de page avec un TTL d’au moins 3600 secondes pour les pages statiques
Le cache d’objets soutenu par Redis ou Memcached
Les en-têtes de cache navigateur via .htaccess ou la configuration du serveur

SSL/HTTPS
Assurez-vous que votre site WordPress est servi exclusivement via HTTPS. Si vous n’avez pas encore de certificat, des Certificats SSL peuvent être provisionnés rapidement et configurés pour se renouveler automatiquement. Mettez à jour les paramètres d’URL du site WordPress :
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Forcez HTTPS dans .htaccess :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Liste de contrôle de renforcement de la sécurité

Désactivez XML-RPC si non nécessaire : ajoutez add_filter('xmlrpc_enabled', '__return_false'); à functions.php

find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Étape 10 : Basculement DNS et lancement

Effectuez le basculement DNS pendant votre fenêtre de trafic le plus faible. Le processus devrait prendre moins de 15 minutes de travail effectif, avec une fenêtre de propagation allant jusqu’à 48 heures (généralement 1 à 4 heures pour la plupart des résolveurs).

Vérifications finales avant le basculement

• Effectuez une exploration complète de l’URL de staging et confirmez zéro 404
• Vérifiez que toutes les redirections 301 renvoient les en-têtes Location corrects
• Testez les formulaires de contact, la fonctionnalité de recherche et tous les flux e-commerce
• Confirmez que Google Search Console est vérifié sur le nouveau site
• Générez et soumettez un nouveau sitemap XML via Yoast SEO ou Rank Math

Processus de mise à jour DNS

Si vous avez enregistré votre domaine via Enregistrement de domaine, mettez à jour l’enregistrement A directement dans le panneau de gestion DNS. Réduisez le TTL à 300 secondes au moins 24 heures avant le basculement pour minimiser le délai de propagation.

A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutover

Surveillance post-lancement

• Activez l’outil de changement d’adresse de Google Search Console si le domaine lui-même a changé
• Surveillez les Core Web Vitals dans Search Console pendant les 30 premiers jours — attendez-vous à une fluctuation temporaire du classement pendant que Google recrawle et réindexe
• Configurez UptimeRobot ou équivalent pour la surveillance de disponibilité
• Vérifiez les journaux d’erreurs du serveur quotidiennement pendant la première semaine :

tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.log

Resoumission aux moteurs de recherche

Soumettez votre sitemap mis à jour dans Google Search Console :

1. Allez dans Search Console > Sitemaps
2. Entrez sitemap.xml (ou sitemap_index.xml pour les grands sites)
3. Cliquez sur Soumettre

Soumettez également à Bing Webmaster Tools et vérifiez le site indépendamment — l’index de Bing est utilisé par plusieurs moteurs de recherche IA dont Copilot.

Recommandations d’infrastructure d’hébergement

Les performances de votre site WordPress migré dépendent fortement de l’infrastructure sous-jacente. Une migration de Drupal vers WordPress est le moment idéal pour moderniser également votre pile d’hébergement.

Pour les sites à trafic modéré (10 000 à 100 000 visites mensuelles), un plan VPS Hosting avec au moins 2 vCPUs, 4 GB RAM et un stockage NVMe offre une marge suffisante pour WordPress avec un cache de page complet. Pour les sites à fort trafic ou gourmands en ressources, les Serveurs dédiés éliminent entièrement le problème du voisin bruyant et vous donnent un contrôle total sur les paramètres du noyau, la configuration MySQL et le réglage de la pile réseau.

Si vous gérez plusieurs sites clients ou préférez une expérience de gestion de serveur pilotée par interface graphique, les Panneaux de contrôle VPS offrent une gamme d’options incluant cPanel, Plesk et DirectAdmin — chacun prenant en charge la gestion multi-sites WordPress, les sauvegardes automatisées et le provisionnement SSL depuis une interface unique.

Matrice de décision technique : quand utiliser chaque approche de migration

Points techniques clés à retenir

• Sauvegardez avant tout. Un dump SQL compressé et une archive tar de sites/default/files/ sont votre filet de sécurité. Vérifiez que les deux sont complets et restaurables avant de commencer.
• Testez la connectivité à la base de données avant de lancer l’importateur. La majorité des migrations échouées bloquent au test de connexion en raison de règles de pare-feu ou de droits SELECT manquants.
• Le contenu Drupal basé sur des paragraphes nécessite le plugin Premium. La version gratuite ignorera silencieusement les champs de paragraphes, laissant le contenu incomplet sans message d’erreur.
• Les redirections 301 ne sont pas optionnelles. Chaque URL Drupal ayant des backlinks externes ou une indexation dans les moteurs de recherche doit rediriger vers son équivalent WordPress avec un 301 permanent. Une redirection manquante est un signal de classement perdu.
• Réduisez le TTL DNS 24 heures avant le basculement. Réglez-le à 300 secondes pour que la propagation se termine en minutes, pas en heures, lorsque vous changez l’enregistrement A.
• Auditez wp_postmeta pour les champs Drupal non mappés. Les données de champs personnalisés s’y retrouvent après l’importation — vérifiez qu’elles sont présentes et correctement indexées avant de désactiver l’instance Drupal.
• Ne désactivez pas Drupal immédiatement. Maintenez l’environnement Drupal en fonctionnement (en mode maintenance, non accessible publiquement) pendant au moins 30 jours après le lancement comme référence et option de retour arrière.
• Resoumettez votre sitemap le jour même de la mise en ligne. N’attendez pas que Googlebot découvre la nouvelle structure de manière organique — la soumission active accélère le recrawl.

FAQ

Puis-je migrer une installation Drupal multisite vers WordPress ?

Oui, mais chaque sous-site Drupal doit être migré individuellement. Le plugin FG Drupal to WordPress ne gère pas nativement le multisite Drupal en une seule passe. Effectuez une importation séparée pour chaque sous-site, en ciblant soit un réseau WordPress Multisite, soit des installations WordPress autonomes selon votre architecture.

Les mots de passe des utilisateurs Drupal seront-ils transférés vers WordPress ?

Non. Drupal utilise un hachage SHA-512 salé (ou bcrypt dans les versions plus récentes) incompatible avec le hachage basé sur phpass de WordPress. Le plugin FG Premium migre les comptes utilisateurs mais réinitialise les mots de passe, déclenchant un e-mail de réinitialisation de mot de passe pour chaque utilisateur. Planifiez la communication avec les utilisateurs en conséquence.

Comment gérer les types de contenu Drupal sans équivalent WordPress ?

Enregistrez des Custom Post Types (CPTs) équivalents dans WordPress avant de lancer l’importation. Le plugin FG Premium vous permet de mapper les types de contenu Drupal vers des CPTs WordPress. Sans ce mappage, tous les nœuds prennent par défaut le type de publication post, effondrant votre taxonomie de contenu.

Que se passe-t-il avec les termes de taxonomie Drupal lors de la migration ?

Les vocabulaires Drupal sont mappés vers les taxonomies WordPress. Le mappage par défaut convertit les tags Drupal en étiquettes WordPress et les categories Drupal en catégories WordPress. Les vocabulaires personnalisés nécessitent un enregistrement manuel de la taxonomie dans WordPress avant l’importation, sinon ils seront ignorés.

Combien de temps prend la migration pour un grand site Drupal ?

Pour un site avec 5 000 nœuds et 2 GB de médias, prévoyez 2 à 4 heures de temps d’importation sur un serveur bien dimensionné, plus 4 à 8 heures d’audit de contenu post-migration et de configuration des redirections. Le basculement DNS effectif prend moins de 15 minutes. Le temps total écoulé du début à la mise en ligne est généralement d’un à deux jours ouvrables pour une migration approfondie et de qualité production.