Migration WordPress de DreamHost vers cPanel : déplacer le site, la base et le courriel

Ce guide accompagne les administrateurs et les développeurs qui déplacent un site WordPress de l’hébergement mutualisé DreamHost ou de DreamPress vers un serveur cPanel/WHM qu’ils contrôlent. DreamHost utilise son propre panneau de contrôle plutôt que cPanel, donc l’outil de transfert de WHM, qui copie des comptes cPanel complets d’un serveur à l’autre, n’a rien à récupérer. La réponse courte : copiez le site vous-même par SSH, le terminal distant chiffré, avec WP-CLI (l’outil WordPress en ligne de commande) pour la base de données et rsync pour les fichiers. En chemin, vous modifiez un réglage qui piège la plupart des migrations DreamHost, soit l’hôte de la base de données dans wp-config.php. À la fin, le site tourne sur cPanel, il a été testé avec son vrai nom d’hôte, et son courriel a suivi.

Ce que vous allez accomplir

Une liste de tout ce que le compte DreamHost contient pour le domaine, notée avant tout changement.
Les fichiers et la base de données copiés dans un nouveau compte cPanel, avec DB_HOST pointé vers le serveur de base de données local.
Le site testé sur le nouveau serveur grâce à votre fichier hosts, un fichier local qui remplace le DNS pour votre ordinateur seulement.
Le DNS, le courriel et le certificat TLS déplacés dans un ordre prévu, et l’ancien compte fermé seulement après une période d’attente.

Prérequis

Chez DreamHost, il vous faut un accès au panneau qui permet de gérer l’hébergement, les utilisateurs et les bases de données du domaine. Il vous faut aussi un utilisateur avec accès shell. DreamHost propose plusieurs types d’utilisateurs, par exemple SFTP seulement ou shell, et seul un utilisateur shell peut lancer ssh. Dans le panneau, trouvez la section des utilisateurs SFTP ou SSH (les noms de menus changent avec le temps) et passez l’utilisateur du site en accès shell au besoin. Notez le nom du serveur que le panneau affiche pour cet utilisateur ; ce guide l’appelle DHHOST et l’utilisateur DHUSER.

Côté destination, il vous faut un accès root à WHM ou un compte cPanel existant pour le domaine (appelé CPUSER ici). Le compte doit avoir l’accès SSH, et wp doit être installé sur le serveur. La référence des commandes WP-CLI et la documentation des API cPanel décrivent chaque commande utilisée plus bas. Remplacez example.com par votre domaine et NEWIP par l’adresse IP du serveur cPanel.

Vérifiez la version de PHP chez DreamHost, que le panneau affiche pour chaque domaine, et réglez la même version dans le MultiPHP Manager de cPanel. Prévoyez aussi le courriel. Si le domaine utilise le courriel DreamHost, notez dès maintenant chaque boîte aux lettres, alias et redirection. Pour les boîtes, imapsync doit être installé sur une machine Linux que vous contrôlez.

Abaissez à 300 secondes le TTL des enregistrements A, AAAA et MX du domaine, au moins 24 heures avant la bascule. Le TTL (durée de vie) est le temps pendant lequel un résolveur peut garder un enregistrement en cache. Si votre éditeur DNS n’a pas de champ TTL, déplacez l’hébergement DNS vers un fournisseur qui en a un, une semaine à l’avance. Le plan d’abaissement du TTL avant la bascule détaille le calendrier.

Comment ça fonctionne

Un site DreamHost est réparti à plus d’endroits qu’un compte cPanel typique. Les fichiers se trouvent dans le dossier personnel de l’utilisateur, dans un dossier au nom du domaine, par exemple /home/DHUSER/example.com. La base de données ne tourne pas sur le serveur web. Elle est sur un serveur MySQL distinct, joint par un nom d’hôte créé dans le panneau, souvent mysql.example.com. Sur cPanel, MySQL tourne sur la même machine, donc DB_HOST devient localhost.

Carte montrant où se trouve chaque partie d'un site WordPress DreamHost aujourd'hui et où elle arrive sur le serveur cPanel : fichiers, base de données, DNS, courriel et certificat

Le DNS et le courriel suivent des voies distinctes. Si le domaine utilise les serveurs de noms de DreamHost, DreamHost écrit lui-même les enregistrements A tant qu’il héberge le site. Le courriel peut aussi se trouver sur les serveurs de courriel de DreamHost, et il se déplace selon son propre calendrier.

La migration se fait par phases. Vous copiez et testez pendant que DreamHost sert encore les visiteurs, puis vous gelez le site, copiez les derniers changements et basculez le DNS. Le courriel suit dès que les nouvelles boîtes sont prêtes.

Chronologie d'une migration de DreamHost vers cPanel : abaisser le TTL, inventaire, copie, importation, test par le fichier hosts, gel et synchro finale, bascule DNS, certificat, courriel, puis fermeture après une période d'attente

Étapes

Les étapes 1 à 7 sont une répétition que vous pouvez refaire autant de fois que vous voulez. Le changement réel commence à l’étape 8.

Faites l’inventaire chez DreamHost. Connectez-vous avec l’utilisateur shell et rassemblez les informations dont vous aurez besoin :
```
ssh DHUSER@DHHOST
cd ~/example.com
wp --info
wp core version
wp config get DB_HOST
wp config get table_prefix
wp plugin list --status=active --fields=name,version
ls -1 wp-content/mu-plugins/
du -sh ~/example.com
pwd
```
wp --info confirme que WP-CLI fonctionne. DB_HOST devrait afficher le nom d’hôte MySQL, par exemple mysql.example.com, ce qui confirme que la base est distante. Gardez la sortie de pwd, /home/DHUSER/example.com, car ce chemin peut être enregistré dans la base. Si ls montre des fichiers que vous n’avez pas installés, notez-les pour l’étape 5. Sur DreamPress, notez aussi toute extension de cache comme Proxy Cache Purge, qui vide le cache serveur de DreamHost et n’a rien à contacter sur votre serveur.
Exportez la base de données. Toujours chez DreamHost, dans le dossier du site :
```
wp db export ~/dh-export.sql --add-drop-table
tail -c 300 ~/dh-export.sql
```
Attendez-vous à Success: Exported to '/home/DHUSER/dh-export.sql'. La fin du fichier doit se terminer par une instruction complète, souvent suivie d’une ligne -- Dump completed. Si l’export échoue avec une erreur d’accès, l’utilisateur MySQL est peut-être limité à certains hôtes. Ajoutez le serveur web comme hôte autorisé pour cet utilisateur dans la section MySQL du panneau, puis réessayez.
Créez le compte cPanel et la base de données. En root dans WHM, créez le compte s’il n’existe pas encore :
```
whmapi1 createacct username=CPUSER domain=example.com
```
Cherchez result: 1 dans la sortie. Ensuite, en tant que CPUSER, créez la base et son utilisateur. cPanel ajoute le préfixe CPUSER_ aux deux noms, donc vous tapez le nom complet :
```
uapi Mysql create_database name=CPUSER_wp
uapi Mysql create_user name=CPUSER_wp password='STRONG-PASSWORD'
uapi Mysql set_privileges_on_database user=CPUSER_wp database=CPUSER_wp privileges='ALL PRIVILEGES'
```
Chaque appel doit afficher status: 1. Un status: 0 vient avec une ligne errors, souvent un mot de passe refusé par la règle de robustesse du serveur. Choisissez-en un plus long et relancez l’appel.
Copiez les fichiers et le dump. Sur le serveur cPanel, en tant que CPUSER, récupérez les données chez DreamHost :
```
rsync -az --info=progress2 DHUSER@DHHOST:example.com/ ~/public_html/
rsync -az DHUSER@DHHOST:dh-export.sql ~/
```
La barre oblique finale de example.com/ copie le contenu du dossier, pas le dossier lui-même. Vérifiez que la taille correspond à peu près au du -sh de l’étape 1 :
```
du -sh ~/public_html
```
Si rsync répond Permission denied (publickey,password), l’utilisateur DreamHost n’est pas encore un utilisateur shell, ou le changement n’est pas encore appliqué.
Importez la base et corrigez wp-config.php. Pointez WordPress vers la base locale, puis importez :
```
cd ~/public_html
wp config set DB_HOST localhost
wp config set DB_NAME CPUSER_wp
wp config set DB_USER CPUSER_wp
wp config set DB_PASSWORD 'STRONG-PASSWORD'
wp db import ~/dh-export.sql
```
Chaque config set affiche une ligne Success: Updated the constant, et l’importation se termine par Success: Imported from. Retirez ensuite les restes propres à l’hébergeur repérés à l’étape 1. Pour une extension de cache DreamPress, par exemple :
```
wp plugin deactivate varnish-http-purge
```
Lancez cette commande seulement si l’extension est apparue à l’étape 1. Si vous prévoyez un cache sur cPanel, mettez-le en place une fois le site stable.
Réécrivez les chemins enregistrés, et les URL si elles ont changé. Faites d’abord un essai à blanc :
```
wp search-replace '/home/DHUSER/example.com' '/home/CPUSER/public_html' --all-tables --dry-run
```
Le tableau indique combien de lignes changeraient. Si le nombre semble raisonnable, relancez la commande sans --dry-run. Le domaine reste en général le même, donc aucun changement d’URL n’est requis. Si vous avez bâti le site sur un nom d’hôte temporaire ou de préproduction DreamHost, remplacez ce nom par example.com de la même façon. Le search-replace après un changement de domaine explique pourquoi WP-CLI protège les données sérialisées, alors que le SQL écrit à la main les abîme.
Testez avec votre fichier hosts. Sur votre ordinateur, ajoutez cette ligne à /etc/hosts (sous Windows, C:\Windows\System32\drivers\etc\hosts) :
```
NEWIP example.com www.example.com
```
Parcourez le site, connectez-vous, puis essayez un formulaire et le téléversement d’une image. Le navigateur signale un problème de certificat, car aucun n’est encore émis ; acceptez-le pour ce test seulement. Retirez la ligne quand vous avez fini. Si les pages affichent Error establishing a database connection, revérifiez les quatre valeurs de l’étape 5.
Gelez le site, synchronisez les derniers changements et basculez le DNS. Mettez le site DreamHost en mode maintenance pour que rien de nouveau ne soit écrit. Refaites les étapes 2, 4 (le dump et un nouveau rsync des fichiers), 5 (l’importation) et 6. Changez ensuite l’enregistrement A, et AAAA si vous utilisez IPv6, vers NEWIP. Si DreamHost héberge votre DNS, il peut refuser la modification des enregistrements qu’il gère tant que l’hébergement est actif. Dans ce cas, cherchez dans le panneau une option pour passer le domaine en DNS seulement (les noms de menus changent), puis ajoutez votre propre enregistrement A. Sinon, modifiez les enregistrements là où pointent vos serveurs de noms.
Émettez le certificat. La validation HTTP ne fonctionne qu’une fois le DNS pointé vers le nouveau serveur. Vérifiez-le, puis lancez AutoSSL pour le compte, en root :
```
dig +short example.com @1.1.1.1
/usr/local/cpanel/bin/autossl_check --user=CPUSER
```
La première commande doit afficher NEWIP. La seconde journalise ses vérifications et devrait se terminer par un certificat installé pour example.com et www.example.com. Si elle signale un échec DCV (validation du contrôle de domaine, la preuve que le domaine vous appartient), attendez quelques minutes que le DNS se propage et relancez-la.
Déplacez le courriel. Créez d’abord chaque boîte aux lettres sur cPanel :
```
uapi Email add_pop email=info domain=example.com password='MAILBOX-PASSWORD' quota=0
```
Attendez-vous à status: 1. Copiez ensuite chaque boîte avec imapsync, en lisant les mots de passe dans des fichiers pour qu’ils restent hors de votre historique. Utilisez le serveur IMAP que DreamHost indique pour les logiciels de courriel, souvent imap.dreamhost.com :
```
imapsync --host1 imap.dreamhost.com --ssl1 --user1 info@example.com --passfile1 dh.pass \
         --host2 NEWIP --ssl2 --user2 info@example.com --passfile2 cp.pass --dry
```
Quand l’essai à blanc semble correct, relancez sans --dry. Ne changez l’enregistrement MX vers votre serveur cPanel qu’après une première synchronisation de chaque boîte. Relancez imapsync après le changement de MX pour récupérer les derniers messages. La migration de boîtes aux lettres vers cPanel avec imapsync couvre la correspondance des dossiers et les grosses boîtes.
Fermez l’ancien compte après une période d’attente. Gardez DreamHost actif au moins 7 jours après le changement de MX. Téléchargez une dernière copie des fichiers et du dump pour vos archives. Retirez ensuite l’hébergement dans le panneau DreamHost. Si le domaine est enregistré chez DreamHost ou utilise ses serveurs de noms, annulez seulement l’hébergement, pas l’enregistrement ni le DNS.

Valider le résultat

Sur le serveur cPanel, en tant que CPUSER :

cd ~/public_html
wp config get DB_HOST
wp option get siteurl
wp db check
wp core verify-checksums

DB_HOST doit afficher localhost et siteurl votre vraie adresse. wp db check devrait indiquer OK pour chaque table, et les sommes de contrôle doivent être valides. De l’extérieur, vérifiez le DNS, le TLS et l’acheminement du courriel :

dig +short example.com @8.8.8.8
dig +short MX example.com @8.8.8.8
curl -sI https://example.com/ | head -1

La première commande devrait afficher NEWIP, la deuxième votre nouvel hôte de courriel, et la troisième une ligne d’état 200 sans erreur de certificat. Envoyez un message à chaque boîte et répondez depuis celle-ci. Lancez aussi une réinitialisation de mot de passe pour prouver que le site peut envoyer des courriels.

Dépannage

« Error establishing a database connection » après l’importation. DB_HOST indique encore mysql.example.com, ou le nom n’a pas le préfixe CPUSER_. Lancez wp config get DB_HOST et wp config get DB_NAME, puis corrigez avec wp config set.

Les liens et les images pointent encore vers une adresse DreamHost. Le site a été bâti sur un nom d’hôte temporaire. Lancez wp search-replace de ce nom vers example.com avec --all-tables, puis wp cache flush.

Les téléversements échouent avec une erreur de permission. Les fichiers ont été copiés en root. Corrigez le propriétaire en root avec chown -R CPUSER:CPUSER /home/CPUSER/public_html.

AutoSSL ignore le domaine. Le DNS pointe encore vers DreamHost, ou un enregistrement CAA (un enregistrement DNS qui liste les autorités de certification permises pour le domaine) bloque l’émetteur. Vérifiez les deux avec dig, corrigez, puis relancez autossl_check.

Le courriel s’arrête après le changement de MX. La boîte n’existait pas avant le changement de MX, ou cPanel traite le domaine comme un courriel distant. Dans le routage du courriel de cPanel (Email Routing), réglez le domaine sur Local Mail Exchanger une fois le MX pointé vers le serveur, et créez toute boîte manquante.

Quand cette approche ne convient pas

Si vous tenez aux fonctions de DreamPress, comme la préproduction en un clic et le cache géré, un compte cPanel non géré ne les offre pas d’emblée. Il faudrait les bâtir vous-même. Le guide de migration depuis Bluehost montre le même compromis avec un autre hébergeur.

Si le courriel est la partie la plus sensible de l’entreprise, séparez la migration. Déplacez d’abord le site web, laissez le MX chez DreamHost, et déplacez le courriel dans une autre fenêtre.

Si le site contient des dizaines de gigaoctets de fichiers téléversés, la synchro finale de l’étape 8 peut prendre des heures. Lancez le rsync des fichiers quelques fois dans les jours qui précèdent, pour que la dernière passe ne copie que les changements, et prévoyez un gel plus long.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.