Comment déplacer tous les comptes cPanel d’un serveur à un autre

La migration de tous les comptes cPanel entre serveurs est le processus de transfert de chaque domaine hébergé, ses fichiers, bases de données MySQL, comptes e-mail, zones DNS, certificats SSL et tâches cron d’une instance WHM source vers une instance WHM de destination — généralement en utilisant l’outil intégré WHM Transfer Tool via une connexion SSH authentifiée. Lorsqu’il est exécuté correctement, ce processus ne nécessite aucune copie manuelle de fichiers et préserve intactes toutes les métadonnées des comptes.

Ce guide couvre le flux de travail complet de migration au niveau production : vérifications préalables, configuration du Transfer Tool, stratégie de basculement DNS, validation post-migration et nettoyage — y compris les cas particuliers qui provoquent des échecs silencieux dans les environnements réels.

Prérequis et liste de contrôle pré-migration

Négliger la préparation est la cause la plus fréquente d’échecs ou de migrations incomplètes de cPanel. Avant de toucher l’un ou l’autre serveur, vérifiez chaque élément ci-dessous.

Accès root sur les deux serveurs. Le WHM Transfer Tool s’authentifie sur le serveur source via SSH en tant que root. Si le serveur source a PermitRootLogin no dans /etc/ssh/sshd_config, vous devez soit l’activer temporairement, soit préconfigurer l’authentification SSH par clé pour root.

Versions cPanel/WHM compatibles. cPanel peut transférer des comptes de versions plus anciennes vers des versions plus récentes, mais pas dans le sens inverse. Une destination exécutant cPanel 110 peut récupérer depuis une source exécutant cPanel 98, mais l’inverse échouera. Vérifiez les versions dans WHM sous Server Information ou exécutez :

cat /usr/local/cpanel/version

Versions PHP et MySQL correspondantes ou compatibles. Si la source exécute PHP 7.4 et MySQL 5.7 tandis que la destination exécute PHP 8.2 et MySQL 8.0, les applications peuvent ne plus fonctionner après le transfert même si les fichiers sont copiés correctement. Auditez les versions PHP installées et les gestionnaires par défaut sur les deux serveurs avant de procéder.

Espace disque suffisant sur la destination. Le Transfer Tool nécessite un espace libre au moins égal à la taille compressée totale de tous les comptes transférés, plus une marge pour l’extraction. Exécutez df -h sur la destination et comparez avec l’utilisation totale du disque des comptes visible dans la vue List Accounts de WHM sur la source.

Règles de pare-feu autorisant SSH entre les serveurs. Le serveur de destination initie une connexion SSH sortante vers la source. Assurez-vous que le port 22 (ou le port SSH personnalisé) est ouvert sur le pare-feu du serveur source pour l’adresse IP de la destination.

Sauvegardes complètes des comptes sur la source. Générez une sauvegarde cPanel complète pour chaque compte avant de commencer. C’est votre point de récupération si le transfert corrompt ou copie partiellement un compte.

/scripts/pkgacct username /backup/directory

Si vous exécutez votre nouvel environnement sur un plan VPS Hosting, confirmez que votre VPS a cPanel/WHM déjà sous licence et installé avant de procéder. Une nouvelle installation cPanel nécessite une licence valide liée à l’adresse IP du serveur.

Étape 1 : Installer et configurer cPanel/WHM sur le serveur de destination

Si cPanel n’est pas encore installé sur la destination, exécutez l’installateur officiel en tant que root. Ce processus prend 20 à 45 minutes selon le matériel :

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Une fois l’installation terminée, accédez à WHM sur https://your-server-ip:2087 et complétez l’assistant de configuration initiale. Portez une attention particulière à :

• Nom d’hôte : Définissez un nom de domaine pleinement qualifié (FQDN) qui se résout vers l’IP du serveur. Un nom d’hôte non résolvable provoque des échecs de livraison de courrier après la migration.
• Serveurs de noms : Configurez les noms d’hôte de vos serveurs de noms et leurs adresses IP si vous prévoyez d’héberger le DNS sur le nouveau serveur.
• Gestionnaires PHP : Installez les mêmes versions PHP disponibles sur le serveur source en utilisant WHM > MultiPHP Manager pour éviter les problèmes de compatibilité des applications.
• Version MySQL/MariaDB : Faites correspondre la version du moteur de base de données du serveur source dans la mesure du possible, ou testez la compatibilité des applications avec la version plus récente avant de migrer les comptes de production.

Pour les équipes gérant plusieurs environnements clients, un VPS avec cPanel fournit un environnement préconfiguré qui élimine entièrement la phase d’installation manuelle.

Étape 2 : Configurer le WHM Transfer Tool

Le WHM Transfer Tool est la méthode de référence pour la migration en masse de comptes. Il gère l’empaquetage, le transfert, l’extraction et la création de compte de manière atomique pour chaque compte.

2.1 Accéder au Transfer Tool

Sur le serveur de destination, connectez-vous à WHM et naviguez vers :

WHM > Transfers > Transfer Tool

C’est un point critique qui déroute de nombreux administrateurs : le Transfer Tool est toujours exécuté depuis le serveur de destination qui récupère les comptes depuis la source — et non l’inverse.

2.2 Se connecter au serveur source

Saisissez les informations de connexion suivantes :

• Adresse du serveur distant : Adresse IP ou nom d’hôte du serveur source
• Port SSH distant : La valeur par défaut est 22 ; utilisez le port réel s’il a été modifié (vérifiez /etc/ssh/sshd_config sur la source pour la directive Port)
• Méthode d’authentification : Mot de passe root ou clé SSH (l’authentification par clé est fortement préférée pour la sécurité et la fiabilité)

Pour utiliser l’authentification par clé SSH, copiez la clé publique root du serveur de destination vers la source :

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Une fois connecté, le Transfer Tool interroge le serveur source et retourne une liste de tous les comptes cPanel, packages et configurations de revendeurs.

2.3 Sélectionner les comptes et la portée du transfert

Vous pouvez sélectionner tous les comptes ou un sous-ensemble. Au-delà des comptes individuels, le Transfer Tool propose également :

• Packages : Transférer les définitions des plans d’hébergement afin que les comptes conservent leurs allocations de ressources
• Zones DNS : Copier tous les fichiers de zone, ce qui est essentiel si le nouveau serveur agira comme serveur de noms faisant autorité
• Privilèges revendeur et ACL : Préserver les configurations des comptes revendeurs et leurs permissions associées

2.4 Configurer les options de transfert

Deux paramètres ont ici un impact opérationnel significatif :

Express Transfer automatise le basculement DNS en mettant à jour les zones DNS sur le serveur source pour pointer vers l’IP de la destination immédiatement après la copie de chaque compte. Cela minimise la fenêtre pendant laquelle un domaine se résout vers l’ancien serveur. Utilisez ceci uniquement si la destination est prête à servir le trafic immédiatement et que vous avez confirmé que toutes les applications sont fonctionnelles.

Routage du courrier : Définissez-le sur Automatique sauf si vous avez une raison spécifique de forcer le routage local ou distant. Un routage de courrier incorrect est l’une des principales causes d’échecs de livraison d’e-mails après la migration.

2.5 Lancer le transfert

Cliquez sur Copy pour démarrer le processus. WHM va :

1. Se connecter en SSH au serveur source
2. Exécuter pkgacct pour créer une archive compressée de chaque compte
3. Transférer l’archive vers la destination via SSH/SCP
4. Exécuter restorepkg sur la destination pour extraire et créer le compte
5. Enregistrer le résultat pour chaque compte

Surveillez attentivement le journal de transfert en direct. Les erreurs pour des comptes individuels n’arrêtent pas le processus global — un compte peut échouer silencieusement pendant que d’autres réussissent. Examinez le journal complet après la fin du transfert et relancez les comptes échoués individuellement.

La durée du transfert dépend du volume total de données et de la bande passante entre les serveurs. Un serveur avec 50 GB de données de comptes sur une liaison 1 Gbps se termine généralement en moins de 30 minutes. Sur une liaison 100 Mbps, prévoyez 60 à 90 minutes.

Étape 3 : Stratégie de basculement DNS

La gestion DNS est l’endroit où les migrations créent le plus souvent des interruptions prolongées. Comprendre les mécanismes de propagation est essentiel pour minimiser l’impact sur les utilisateurs.

3.1 Réduire le TTL avant la migration

Idéalement, 24 à 48 heures avant la migration, réduisez le TTL sur tous les enregistrements A des domaines hébergés à 300 secondes (5 minutes). Cela garantit qu’une fois les enregistrements DNS mis à jour, le changement se propage globalement en quelques minutes plutôt qu’en heures. Si vous ne l’avez pas fait à l’avance, vous devez tenir compte de la valeur TTL existante comme fenêtre de propagation maximale.

3.2 Mettre à jour les zones DNS

Si le nouveau serveur est le serveur de noms faisant autorité pour les domaines, mettez à jour les enregistrements A dans chaque fichier de zone via WHM > DNS Functions > Edit DNS Zone, en changeant l’IP de l’adresse de l’ancien serveur vers celle du nouveau.

Si les domaines utilisent un fournisseur DNS externe ou le DNS du registrar, connectez-vous à chaque registrar ou panneau de gestion DNS et mettez à jour les enregistrements A manuellement. Pour les mises à jour en masse sur de nombreux domaines, la plupart des registrars offrent un accès API ou une importation CSV.

3.3 Mettre à jour les enregistrements glue des serveurs de noms

Si vous migrez également des serveurs de noms (par ex., ns1.yourdomain.com), vous devez mettre à jour les enregistrements glue chez le registrar de domaine — pas seulement le fichier de zone. Les enregistrements glue sont des mappages d’adresses IP pour les serveurs de noms enregistrés sous le même domaine qu’ils servent. Ne pas mettre à jour les enregistrements glue est une omission courante qui provoque un échec complet de la résolution DNS pour tous les domaines hébergés.

3.4 Vérifier la propagation

Utilisez dig pour vérifier la résolution depuis plusieurs emplacements géographiques :

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Croisez avec un vérificateur de propagation en ligne. La propagation mondiale complète se termine généralement dans un délai de 1 à 4 heures lorsque le TTL a été réduit à l’avance, ou jusqu’à 48 heures lorsque le TTL n’a pas été réduit préalablement.

Si vos domaines sont enregistrés via Domain Registration, les mises à jour des serveurs de noms peuvent être gérées directement depuis le même panneau de contrôle, simplifiant le processus de basculement.

Étape 4 : Validation post-migration

Ne déclarez jamais une migration terminée en vous basant uniquement sur le journal de succès du Transfer Tool. Validez chaque couche de la pile indépendamment.

4.1 Fonctionnalité des applications web

Accédez à chaque domaine transféré directement par IP en utilisant une substitution du fichier hosts (pour contourner la propagation DNS) et vérifiez que l’application se charge correctement :

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Vérifiez les erreurs de connexion à la base de données, les chemins de fichiers manquants et les configurations d’application défectueuses. Les sites WordPress échouent souvent si les identifiants de base de données wp-config.php référencent localhost mais que le chemin du socket MySQL diffère entre les serveurs.

4.2 Intégrité des bases de données

Connectez-vous à cPanel pour chaque compte et vérifiez que les bases de données existent et sont accessibles. Pour les bases de données critiques, exécutez une vérification d’intégrité :

mysqlcheck -u root -p --all-databases --check

4.3 Fonctionnalité des e-mails

Testez les e-mails entrants et sortants pour chaque compte. Vérifiez que les enregistrements MX se résolvent correctement et que le serveur de messagerie accepte les connexions sur les ports 25, 465 et 587. Vérifiez /var/log/exim_mainlog pour les erreurs de livraison :

tail -f /var/log/exim_mainlog

Pour les entreprises disposant d’une infrastructure de messagerie dédiée, Email Hosting fournit des environnements de messagerie isolés qui ne sont pas affectés par les migrations de serveurs web.

4.4 Vérification des certificats SSL

Confirmez que les certificats SSL ont été transférés correctement et sont actifs. Dans WHM, naviguez vers SSL/TLS > Manage SSL Hosts et vérifiez que chaque domaine possède un certificat valide et non expiré. AutoSSL devrait automatiquement réémettre les certificats Let’s Encrypt pour ceux qui n’ont pas pu être transférés, mais déclenchez-le manuellement pour éviter d’attendre l’exécution planifiée :

/usr/local/cpanel/bin/autossl_check --all

Si vous gérez les certificats indépendamment, les SSL Certificates peuvent être installés directement sur le nouveau serveur sans dépendance au processus de transfert.

4.5 Tâches cron et tâches planifiées

Les tâches cron sont transférées dans le cadre du package de compte, mais vérifiez-les dans cPanel > Cron Jobs pour chaque compte. Portez une attention particulière aux tâches cron qui référencent des chemins de fichiers absolus ou des variables d’environnement spécifiques au serveur qui peuvent différer sur le nouveau serveur.

Étape 5 : Nettoyage et renforcement post-migration

5.1 Suspendre les comptes sur le serveur source

Une fois que le DNS a propagé et que la validation est terminée, suspendez tous les comptes sur le serveur source via WHM > List Accounts > Suspend. Ne les supprimez pas encore. La suspension empêche l’écriture de nouvelles données sur la source tout en la maintenant disponible comme solution de repli si un problème critique survient après la migration.

5.2 Sauvegarde post-migration

Créez une sauvegarde complète de tous les comptes sur le nouveau serveur immédiatement après la migration. L’état transféré est votre nouvelle référence :

/scripts/cpbackup --force

Vérifiez que les sauvegardes se terminent avec succès et sont stockées dans un emplacement séparé du serveur lui-même — idéalement une destination de sauvegarde hors serveur configurée dans WHM > Backup Configuration.

5.3 Surveillance des performances

Surveillez l’utilisation des ressources du nouveau serveur pendant 72 heures après la migration. Métriques clés à surveiller :

• Charge CPU moyenne (doit rester en dessous du nombre de cœurs CPU sous charge normale)
• Utilisation de la mémoire et activité du swap
• Temps d’attente I/O disque (un temps d’attente I/O élevé indique des goulots d’étranglement de stockage)
• Journal des requêtes lentes MySQL pour les requêtes qui s’exécutent mal sur le nouveau schéma ou la nouvelle version du moteur

Utilisez top, iostat et vmstat pour la surveillance en temps réel, et consultez le Resource Monitor de cPanel dans WHM pour la consommation de ressources par compte.

5.4 Décommissionner le serveur source

Après une période d’observation minimale de 7 jours sans problèmes signalés, vous pouvez décommissionner le serveur source. Avant de résilier l’ancien serveur, archivez une sauvegarde finale en stockage à froid. Cette archive sert de référence légale et opérationnelle et coûte très peu à conserver.

Migration de comptes cPanel : comparaison des méthodes

Pièges courants et comment les éviter

Échecs silencieux de transfert de comptes. Le Transfer Tool continue le traitement même lorsque des comptes individuels échouent. Lisez toujours le journal de transfert complet — ne supposez pas le succès parce que l’outil s’est terminé sans s’arrêter.

Incompatibilité des privilèges utilisateur MySQL. restorepkg recrée les utilisateurs de base de données, mais si un nom d’utilisateur de base de données dépasse la limite de 32 caractères de MySQL (un problème courant avec les comptes hérités), l’utilisateur est créé avec un nom tronqué et les identifiants de base de données de l’application ne correspondent plus. Auditez les noms d’utilisateurs de base de données longs avant de migrer.

Dépendances de modules Perl et de logiciels personnalisés. Les applications qui reposent sur des modules Perl compilés sur mesure, des packages Python ou des bibliothèques système installés en dehors des chemins gérés par cPanel ne seront pas transférées. Ces dépendances doivent être réinstallées manuellement sur la destination.

Divergences de quota disque. Le système de quota disque de cPanel utilise des quotas au niveau du système de fichiers. Après la migration, les quotas peuvent ne pas refléter avec précision jusqu’à l’exécution du script de recalcul des quotas :

/scripts/fixquotas

Conflits de règles ModSecurity. Si le serveur source avait des règles ModSecurity personnalisées ou une version de jeu de règles différente de celle de la destination, les sites transférés peuvent recevoir des erreurs 403 inattendues. Examinez les journaux ModSecurity sur /usr/local/apache/logs/error_log après la migration.

Lacunes dans les permissions des comptes revendeurs. Les ACL revendeurs et les assignations de packages sont transférées, mais si le WHM de destination a des listes de fonctionnalités différentes configurées, les revendeurs peuvent constater que leurs comptes ont moins de capacités ou des capacités différentes de celles attendues. Auditez les configurations des revendeurs après la migration.

Pour les environnements à fort trafic où la tolérance aux interruptions est quasi nulle, envisagez d’exécuter la migration sur un Dedicated Server avec des ressources dédiées, éliminant le risque de contention de ressources pendant les phases de transfert et de validation.

Matrice de décision technique

Utilisez cette matrice pour déterminer votre approche de migration en fonction des caractéristiques de l’environnement :

FAQ

Puis-je migrer des comptes cPanel sans accès root au serveur source ?

Non. Le WHM Transfer Tool nécessite un accès SSH root au serveur source pour exécuter pkgacct et lire toutes les données des comptes. Si l’accès root n’est pas disponible, la seule alternative est de demander des fichiers de sauvegarde cPanel individuels (archives .tar.gz) à l’administrateur du serveur source et de les restaurer manuellement en utilisant restorepkg sur la destination.

Combien de temps prend une migration complète d’un serveur cPanel ?

Le temps de transfert dépend du volume total de données et de la bande passante réseau entre les serveurs. Un serveur avec 100 GB de données de comptes sur une liaison dédiée 1 Gbps se transfère généralement en 15 à 30 minutes. Sur des connexions partagées ou limitées, les mêmes données peuvent prendre plusieurs heures. La propagation DNS ajoute 1 à 48 heures supplémentaires selon les valeurs TTL.

Les certificats SSL sont-ils transférés automatiquement ?

Les certificats SSL installés via AutoSSL (Let’s Encrypt) ne se transfèrent pas en tant que certificats valides — ils sont réémis par AutoSSL sur le serveur de destination car ils sont liés à l’IP du serveur et au compte. Les certificats achetés commercialement stockés dans cPanel se transfèrent bien dans le cadre du package de compte, mais doivent être vérifiés et réactivés après la migration.

Que se passe-t-il avec les e-mails sur l’ancien serveur pendant la fenêtre de migration ?

Les e-mails livrés à l’ancien serveur pendant la fenêtre de migration sont stockés dans la file d’attente de messagerie et les boîtes aux lettres des utilisateurs de l’ancien serveur. Ils ne se répliquent pas automatiquement vers le nouveau serveur. Pour éviter la perte de courrier, maintenez les services de messagerie de l’ancien serveur en fonctionnement jusqu’à la propagation complète du DNS, ou configurez l’Exim de l’ancien serveur pour relayer les e-mails entrants vers l’IP du nouveau serveur pendant la période de transition.

Le WHM Transfer Tool peut-il migrer des comptes entre différents systèmes d’exploitation (par ex., CentOS vers AlmaLinux) ?

Oui. Le Transfer Tool est agnostique au niveau de la couche applicative — il transfère les données des comptes cPanel, pas les configurations au niveau du système d’exploitation. Les migrations de CentOS 7 vers AlmaLinux 8 ou Rocky Linux 8 sont entièrement prises en charge et constituent le scénario de migration le plus courant suite à la fin de vie de CentOS 7. Vérifiez que toutes les configurations personnalisées au niveau système (politiques SELinux, modules noyau personnalisés, services hors cPanel) sont répliquées manuellement sur la destination.