Migrer WordPress de Flywheel vers cPanel : le guide de bascule complet

Ce guide vous accompagne pour sortir un site WordPress de Flywheel et l’installer sur un compte d’hébergement cPanel. Flywheel est l’hébergeur WordPress infogéré racheté par WP Engine en 2019, et une bonne partie de ce qui fait fonctionner votre site là-bas vit en dehors de WordPress. Vous n’avez pas de shell sur les forfaits d’entrée, Flywheel est propriétaire du fichier wp-config.php, et vos règles de redirection vivent dans leur tableau de bord, où aucune sauvegarde ne les trouvera. La réponse courte consiste à récupérer le site dans Local, l’application de bureau gratuite écrite par Flywheel, puis à en exporter une archive simple de fichiers et un vidage de base. Vous rebâtissez ensuite à la main, du côté cPanel, tout ce qui n’existait que dans le tableau de bord.

Ce que vous allez accomplir

Une archive portable du site, c’est-à-dire tous les fichiers plus un vidage .sql, sortie par Local.
Une liste écrite de tout ce qui n’existe que dans le tableau de bord Flywheel, avec son remplacement cPanel nommé.
Une copie fonctionnelle sur cPanel, testée sur le vrai nom de domaine avant qu’un seul enregistrement DNS ne bouge.
Un certificat TLS émis sur la destination et un routage du courriel corrigé, pour que la bascule ne casse ni l’un ni l’autre.
Un retour en arrière exécutable en quelques minutes, et une idée honnête du moment où il cesse d’être bon marché.

Prérequis

Il vous faut trois types d’accès. Côté Flywheel, le tableau de bord et les identifiants SFTP affichés sur la page du site. Le SFTP est le transfert de fichiers sécurisé, et c’est l’accès sur lequel vous pouvez compter, parce que le shell ne fait pas partie de tous les forfaits. Sur votre poste, installez Local, l’application gratuite de Flywheel qui fait tourner des sites WordPress sur un portable. Sur la destination, un compte cPanel avec SSH activé, une base de données MySQL et son utilisateur, et wp sur la machine. Ce dernier, c’est WP-CLI, la ligne de commande officielle de WordPress.

Répondez à six questions pendant que le site est encore en ligne et que vous avez encore le tableau de bord.

Quelle version de PHP le site utilise-t-il ? Alignez la destination dans le MultiPHP Manager de cPanel avant d’importer quoi que ce soit. Du code écrit pour PHP 8.2 déposé sur un compte réglé à 7.4 échoue d’une façon qui ressemble à des fichiers corrompus.
Votre forfait vous donne-t-il un accès SSH ? Sinon, toutes les commandes ci-dessous s’exécutent dans le shell de Local ou sur cPanel. La copie des fichiers devient alors un téléversement depuis votre poste.
Quelle est la taille de la base de données ? Dans le shell de Local, wp db size --tables --size_format=mb l’affiche table par table. Au-delà de quelques centaines de mégaoctets, la méthode d’import et la durée du gel changent tous les deux.
Quelles règles de redirection sont configurées dans le tableau de bord ? Elles s’appliquent au-dessus de WordPress, elles ne sont pas dans le .htaccess, et elles disparaissent le jour où vous fermez le compte. Recopiez la liste dans un fichier texte dès maintenant.
D’où part le courriel ? Flywheel n’héberge aucune boîte, donc vos enregistrements MX pointent déjà ailleurs et le site expédie par SMTP. Ces deux faits changent dès que le domaine arrive sur cPanel.
Quelles extensions Flywheel bloquait-il ? Flywheel interdit les extensions de cache, de sauvegarde et certaines extensions de sécurité, parce que la plateforme couvre ces couches. Rien sur cPanel n’applique cette liste.

Abaissez ensuite le TTL des enregistrements A et AAAA à 300 secondes, au moins 24 heures à l’avance. Le TTL est la durée pendant laquelle les résolveurs gardent une réponse en mémoire, et ce seul changement transforme une mauvaise bascule en un retour en arrière de cinq minutes.

Comment ça marche

Flywheel vous remet WordPress, pas la machinerie qui l’entoure. La sortie la plus propre passe par l’onglet Connect de Local, qui rapatrie le site entier sur votre poste sous forme d’installation fonctionnelle. L’export de Local écrit ensuite un .zip avec les fichiers sous app/public/ et un vidage de base sous app/sql/, exactement la forme qu’attend un compte cPanel.

Schéma de flux montrant un site Flywheel exporté par Local ou par une sauvegarde du tableau de bord vers une archive portable de fichiers et de vidage de base, puis téléversée vers un compte cPanel

Ce chemin a un effet de bord. Local sert le site sur un nom d’hôte qui se termine par .local. Une récupération suivie d’un export laisse donc trois noms d’hôtes dans la base : le domaine en ligne, le nom d’hôte temporaire de Flywheel et celui de Local. L’étape 8 remplace les trois. Si vous téléchargez plutôt une sauvegarde du tableau de bord, il n’y en a que deux à remplacer.

Seule une des trois colonnes ci-dessous arrive dans cette archive.

Carte en trois colonnes classant les composants d'un site Flywheel selon ce qui suit l'export, ce qui n'existe que dans le tableau de bord Flywheel et ce qui n'a aucun équivalent sur cPanel

Le cache pleine page. Flywheel sert la majorité du trafic anonyme depuis un cache pleine page placé devant PHP, qu’ils appellent FlyCache. Sur cPanel, cette couche n’existe pas tant que vous ne la construisez pas. Un thème qui paraissait rapide sur Flywheel était mesuré avec PHP largement contourné, et cette vitesse appartenait à la plateforme plutôt qu’au code.

Les règles de redirection. Les règles configurées dans le tableau de bord sont stockées dans le tableau de bord. Une copie de fichiers n’en garde aucune trace, alors la migration semble impeccable, puis de vieilles URL se mettent à répondre 404 aux moteurs de recherche et aux signets.

wp-config.php. Flywheel considère ce fichier comme le sien, donc les constantes que vous y ajoutez ne survivent pas forcément à un changement de plateforme. Ne le recopiez pas. Écrivez-en un neuf sur cPanel avec vos identifiants et de nouveaux sels de sécurité, puis reportez uniquement les constantes que vous reconnaissez.

Le certificat. Flywheel émet et renouvelle le SSL depuis le tableau de bord, rattaché à son infrastructure, donc il ne vous suit pas. Sur cPanel vous avez AutoSSL, le service de certificats gratuits de cPanel, qui doit valider le contrôle du domaine avant d’émettre quoi que ce soit.

Deux points plus petits complètent l’inventaire. L’environnement de test de Flywheel est une fonction de la plateforme, avec un envoi en un clic, donc un sous-domaine de test et une procédure de promotion deviennent les vôtres à définir. Ses sauvegardes nocturnes sont un service de la plateforme, alors l’outillage de sauvegarde sur cPanel devient une décision. La même forme revient dans le guide WP Engine.

Pas à pas

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

Recopiez le tableau de bord avant de toucher à quoi que ce soit. Dans un fichier texte, notez la liste complète des redirections et le nom d’hôte temporaire exact. Ajoutez chaque domaine et sous-domaine que le site sert, plus la version de PHP. Cette étape ne produit rien à vérifier, et c’est celle que les gens sautent.
Récupérez le site dans Local. Ouvrez l’onglet Connect, connectez-vous avec votre compte Flywheel, puis rapatriez le site. Ouvrez ensuite le shell du site depuis Local et faites l’inventaire :
```
wp --info
wp core verify-checksums
ls -la wp-content/mu-plugins/
ls -l wp-content/object-cache.php wp-content/advanced-cache.php
```
wp --info affiche le binaire PHP, la version de PHP et le chemin du wp-config.php trouvé. verify-checksums doit afficher Success: WordPress installs verify against checksums., et tout ce qu’il signale est un fichier du noyau modifié que vous devez expliquer. La liste de mu-plugins/ montre les extensions obligatoires, qui se chargent à chaque requête et n’apparaissent jamais dans l’écran des extensions. Un No such file or directory sur la dernière ligne est une bonne réponse.
Exportez une archive que vous contrôlez. Faites un clic droit sur le site dans Local, choisissez Export, puis vérifiez ce que vous tenez :
```
unzip -l ~/Downloads/sitename.zip | head -20
```
Vous voulez des chemins sous app/public/ et un fichier .sql sous app/sql/. Prenez aussi votre propre vidage, depuis le shell de Local :
```
wp db export flywheel-bulk.sql --add-drop-table --default-character-set=utf8mb4
tail -3 flywheel-bulk.sql
```
Attendez-vous à Success: Exported to 'flywheel-bulk.sql'. La fin du fichier doit tomber sur une instruction complète, jamais au milieu d’un INSERT. Un vidage tronqué s’importe sans se plaindre et perd la fin de votre plus grosse table.
Téléversez les fichiers vers cPanel. Sans shell chez Flywheel, la copie part de votre poste. Décompressez l’export, puis poussez le contenu de app/public/ :
```
rsync -avz --exclude 'wp-content/cache' app/public/ CPUSER@cpanel.example.com:public_html/
du -sh ~/public_html
```
rsync se termine par un résumé sent … received … bytes/sec et une taille totale proche de ce que le site occupait sur Flywheel. du doit confirmer.
Créez la base et importez à taille réelle. Créez la base et l’utilisateur avec l’assistant MySQL de cPanel, et réglez la version de PHP sur celle de l’étape 1. Importez dans screen ou tmux pour qu’une connexion coupée n’interrompe pas l’opération :
```
mysql --max-allowed-packet=512M --default-character-set=utf8mb4 -u DBUSER -p DBNAME < flywheel-bulk.sql
mysql -u DBUSER -p -e 'SELECT COUNT(*) FROM information_schema.tables WHERE table_schema="DBNAME";'
```
Un import propre n’affiche rien du tout. Le nombre de tables doit correspondre à ce que la même requête renvoie dans le shell de Local.
Écrivez un wp-config.php neuf. Partez du modèle fourni par WordPress, collez-y les identifiants cPanel, générez de nouveaux sels et n’ajoutez que les constantes que vous reconnaissez. Relisez ensuite ce que vous avez écrit :
```
grep -n 'DB_NAME\|DB_HOST\|WP_CACHE\|WP_HOME\|WP_SITEURL' ~/public_html/wp-config.php
```
Vous voulez vos propres DB_NAME et DB_HOST, plus WP_CACHE à false tant que vous n’avez pas choisi d’extension de cache. Un WP_HOME ou un WP_SITEURL qui nomme encore un hôte Flywheel signifie que vous avez recopié le fichier au lieu d’en écrire un.
Mettez de côté les résidus de la plateforme. Déplacez plutôt que supprimer, pour pouvoir encore les relire :
```
mv ~/public_html/wp-content/object-cache.php ~/object-cache.php.bak
mv ~/public_html/wp-content/advanced-cache.php ~/advanced-cache.php.bak
ls -la ~/public_html/wp-content/mu-plugins/
```
Un No such file or directory sur l’un ou l’autre veut dire qu’il n’a jamais été là, et c’est très bien. La liste finale ne doit montrer que des extensions obligatoires écrites par vous ou vos développeurs.
Remplacez chaque nom d’hôte, à blanc d’abord. Reprenez le nom d’hôte temporaire de Flywheel mot pour mot depuis vos notes de l’étape 1 :
```
wp search-replace 'sitename.flywheelsites.com' 'example.com' --all-tables-with-prefix --dry-run --report-changed-only
```
Lisez le tableau de comptes et la ligne finale Success: N replacements to be made, puis lancez pour de vrai :
```
wp search-replace 'sitename.flywheelsites.com' 'example.com' --all-tables-with-prefix --precise
```
--all-tables-with-prefix attrape les tables qu’une extension a créées sous votre préfixe et que le balayage par défaut saute. --precise force le traitement des données sérialisées côté PHP, et c’est pour cette raison qu’un UPDATE écrit à la main les corrompt. La référence WP-CLI search-replace documente chaque option. Répétez la paire pour le nom d’hôte Local, et pour http:// vers https:// si l’ancien site était mixte.
Rebâtissez les redirections. Traduisez votre liste de l’étape 1 en règles .htaccess ou en extension de redirection, puis comptez ce qui a atterri :
```
grep -c 'Redirect\|RewriteRule' ~/public_html/.htaccess
```
Le compte doit être au moins égal au nombre de règles recopiées. Testez chacune avant la bascule, pas après.
Installez la couche de cache qui vous revient. Commencez par savoir ce que tourne le serveur :
```
curl -sI http://127.0.0.1/ | grep -i '^server:'
```
Server: LiteSpeed veut dire installer LiteSpeed Cache. Server: Apache veut dire une extension de cache pleine page plus un CDN. Dans les deux cas, excluez les pages panier, commande et compte si le site vend quelque chose. Un cache qui garde une page panier peut remettre à un client le panier d’un autre.
Faites émettre le certificat avant la bascule. AutoSSL peut valider de deux façons. Par HTTP, ce qui ne peut pas réussir tant que le domaine ne résout pas vers cPanel. Ou par DNS, avec un enregistrement TXT que vous ajoutez pendant que Flywheel sert encore le trafic. Prenez la méthode DNS pour avoir le certificat prêt d’avance. Le portail de documentation de cPanel couvre les options. Vérifiez ensuite la couverture :
```
uapi SSL installed_hosts | grep -i domains
```
Chaque nom d’hôte doit apparaître : le domaine racine, www et chaque sous-domaine. Un certificat qui couvre example.com mais pas www.example.com alerte la moitié de vos visiteurs.
Corrigez le routage du courriel, puis gelez, synchronisez et basculez. cPanel suppose par défaut qu’il est le serveur de courriel de tout domaine hébergé sur le compte, ce qui avalerait le courrier destiné à votre vrai fournisseur :
```
dig +short MX example.com
```
Si la commande renvoie un fournisseur externe, réglez le domaine sur « serveur de messagerie distant » dans l’écran Routage du courriel de cPanel. Ouvrez maintenant la fenêtre en lecture seule. Mettez le site Flywheel en mode maintenance pour qu’il arrête de prendre commandes, commentaires et formulaires. Récupérez de nouveau dans Local, réimportez la base, relancez les remplacements de l’étape 8, puis relancez le rsync de l’étape 4, qui ne devrait presque plus rien transférer. Changez l’enregistrement A seulement à ce moment-là. Pendant la propagation, les deux hébergeurs répondent, et c’est précisément pour ça que le gel existe.
Videz les caches et les règles de réécriture sur le nouvel hôte.
```
wp cache flush
wp rewrite flush --hard
```
Attendez-vous à Success: The cache was flushed. et Success: Rewrite rules flushed. La forme --hard régénère les règles dans le .htaccess, pas seulement dans la base.

Vérifier que ça fonctionne

Passez ce balayage environ une heure après la bascule, une fois le DNS stabilisé :

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

siteurl et home doivent tous deux renvoyer votre domaine final, jamais un nom d’hôte Flywheel ou .local. wp db check doit répondre OK pour chaque table.

Regardez ensuite de l’extérieur. Mettez vos vingt URL les plus visitées dans un fichier et passez-les en revue :

while read u; do printf '%s ' "$u"; curl -o /dev/null -s -w '%{http_code}\n' "$u"; done < top-urls.txt

Chaque ligne doit afficher 200, ou 301 pour les URL que vous redirigez volontairement. Un 404 dans cette liste est presque toujours une règle de redirection du tableau de bord que vous n’avez pas rebâtie. Cherchez ensuite ce qui pointe encore vers l’ancien hôte :

curl -s https://example.com/ | grep -o 'src="http://[^"]*' | head
dig +short example.com @1.1.1.1

La première commande ne doit rien afficher. La seconde doit renvoyer l’adresse IP cPanel depuis un résolveur public. Terminez par du vrai courriel : une réinitialisation de mot de passe, un formulaire de contact et une confirmation de commande, pas un seul des trois. Surveillez ensuite pendant soixante-douze heures, parce que c’est là que sortent les problèmes qu’un test rapide n’atteint pas.

Le retour en arrière

Gardez le site Flywheel intact et payé jusqu’à la fin de cette période de surveillance. L’annuler est le seul geste irréversible ici, parce que le tableau de bord part avec. Si la vérification tourne mal, remettez l’enregistrement A ; avec un TTL de 300 secondes, la plupart des résolveurs suivent en quelques minutes.

Ce retour en arrière n’est gratuit que tant que la copie cPanel n’a reçu aucune écriture. La première vraie commande, le premier commentaire ou le premier formulaire sur le nouvel hôte vous coûte ces lignes si vous revenez. C’est cette frontière le point de non-retour, pas le changement DNS.

Dépannage

De vieilles URL répondent 404 et rien dans le site ne l’explique. Ce sont les règles de redirection du tableau de bord, appliquées au-dessus de WordPress, et aucune copie de fichiers ne les a enregistrées. Si le compte Flywheel est encore ouvert, allez les relire dans le panneau. S’il est fermé, reconstruisez-les depuis vos journaux serveur et le rapport de couverture de la Search Console.

Tout pointe encore vers une adresse .local. Le nom d’hôte de Local a été écrit dans la base pendant la récupération et l’étape 8 l’a manqué. Remplacez-le de la même façon, à blanc d’abord :

wp search-replace 'sitename.local' 'example.com' --all-tables-with-prefix --dry-run --report-changed-only

Les téléversements répondent 403, ou WordPress n’arrive pas à écrire dans wp-content. Le rsync a tourné en root, donc chaque fichier appartient à root au lieu de l’utilisateur du compte cPanel. Corrigez propriétaire et permissions ensemble :

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

Les pages chargent mais paraissent bien plus lentes que sur Flywheel. FlyCache répondait aux requêtes anonymes avant que PHP ne démarre, et rien sur cPanel ne fait ça tant que vous n’installez pas d’extension de cache. Faites l’étape 10 et remesurez avant de chasser une extension fautive.

L’import s’arrête sur une collation inconnue. Un vidage venu d’un MariaDB plus récent porte une collation que votre destination ne connaît pas. Réécrivez-le avant d’importer, puis vérifiez avec le compte de tables de l’étape 5 :

sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g' flywheel-bulk.sql

Quand cette approche n’est pas la bonne

Soyez honnête sur la raison du départ. Si le site paraît lent et que personne ne veut porter la performance, cPanel plus une extension de cache est un recul. Flywheel faisait tourner le cache pleine page, les sauvegardes, le certificat et le réglage de PHP. Sur un compte cPanel non infogéré, chacun de ces points devient votre travail.

Si la seule raison est la facture, chiffrez d’abord le remplacement. L’extension de cache, un CDN, l’outillage de sauvegarde, la surveillance et les heures que quelqu’un y consacre montent plus vite que la facture ne le laisse croire. Pour un site vitrine, l’échange fonctionne souvent. Pour une boutique qui encaisse, sans personne assigné à ces tâches, les frais de plateforme achetaient quelque chose de réel.

Si la raison est le contrôle, le déplacement se justifie et la carte en trois colonnes ci-dessus est votre périmètre de travail. Des boîtes courriel sur le même compte, une extension que Flywheel interdit, une extension PHP qu’ils n’offrent pas, ou plusieurs applications côte à côte sont autant de choses que cPanel fait mieux. Si vous cherchez plutôt une autre plateforme infogérée, comparez d’abord avec le guide Kinsta.

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.