Migrer WordPress d'IONOS vers cPanel : le déplacement manuel et la bascule

Ce guide s’adresse à l’administrateur ou au développeur qui déménage un site WordPress d’un hébergement IONOS mutualisé ou Managed WordPress vers un serveur cPanel/WHM qu’il contrôle. IONOS utilise son propre panneau de contrôle plutôt que cPanel, donc aucune archive de compte au format cPanel, le fichier cpmove, n’existe pour l’outil de transfert de WHM. La réponse courte est que vous copiez vous-même les fichiers et la base, reconstruisez le compte et chaque boîte courriel sur cPanel, puis déplacez le DNS en dernier. Le courriel est la partie qui fait le plus mal au client, parce qu’IONOS Mail est un produit distinct qui reste derrière quand les fichiers et la base partent. À la fin, le site est servi par votre propre serveur, testé sur son vrai nom de domaine avant qu’un seul enregistrement DNS ne change.

Ce que vous allez accomplir

Une réponse confirmée sur l’endroit où WordPress vit réellement chez IONOS, souvent un sous-dossier plutôt que le haut du répertoire personnel.
Une copie complète des fichiers et de la base sur votre compte cPanel, vérifiée plutôt que présumée.
Un wp-config.php qui pointe vers la base locale, parce qu’IONOS donne à la base un nom d’hôte bien à elle au lieu de localhost.
Chaque boîte courriel et chaque redirection recréées sur cPanel avant le déplacement des enregistrements MX. MX veut dire mail exchanger, l’enregistrement DNS qui nomme le serveur recevant le courriel du domaine.
Une bascule que vous pouvez répéter, avec le site qui répond sur son vrai nom de domaine avant le premier changement DNS.

Prérequis

Côté IONOS, il vous faut l’identifiant du contrat qui possède l’hébergement, pas seulement un compte administrateur WordPress. Tous les forfaits IONOS offrent le SFTP, c’est-à-dire le transfert de fichiers sur une connexion SSH, et la plupart des forfaits Linux offrent aussi SSH, un shell distant sur le serveur. Confirmez SSH en vous connectant plutôt qu’en lisant une liste de fonctionnalités.

Il vous faut aussi les identifiants de la base. IONOS donne accès à MariaDB ou MySQL par phpMyAdmin, et par le client mysqldump là où SSH existe. Notez le nom d’hôte de la base exactement comme wp-config.php l’affiche, parce que chez IONOS c’est habituellement un nom d’hôte à part plutôt que localhost.

Côté destination, il vous faut un compte cPanel pour le domaine, une base MySQL et son utilisateur, un accès SSH et wp sur la machine. wp, c’est WP-CLI, l’outil WordPress en ligne de commande, décrit dans la référence des commandes WP-CLI.

Alignez la version de PHP avant de copier quoi que ce soit. Relevez-la dans le réglage PHP du panneau IONOS pour ce domaine, puis fixez la même dans MultiPHP Manager de cPanel, qui pilote EA4. EA4, c’est EasyApache 4, le système de compilation qui fournit les versions de PHP offertes par un serveur cPanel. Un site en PHP 8.2 qui atterrit sur un compte réglé à 7.4 échoue d’une façon qui ressemble à un téléversement brisé.

Enfin, dressez la liste de chaque boîte courriel, redirection et répondeur du domaine pendant que le panneau est ouvert. Vous vous servirez de cette liste deux fois.

Comment ça marche

Une migration déplace deux choses qui voyagent bien et trois qui ne voyagent pas. Les fichiers et la base se copient avec des outils ordinaires. Les boîtes courriel, les enregistrements DNS et le certificat TLS doivent chacun être rebâtis de l’autre côté. TLS veut dire transport layer security, le chiffrement derrière une adresse https.

Schéma montrant quelles parties d'un site IONOS la copie des fichiers et de la base emporte vers cPanel, et lesquelles restent derrière et doivent être rebâties

Rien ne se restaure tout seul ici, et le panneau de contrôle en est la raison. IONOS a bâti le sien, donc il n’y a aucune archive de compte cPanel à remettre à WHM. Vous avez un gestionnaire de fichiers, phpMyAdmin, des accès SFTP et, sur la plupart des forfaits Linux, SSH.

Managed WordPress ajoute une couche de plus. Ce produit fait tourner un cache au-dessus de WordPress et livre des extensions qui parlent à la plateforme, et sur votre serveur elles appellent des services que votre compte n’a plus. L’étape 7 les enlève.

Marche à suivre

Tout ce qui précède le gel de l’étape 11 est une répétition que vous pouvez refaire. Tout ce qui suit est en direct.

Trouvez où vit WordPress, et lisez ses identifiants. IONOS donne souvent un sous-dossier à chaque site, alors confirmez le chemin au lieu de le deviner :
```
pwd
ls -1
wp core version
ls -1 wp-content/mu-plugins/
wp config get DB_HOST
wp config get DB_NAME
wp config get DB_USER
```
pwd affiche la vraie racine du site, souvent de la forme /homepages/NN/dNNNNNNNNN/htdocs avec un dossier par site en dessous. Gardez cette chaîne, parce qu’une extension a pu la stocker dans la base. ls -1 devrait montrer wp-admin, wp-content et wp-includes côte à côte, et sinon vous êtes un répertoire trop haut. Surveillez DB_HOST : autre chose que localhost veut dire que la base est sur un hôte IONOS distinct, et l’étape 6 le corrige. Sans SSH, lisez le dossier cible du domaine dans le panneau et ouvrez wp-config.php dans le gestionnaire de fichiers.
Exportez la base. Avec SSH et WP-CLI :
```
wp db export ionos.sql --add-drop-table
```
Attendez-vous à Success: Exported to 'ionos.sql'. Avec SSH mais sans WP-CLI, utilisez le client directement avec les valeurs de l’étape 1 :
```
mysqldump -h DBHOST -u DBUSER -p DBNAME --single-transaction --default-character-set=utf8mb4 --add-drop-table > ionos.sql
```
Il demande Enter password: et n’affiche rien d’autre quand ça marche. Dans les deux cas, vérifiez la fin du fichier :
```
tail -3 ionos.sql
```
La dernière ligne devrait être -- Dump completed. Un dump tronqué s’importe sans se plaindre et perd discrètement la fin de votre plus grosse table. Sans SSH, passez par phpMyAdmin : choisissez la base, puis Exporter, puis Personnalisé, et cochez l’option qui ajoute les instructions DROP TABLE.
Empaquetez les fichiers. Depuis la racine confirmée à l’étape 1 :
```
ls -a | grep htaccess
tar -czf ~/ionos-files.tar.gz wp-content wp-config.php .htaccess
ls -lh ~/ionos-files.tar.gz
```
Lancez le grep d’abord. Les sites Managed WordPress n’ont souvent aucun .htaccess, et tar s’arrête sur Cannot stat: No such file or directory si vous nommez un fichier absent. tar reste muet quand il réussit, alors comparez la taille affichée par ls -lh à l’espace disque indiqué par le panneau. Les fichiers du cœur restent derrière, puisque l’étape 5 en télécharge une copie propre.
Bâtissez le côté cPanel avant de copier quoi que ce soit. Créez le compte dans WHM, puis la base et son utilisateur dans l’assistant de bases MySQL de cPanel. Réglez la version de PHP dans MultiPHP Manager à celle des prérequis. Créez ensuite chaque boîte courriel, redirection et répondeur de votre liste, en gardant la même partie locale. Des boîtes vides ne coûtent rien pendant que MX pointe encore vers IONOS, et ce sont elles qui empêchent le courriel de rebondir plus tard.
Déplacez les octets. Tirez plutôt que pousser, en lançant ceci sur le serveur cPanel sous l’utilisateur du compte :
```
wp core download --version=WPVERSION --skip-content --path=/home/CPUSER/public_html
rsync -avz -e 'ssh -p 22' IONOSUSER@IONOSHOST:DOCROOT/wp-content/ /home/CPUSER/public_html/wp-content/
scp -P 22 IONOSUSER@IONOSHOST:ionos.sql IONOSUSER@IONOSHOST:wp-config.php /home/CPUSER/
```
Utilisez la version affichée à l’étape 1, ainsi que l’hôte et le port montrés par le panneau SSH d’IONOS, qui est le 22 sauf indication contraire. --skip-content laisse wp-content vide pour que rsync le remplisse. rsync se termine par un résumé sent ... received ..., et scp affiche une ligne de progression par fichier qui finit à 100%. Ne lancez jamais l’un ou l’autre en root, sinon le problème de propriété du dépannage devient le vôtre. Avec le SFTP seulement :
```
echo 'get -r DOCROOT ionos-files' | sftp -b - IONOSUSER@IONOSHOST
```
Ça affiche une ligne Fetching ... par répertoire et se termine sans bruit.
Importez la base et pointez wp-config.php vers localhost. Mettez d’abord l’ancien wp-config.php dans la racine du site, puis corrigez-le :
```
cd /home/CPUSER/public_html
wp db import /home/CPUSER/ionos.sql
wp config set DB_HOST localhost
wp config set DB_NAME CPUSER_wp
wp config set DB_USER CPUSER_wpuser
wp config set DB_PASSWORD 'THEPASSWORDYOUSET'
wp db check
```
L’import répond Success: Imported from '/home/CPUSER/ionos.sql'. Chaque wp config set répond avec la constante et sa nouvelle valeur, et wp db check affiche une ligne par table se terminant par OK. Laissez le nom d’hôte IONOS en place et le site continue de lire l’ancienne base par le réseau, ce qui ressemble à une migration réussie jusqu’à la fin du contrat.
Retirez le code de plateforme laissé par Managed WordPress. Listez ce qui est là avant de supprimer quoi que ce soit, parce que l’ensemble varie selon l’âge du compte :
```
ls -1 wp-content/mu-plugins/
wp plugin list --fields=name,status
ls -l wp-content/object-cache.php wp-content/advanced-cache.php
grep -n "WP_CACHE" wp-config.php
```
Tout ce qui porte le nom de l’hébergeur, ou celui de son assistant ou de son outillage de performance, appartient à la plateforme que vous quittez. Retirez chaque élément par son nom :
```
wp plugin deactivate PLUGINNAME
wp plugin delete PLUGINNAME
rm -f wp-content/object-cache.php wp-content/advanced-cache.php
wp config delete WP_CACHE
```
Attendez-vous à Success: Deactivated 1 of 1 plugins. puis Success: Deleted 1 of 1 plugins. Le rm efface des fichiers de cache qui pointent vers des services que ce serveur ne fait pas tourner. wp config delete WP_CACHE répond avec la constante retirée, et vous sautez cette commande si le grep n’a rien trouvé.
Corrigez les chemins stockés, et les URL seulement si le domaine change. Quand le nom de domaine reste le même, l’URL du site n’a besoin d’aucune réécriture. Un search-replace dessus brasse des lignes pour rien. Le chemin absolu est un autre dossier, parce que certaines extensions le stockent. Remplacez la chaîne donnée par pwd à l’étape 1, à blanc d’abord :
```
wp search-replace '/homepages/NN/dNNNNNNNNN/htdocs' '/home/CPUSER/public_html' --all-tables --dry-run --report-changed-only
wp search-replace '/homepages/NN/dNNNNNNNNN/htdocs' '/home/CPUSER/public_html' --all-tables --precise
```
L’essai à blanc affiche les comptes par table et une ligne finale Success: N replacements to be made. --all-tables parcourt les tables créées par une extension sous un autre préfixe, que le balayage par défaut saute. --precise fait désérialiser et resérialiser WP-CLI en PHP au lieu de passer par du SQL brut, ce qui garde les tableaux sérialisés valides quand un remplacement change la longueur d’une chaîne. Relancez la même paire sur l’ancien et le nouveau domaine seulement si le domaine change vraiment.
Descendez le courriel pendant qu’IONOS le détient encore. Les boîtes de l’étape 4 sont vides et MX pointe toujours vers IONOS, donc les deux côtés sont lisibles en même temps. imapsync copie les messages en IMAP, le protocole qu’un client de messagerie utilise pour lire du courriel gardé sur le serveur :
```
imapsync --host1 IONOSIMAPHOST --user1 you@example.com --password1 OLDPASS --host2 localhost --user2 you@example.com --password2 NEWPASS
```
Prenez IONOSIMAPHOST dans le nom du serveur entrant, sur la page des réglages de messagerie d’IONOS. L’outil se termine par un résumé de transfert et une ligne Detected 0 errors. Pour deux ou trois boîtes, ajouter les deux comptes dans un client de bureau et glisser les dossiers fonctionne aussi bien.
Prouvez le site sur son vrai nom avant de toucher au DNS. Sur votre poste, ajoutez à /etc/hosts une ligne NEWIP example.com www.example.com. Votre navigateur atteint alors le nouveau serveur pendant que le reste du monde voit encore IONOS. curl peut faire la même chose pour une seule requête :
```
curl -sI --resolve example.com:80:NEWIP http://example.com/ | head -1
```
Attendez-vous à HTTP/1.1 200 OK, ou à un 301 si le site redirige vers https. Faites ensuite émettre le certificat. AutoSSL est le service de certificats gratuit de cPanel, et il prouve que vous contrôlez le domaine par DCV, soit domain control validation. La validation par HTTP ne peut pas passer tant que le domaine résout vers IONOS, donc utilisez la méthode DNS et ajoutez l’enregistrement TXT demandé dans le panneau DNS d’IONOS. Le portail de documentation cPanel couvre ces choix. Retestez ensuite en TLS :
```
uapi SSL installed_hosts | grep -i domains
curl -sI --resolve example.com:443:NEWIP https://example.com/ | head -1
```
Le domaine racine, www et chaque sous-domaine servi par le site doivent apparaître dans la première sortie. La seconde devrait renvoyer HTTP/2 200 sans avertissement de certificat.
Abaissez le TTL, gelez, synchronisez le delta, puis déplacez les enregistrements. TTL veut dire time to live, le nombre de secondes pendant lesquelles un résolveur peut garder une réponse en cache. Abaissez les enregistrements A, AAAA et MX à 300 au moins 24 heures avant la bascule, dans le panneau qui détient la zone. Pour la plupart de ces domaines, ce panneau est celui d’IONOS, puisqu’IONOS est aussi le registraire. Vérifiez ce que les résolveurs distribuent :
```
dig +noall +answer example.com @1.1.1.1
dig +noall +answer MX example.com @1.1.1.1
```
La deuxième colonne de chaque ligne de réponse est le TTL en secondes, et elle doit afficher 300 avant d’aller plus loin. Mettez ensuite le site IONOS en mode maintenance pour qu’aucune commande, aucun commentaire et aucun formulaire n’arrive après votre export final. Refaites les étapes 2, 3 et 5 pour rattraper le delta, réimportez, et déplacez MX d’abord, puis A et AAAA.

Terminez en vidant les règles façonnées par l’ancien hébergeur :
```
wp rewrite flush --hard
wp cache flush
```
Attendez-vous à Success: Rewrite rules flushed. et Success: The cache was flushed. La forme --hard écrit le bloc WordPress dans .htaccess en plus de la copie en base, ce qui compte quand le site est arrivé sans aucun .htaccess.

Valider que ça fonctionne

Environ une heure après la bascule, vérifiez depuis l’intérieur du compte :

wp option get siteurl
wp option get home
wp db check
wp core verify-checksums

Les deux options doivent renvoyer le domaine final et chaque table doit répondre OK. Les sommes de contrôle devraient afficher Success: WordPress installs verify against checksums. Mettez ensuite vos vingt URL les plus consultées dans un fichier et balayez-les :

while read -r u; do code=$(curl -o /dev/null -s -w '%{http_code}' "$u"); echo "$code $u"; done < top-urls.txt

Chaque ligne devrait afficher 200, ou 301 là où vous redirigez volontairement. Confirmez ensuite la résolution et le routage du courriel depuis un résolveur public :

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

La première doit renvoyer l’adresse de votre serveur cPanel, la deuxième votre hôte de messagerie prévu, et la troisième HTTP/2 200 sans erreur de certificat. Envoyez un vrai message à chaque boîte et répondez depuis celle-ci. Exercez aussi le courriel envoyé par le site : réinitialisation de mot de passe, formulaire de contact, confirmation de commande. Surveillez le journal d’erreurs et la Search Console pendant 72 heures avant de toucher au contrat IONOS.

Dépannage

Le site charge, mais les modifications faites sur le nouveau serveur n’apparaissent jamais. wp-config.php porte encore le nom d’hôte de la base IONOS, donc WordPress lit et écrit l’ancienne base par le réseau. Lancez wp config get DB_HOST. S’il répond autre chose que localhost, refaites l’étape 6 et réimportez : le contenu ajouté depuis l’import vit dans l’ancienne base.

L’import s’arrête sur un collation inconnu. Un dump écrit par un MySQL plus récent porte un collation que la destination ne connaît pas. Réécrivez-le avant d’importer :

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' ionos.sql

Un avertissement venant d’une extension au nom de l’hébergeur s’affiche au-dessus de la page. L’étape 7 a manqué quelque chose dans wp-content/mu-plugins/. WordPress charge ces extensions à chaque requête, sans bouton d’arrêt dans l’admin. Supprimez le fichier et rechargez. Une sortie imprimée avant les en-têtes casse aussi le Set-Cookie qui vous connecte, donc ça ressemble souvent à un échec de connexion.

Le courriel rebondit ou disparaît après la bascule. Sans boîtes créées avant le déplacement des MX, le courriel arrive sur un serveur qui n’a nulle part où le mettre. Si MX pointe encore vers IONOS alors que le domaine vit sur votre compte cPanel, cPanel se considère comme le serveur de courriel local et avale le message. Réglez le domaine sur Remote Mail Exchanger dans l’écran Routage du courriel de cPanel tant que MX n’a pas vraiment bougé.

Les téléversements échouent en 403 et WordPress ne peut pas écrire dans wp-content. Vous avez copié les fichiers en root, donc ils appartiennent à root :

chown -R CPUSER:CPUSER /home/CPUSER/public_html
find /home/CPUSER/public_html -type d -exec chmod 755 {} \;
find /home/CPUSER/public_html -type f -exec chmod 644 {} \;

Quand ce n’est pas la bonne approche

Si le site quitte Managed WordPress et que quelqu’un s’attend à la même vitesse à l’arrivée, mesurez d’abord. Ce produit sert une bonne part du trafic depuis un cache placé au-dessus de WordPress, donc les chiffres dont vous vous souvenez ont été mesurés avec PHP largement contourné. Sur un compte cPanel ordinaire, cette couche n’existe pas tant que vous ne la bâtissez pas, avec LiteSpeed Cache sur un serveur LiteSpeed ou une extension de cache de page sur Apache.

Si le courriel du domaine est le cœur de l’entreprise, coupez le déménagement en deux. Migrez le site web vers cPanel, laissez le courriel chez IONOS pour l’instant, et réglez le domaine sur Remote Mail Exchanger pour que cPanel arrête de livrer localement. Ça retire la voie la plus risquée de la bascule.

Si IONOS est aussi le registraire et que vous comptez transférer le nom de domaine, ne faites pas les deux la même semaine. Un transfert de registraire a sa propre fenêtre de plusieurs jours et ses propres modes d’échec. Déplacez l’hébergement, prouvez-le, puis lancez le transfert. Gardez le forfait IONOS payé au moins 30 jours après la bascule, et faites le ménage de l’ancien serveur après la migration une fois le courriel et le web confirmés ailleurs.

Si votre source est une plateforme infogérée avec un chemin d’export documenté plutôt qu’IONOS, le travail a une autre forme. Migrer WordPress de Kinsta vers cPanel couvre ce cas.

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.