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-cronnatif 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.
- Installer All-in-One WP Migration (ou Duplicator) côté source.
- Lancer l'export : le plugin génère une archive contenant fichiers + base.
- Télécharger l'archive en local.
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.
- SFTP : télécharger l'intégralité de la racine WordPress en local.
- 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
- Dans Plesk, Sites Web & Domaines > Ajouter un domaine. Utilisez le nom final (
monsite.fr) même si le DNS ne pointe pas encore. - Racine web par défaut :
/httpdocs. - Dans Bases de données, créez une nouvelle base MySQL/MariaDB avec un utilisateur dédié. Notez les identifiants.
- 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.
--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.
- 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).
- 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.
- J+0 : suivez la propagation via
dig +short monsite.fr @8.8.8.8,@1.1.1.1, et un outil comme dnschecker.org. - J+1 à J+3 : monitorez access/error logs côté Plesk, vérifiez l'absence de pics d'erreurs 500 ou 404.
- J+7 : remontez le TTL à 3600 ou 86400.
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.
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-replacepassé 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.