Un client gérait son site WordPress depuis des années sur un hébergement mutualisé cPanel, pratique pour l’installation en un clic mais de plus en plus limitant à mesure que son trafic augmentait : impossible d’ajuster PHP-FPM finement, impossible d’installer certains modules, support générique peu technique. Il voulait un VPS Debian, avec la pile logicielle qu’il choisirait lui-même, quitte à gagner en responsabilité d’administration.
La migration d’un environnement cPanel (généralement Apache avec PHP en mode suPHP ou CGI) vers un VPS nu (généralement nginx et PHP-FPM) n’est pas un simple copier-coller de fichiers : les deux environnements diffèrent sur les permissions, la gestion des .htaccess et la configuration PHP elle-même. Voici les étapes suivies, dans l’ordre, pour cette bascule précise.
1. Exporter l’intégralité du site depuis cPanel
cPanel propose un export complet du compte via l’outil « Backup » de son interface, qui génère une archive contenant les fichiers, la base de données et la configuration de messagerie. Pour un contrôle plus fin, l’export manuel via SSH reste préférable :
ssh client@ancien-hebergeur.exemple
cd public_html
tar czf /home/client/site-complet.tar.gz .
mysqldump -u client_wp -p client_wordpress > /home/client/dump.sql
2. Préparer le VPS Debian : pile logicielle
Sur le VPS neuf, on installe nginx, PHP-FPM (avec les extensions requises par WordPress) et MariaDB, sans les à-côtés cPanel devenus inutiles :
sudo apt update
sudo apt install nginx mariadb-server php-fpm php-mysql php-xml php-curl php-gd php-mbstring php-zip
3. Transférer les fichiers et la base
Le transfert se fait directement de serveur à serveur via scp, sans repasser par un poste local, pour gagner en vitesse et éviter une étape intermédiaire :
scp client@ancien-hebergeur.exemple:/home/client/site-complet.tar.gz /var/www/nouveau-site/
scp client@ancien-hebergeur.exemple:/home/client/dump.sql /tmp/
tar xzf /var/www/nouveau-site/site-complet.tar.gz -C /var/www/nouveau-site/
mysql -u root -p -e "CREATE DATABASE client_wordpress CHARACTER SET utf8mb4;"
mysql -u root -p client_wordpress < /tmp/dump.sql
4. Recréer les permissions, un point sensible
cPanel exécute PHP sous l'identité de l'utilisateur du compte (via suPHP ou CGI), avec des droits assez permissifs par défaut. Sur un VPS nginx + PHP-FPM classique, PHP tourne sous un utilisateur dédié (souvent www-data), distinct du propriétaire des fichiers si l'on suit les bonnes pratiques de séparation des droits.
chown -R www-data:www-data /var/www/nouveau-site
find /var/www/nouveau-site -type d -exec chmod 755 {} \;
find /var/www/nouveau-site -type f -exec chmod 644 {} \;
5. Convertir les règles .htaccess en configuration nginx
nginx n'interprète pas les fichiers .htaccess : les règles de réécriture de cPanel doivent être traduites en configuration de bloc serveur. Pour WordPress, l'essentiel tient en quelques lignes de try_files.
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
6. Adapter wp-config.php et vérifier les identifiants de connexion à la base
Le fichier wp-config.php pointait vers un hôte de base de données local à l'ancien mutualisé (parfois une adresse spécifique, pas toujours localhost). Sur le VPS, il faut vérifier et corriger DB_HOST, DB_USER, DB_PASSWORD pour coller aux nouveaux identifiants MariaDB créés localement.
7. Basculer le DNS et vérifier avant coupure de l'ancien hébergement
Avant toute bascule DNS, un test complet via une entrée modifiée dans le fichier hosts local permet de vérifier que le site fonctionne à l'identique sur le nouveau serveur. Une fois validé, le TTL du domaine est abaissé, le DNS basculé, et l'ancien hébergement conservé encore quelques jours en lecture seule avant résiliation définitive.
- Vérifier chaque formulaire (contact, commentaires) après bascule, souvent oublié dans les tests rapides
- Contrôler les logs d'erreur PHP-FPM les premières heures pour repérer une extension manquante
- Ne résilier l'ancien compte cPanel qu'après au moins une semaine de fonctionnement stable
La différence de permissions entre cPanel et un VPS nu est, de loin, la cause la plus fréquente d'erreurs 500 silencieuses après ce type de migration.
Notre verdict
Migrer de cPanel vers un VPS Debian demande de reprendre la main sur des détails que cPanel gérait auparavant tout seul — permissions, réécriture d'URL, configuration PHP. Le gain en contrôle et en performance justifie l'effort pour un client dont le trafic ou les besoins techniques dépassent ce qu'un mutualisé peut raisonnablement offrir, à condition d'accepter la responsabilité d'administration système qui vient avec.
