# Migrer un site WordPress d’un hébergeur cPanel vers un VPS Debian

> Un client voulait sortir du mutualisé cPanel pour un VPS Debian maîtrisé en ligne de commande. Voici les commandes précises de cette bascule technique, étape par étape.

- Auteur : Clément Hadrot
- Publié le : 2022-10-09
- Mis à jour le : 2022-10-09
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/migrer-wordpress-cpanel-vps-debian/

## L’essentiel

- L'export cPanel fournit une archive complète prête à être exploitée
- nginx et PHP-FPM remplacent Apache et le mode CGI de cPanel
- Les permissions de fichiers changent radicalement d'un environnement à l'autre

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
```

> L'essentiel à retenir : L'export cPanel fournit une archive complète prête à être exploitée ; nginx et PHP-FPM remplacent Apache et le mode CGI de cPanel ; Les permissions de fichiers changent radicalement d'un environnement à l'autre

## 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.