🚀 Premiers pas

Migrer un site WordPress vers Datacampus (depuis OVH, o2switch, Infomaniak, 1&1…)

Guide pas-à-pas pour migrer proprement un site WordPress depuis n'importe quel hébergeur mutualisé vers un hébergement Datacampus : inventaire, export, import, search-replace, tests, bascule DNS et post-migration.

intermédiaire ⏱ 20 min Mise à jour : 2026-04-24

Cette doc s'adresse aux agences web qui migrent un site WordPress d'un hébergeur mutualisé (OVH, o2switch, Infomaniak, 1&1/IONOS, PlanetHoster…) vers un hébergement Datacampus sous Plesk. Elle déroule chaque phase, du premier inventaire jusqu'au monitoring post-bascule, avec trois approches d'export selon la taille du site et la propreté de l'ancien environnement.

Pourquoi migrer chez Datacampus

  • Souveraineté numérique : datacenter Cassin1 au Futuroscope, AS50446, données 100 % en France, stack 100 % Open Source, aucune dépendance cloud étrangère.
  • Performance : stockage Ceph NVMe en réplica 3, PHP-FPM par site, HTTP/2 et HTTP/3. Les sites WordPress gagnent souvent un facteur 2 à 3 sur le TTFB comparé au mutualisé bas de gamme.
  • Support FR direct : équipe à Niort, pas de call center, ticket pris en charge par un ingénieur qui connaît votre infra. Zéro sous-traitance.
  • Éco-responsable : énergie 100 % renouvelable, immersion cooling Submer SmartPodX (PUE cible 1.03), récupération de chaleur fatale. Datacampus est Entreprise à mission, certifiée Positive Company et membre vérifié de The Green Web Foundation.

Pour une agence, c'est aussi un argument commercial : dire à un client que son site tourne sur un hébergeur français indépendant, alimenté en renouvelable, change la conversation RSE.

Phase 1 — Préparation et inventaire

Avant de toucher quoi que ce soit, on dresse l'état des lieux. Cette phase évite 80 % des mauvaises surprises en phase d'import.

Inventaire technique

  • Taille totale du site : du -sh ~/www/ en SSH, ou inspection du File Manager. Au-delà de 2 Go, les plugins de migration atteignent leurs limites.
  • Base de données : taille, nombre de tables, préfixe (wp_ ou custom), moteur (InnoDB partout idéalement), collation (utf8mb4_unicode_ci).
  • Versions : PHP côté source, MySQL/MariaDB, WordPress core, thème, extensions.
  • Extensions sensibles : WooCommerce, WPML, LearnDash, cache (WP Rocket, W3TC, LiteSpeed Cache) et plugins d'optimisation d'images qui peuvent stocker des chemins absolus.
  • Tâches cron : wp-cron natif ou vrai cron système ? Si cron système, on le recrée côté Plesk.
  • Emails transactionnels : SMTP externe (Mailjet, Brevo, SendGrid) ou fonction mail() PHP ?
  • DNS actuel : qui gère la zone ? TTL des enregistrements A et MX ?

Créer l'abonnement Datacampus

Choisissez l'offre adaptée sur datacampus.fr/heberger-un-site-web. Pour un WordPress d'agence, un hébergement mutualisé Plesk suffit dans la majorité des cas ; pour du WooCommerce à fort trafic ou plusieurs dizaines de sites, on passe sur un VPS ou un cluster Proxmox dédié. L'équipe commerciale vous oriente en cas de doute.

À réception des identifiants Plesk, prenez le temps de vous familiariser avec l'interface : voir Plesk au quotidien.

Phase 2 — Export depuis l'ancien hébergeur

Trois méthodes, à choisir selon le contexte.

Méthode A : plugin All-in-One WP Migration ou Duplicator

Rapide, sans compétence sysadmin, idéal pour les sites de moins de 512 Mo.

  1. Installer All-in-One WP Migration (ou Duplicator) côté source.
  2. Lancer l'export : le plugin génère une archive contenant fichiers + base.
  3. Télécharger l'archive en local.
⚠️
Limite de taille
La version gratuite d'All-in-One WP Migration bride l'import à 512 Mo. Pour dépasser, passez à la version Premium ou basculez sur la méthode wp-cli. Duplicator est plus souple sur la taille mais peut ramer sur les gros sites.

Méthode B : wp-cli (recommandée)

C'est la méthode propre, scriptable, sans limite de taille. Voir wp-cli pour l'installation et les commandes de base.

En SSH sur l'ancien hébergeur :

cd ~/www/
wp db export dump.sql --add-drop-table --default-character-set=utf8mb4
tar -czf site.tar.gz --exclude='wp-content/cache' --exclude='wp-content/updraft' .

Puis on rapatrie en local :

scp user@ancien-hebergeur:~/www/site.tar.gz ./
scp user@ancien-hebergeur:~/www/dump.sql ./

Méthode C : manuel (SFTP + phpMyAdmin)

Quand vous n'avez ni SSH, ni plugin autorisé. C'est le plus lent.

  1. SFTP : télécharger l'intégralité de la racine WordPress en local.
  2. phpMyAdmin : exporter la base au format SQL (format compressé gzip si disponible).

Sur les très grosses bases, phpMyAdmin atteint sa limite. Dans ce cas, demandez un dump à l'hébergeur source ou utilisez un plugin comme WP-DBManager.

Phase 3 — Import sur Datacampus

Créer le domaine et la base dans Plesk

  1. Dans Plesk, Sites Web & Domaines > Ajouter un domaine. Utilisez le nom final (monsite.fr) même si le DNS ne pointe pas encore.
  2. Racine web par défaut : /httpdocs.
  3. Dans Bases de données, créez une nouvelle base MySQL/MariaDB avec un utilisateur dédié. Notez les identifiants.
  4. Vérifiez la version PHP dans Paramètres PHP : alignez-la avec celle de l'ancien hébergeur, vous basculerez plus tard.

Uploader les fichiers

Deux options. SFTP (FileZilla, Cyberduck) pour un transfert direct, File Manager Plesk pour uploader l'archive puis clic droit > Extraire. Sur une archive .tar.gz, préférez SSH :

cd ~/httpdocs
tar -xzf ~/site.tar.gz

Importer la base

Par phpMyAdmin pour les petits dumps, par ligne de commande pour les gros :

mysql -u MON_USER -p MA_BASE < dump.sql

Voir MySQL/MariaDB en ligne de commande.

Adapter wp-config.php

Éditez wp-config.php pour pointer vers la nouvelle base :

define('DB_NAME',     'nouvelle_base');
define('DB_USER',     'nouveau_user');
define('DB_PASSWORD', 'mot_de_passe');
define('DB_HOST',     'localhost');

Profitez-en pour régénérer les clés de sécurité (API WordPress) et retirer les constantes obsolètes (WP_CACHE si vous changez de solution de cache, chemins absolus hardcodés par certains plugins).

Phase 4 — search-replace des URLs

Si le domaine final est identique à l'ancien, passez cette étape. Sinon, il faut remplacer les URLs dans la base. Ne jamais faire de sed brut sur le dump : WordPress stocke des données sérialisées (widgets, options, Elementor, ACF…) qui cassent si on modifie la chaîne sans ajuster la longueur.

La bonne approche, c'est wp-cli :

wp search-replace 'https://ancien.fr' 'https://nouveau.fr' --all-tables --precise --skip-columns=guid
wp search-replace 'http://ancien.fr' 'https://nouveau.fr' --all-tables --precise --skip-columns=guid

Le flag --skip-columns=guid évite de casser l'identifiant historique des articles. Pour les sites multisite, ajoutez --network.

💡
Mode dry-run
Ajoutez --dry-run à la commande wp search-replace pour voir le nombre d'occurrences touchées sans rien modifier. Utile avant le coup final.

Phase 5 — Tests sur hostname temporaire

On ne bascule jamais le DNS avant d'avoir validé le site sur la nouvelle plateforme. Deux techniques.

Hostname Plesk temporaire

Plesk expose un hostname de preview du type monsite.datacampus.ninja (ou équivalent selon votre abonnement). Ajoutez-le en tant qu'alias du domaine, faites un wp search-replace temporaire, testez, puis revenez.

Modifier le fichier hosts local

Plus propre, car aucune modification en base. Sur macOS/Linux, éditez /etc/hosts :

10.0.20.XX    monsite.fr www.monsite.fr

Remplacez par l'IP de votre serveur Datacampus (visible dans Plesk). Redémarrez le navigateur. Vous naviguez sur la nouvelle infra pendant que le reste du monde voit encore l'ancien site.

Check-list de validation

  • Page d'accueil, pages piliers, article type, page contact.
  • Tunnel WooCommerce complet jusqu'à la page de paiement (pas de transaction réelle).
  • Formulaires : envoi d'email test.
  • Admin WordPress : connexion, dashboard, mise à jour d'un article.
  • Images, fonts, CSS, JS : aucun 404 dans la console navigateur.
  • Sitemap XML et robots.txt.
  • Performance : PageSpeed Insights ou WebPageTest.

Phase 6 — Bascule DNS

Une fois la validation OK, on planifie la bascule.

  1. J-1 : abaissez le TTL de l'enregistrement A (et AAAA) à 300 secondes chez le registrar ou le gestionnaire DNS. La propagation de cette baisse prend le TTL précédent (souvent 3600 ou 86400 secondes).
  2. Jour J : changez l'enregistrement A (et AAAA si IPv6) vers l'IP Datacampus. Ne touchez pas aux MX si le mail reste chez l'ancien fournisseur.
  3. J+0 : suivez la propagation via dig +short monsite.fr @8.8.8.8, @1.1.1.1, et un outil comme dnschecker.org.
  4. J+1 à J+3 : monitorez access/error logs côté Plesk, vérifiez l'absence de pics d'erreurs 500 ou 404.
  5. J+7 : remontez le TTL à 3600 ou 86400.
Gelez les contenus
Entre le dump et la bascule DNS, demandez au client de ne plus publier ni modifier de contenu. Sinon les nouvelles publications restent sur l'ancien serveur et disparaissent après la bascule. Si le gel est impossible (média actif, e-commerce), prévoyez un second dump juste avant le changement DNS.

Phase 7 — Post-migration

SSL Let's Encrypt

Une fois le DNS propagé, dans Plesk : SSL/TLS > Installer un certificat Let's Encrypt gratuit. Cochez le domaine principal, www, et les sous-domaines exposés. Renouvellement automatique géré par Plesk. Voir Let's Encrypt avec Plesk.

Caches et CDN

  • Purge du cache WordPress (WP Rocket, W3TC, LiteSpeed Cache).
  • Purge du CDN (Cloudflare, BunnyCDN, etc.) si utilisé.
  • Vider le cache navigateur pour vos tests.

Emails transactionnels

Testez un envoi depuis WordPress (mot de passe oublié, commande WooCommerce). Si vous utilisiez la fonction mail() PHP côté source, c'est le moment de passer à un SMTP authentifié (plugin WP Mail SMTP + un relais comme Mailjet ou votre serveur Mailcow Datacampus). La délivrabilité sera meilleure, surtout si l'ancien hébergeur avait une bonne réputation IP que vous laissez derrière vous.

Redirections 301

Si les URLs changent (ex : passage en HTTPS, changement de permaliens, consolidation de domaines), créez les redirections 301. Dans un .htaccess WordPress standard :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.ancien\.fr$ [NC]
RewriteRule ^(.*)$ https://nouveau.fr/$1 [R=301,L]

Déclarez le changement d'adresse dans Google Search Console et Bing Webmaster. Resoumettez le sitemap.

Monitoring

Activez un monitoring externe (UptimeRobot, Updown.io, ou via Datacampus sur demande). Configurez une alerte email sur 500/timeout pendant la première semaine.

💡
Migration clé en main
Pas le temps ? Datacampus propose un accompagnement migration clé en main : nos ingénieurs prennent en charge l'export, l'import, le search-replace, la bascule DNS et le monitoring post-migration. Vous fournissez les accès, on vous rend un site opérationnel. Demandez un devis à sales@datacampus.fr ou via le formulaire de contact.

Check-list finale

À cocher mentalement avant de clôturer la mission.

  • Inventaire source archivé (tailles, versions, plugins).
  • Dump SQL et archive fichiers conservés hors production pendant 30 jours.
  • wp-config.php adapté, clés de sécurité régénérées.
  • wp search-replace passé si changement d'URL, avec --skip-columns=guid.
  • Tests fonctionnels validés sur hostname temporaire ou via /etc/hosts.
  • TTL abaissé avant bascule, remonté après stabilisation.
  • Certificat Let's Encrypt installé, renouvellement auto actif.
  • Caches WordPress et CDN purgés.
  • Emails transactionnels testés, SMTP authentifié configuré.
  • Redirections 301 en place, Search Console notifiée.
  • Monitoring externe armé, logs Plesk surveillés 7 jours.
  • Ancien hébergement conservé 30 jours minimum (roll-back possible) puis résilié.

Une question sur votre migration ? Voir Ouvrir un ticket support efficace, ou écrivez directement à sales@datacampus.fr.

Pour aller plus loin

Besoin d'aide ?

Cette documentation ne couvre pas votre cas ? Notre support humain est là.