Migrer plusieurs comptes cPanel avec Transfer Tool et une bascule contrôlée

Transfer Tool copie des comptes, mais une migration fiable exige aussi de choisir quand les écritures et le trafic changent de serveur. Sa documentation signale des effets sur DNS, messagerie et réglages PHP-FPM qu’il faut intégrer au plan, avant de lancer un lot.

Intention de recherche : déplacer plusieurs comptes cPanel vers un nouveau WHM avec une interruption limitée et un retour arrière réaliste. Prévoyez un accès administrateur aux deux serveurs et aux DNS autoritatifs ; ne promettez pas une absence totale d’interruption.

1. Préparer la destination et les sauvegardes

Problème et causes possibles

Une copie réussie peut laisser un site inutilisable : extension PHP absente, version SQL incompatible, mauvaises permissions, ancienne adresse IPv6, routage mail incorrect ou données écrites après la copie. Construisez un inventaire par compte : domaines, IP, version PHP, extensions, bases, volumes mail, cron, certificats et dépendances externes.

Dans WHM, comparez EasyApache 4 et MultiPHP Manager sur les deux serveurs. Vérifiez capacité disque, quotas, nom d’hôte, accès réseau et versions prises en charge. Ne transposez pas automatiquement les réglages d’un ancien serveur moins puissant.

mysql --version décrit le client ; confirmez aussi la version du serveur SQL dans sa console avec SELECT VERSION();. Notez les chemins /home/cpuser/, /home/cpuser/mail/ et les configurations applicatives de connexion aux bases. Ne copiez pas un répertoire MySQL actif comme s’il s’agissait de simples fichiers.

Sauvegarde avant modification

Vérifiez une sauvegarde complète de chaque compte dans WHM, Backup Configuration/Backup Restoration, stockée hors de la source et testée sur un compte pilote. Exportez les zones chez leur fournisseur réel et enregistrez les réglages de messagerie. Conservez les configurations PHP-FPM sous /var/cpanel/userdata/cpuser/.

Réduisez les TTL concernés avant la fenêtre, puis attendez l’ancien TTL. Cette attente concerne les réponses déjà en cache ; un TTL faible n’empêche ni les caches applicatifs ni les sessions persistantes.

2. Répéter le transfert puis exécuter la bascule

1. Pilote isolé : dans le WHM de destination, Transfers, Transfer Tool, utilisez un compte représentatif sans données critiques. Examinez toutes les options avant Copy. Live Transfer peut rediriger le trafic et modifier la source : désactivez-le pour une répétition qui doit rester isolée.
2. Maîtrise DNS : vérifiez le cluster et l’autorité DNS. Si Update DNS Zone est désactivé pour protéger la production, préparez manuellement les zones et le routage mail de destination : l’outil ne les configure pas dans ce mode. Un cluster synchronisé peut propager des changements ; ne supposez pas qu’une copie est invisible.
3. Contrôles avant bascule : comparez PHP et extensions, fichiers, base, tâches planifiées et permissions. Les réglages PHP-FPM ne sont pas appliqués automatiquement : examinez les fichiers .php-fpm.transferred et recréez les paramètres nécessaires dans MultiPHP Manager.
4. Tester la destination sans changer le DNS public :

Remplacez l’IP d’exemple. --resolve conserve le nom HTTP et SNI en forçant la destination. N’ajoutez pas -k pour cacher un problème TLS. Testez aussi connexion, formulaires et paiements en mode test, sans déclencher de vraies opérations. 5. Synchronisation finale : annoncez une courte maintenance pour les sites avec écritures. Stoppez producteurs de jobs et cron applicatifs à la source, puis confirmez qu’aucune écriture n’y arrive. Réalisez le transfert final du compte depuis cet état figé. Si la destination contient la répétition, sauvegardez-la et examinez explicitement les options de remplacement : ne lancez pas un écrasement aveugle. 6. E-mails et DNS : pour une bascule finale éligible, Live Transfer prévoit notamment une nouvelle copie des boîtes et un routage vers la destination. Cela ne garantit pas la synchronisation continue de toutes les données applicatives. Contrôlez les enregistrements publics chez le fournisseur externe, A/AAAA, MX, SPF, DKIM, DMARC et DNSSEC. Vérifiez les files mail restantes avant de retirer la source.

Retour arrière avec données cohérentes

Avant toute écriture sur la destination, revenir au routage et DNS enregistrés peut suffire après vérification. Après de nouvelles commandes ou des e-mails reçus, gelez les écritures et réconciliez les données vers la source avant de revenir. Avec Live Transfer, le désuspensionnement du compte source désactive le proxy de services : ne l’effectuez qu’après cette décision. Gardez un seul système autorisé à écrire.

3. Vérification finale

Contrôlez chaque compte : pages dynamiques, TLS, authentification, envoi/réception mail, quotas, cron et sauvegarde de destination. Vérifiez la résolution externe et l’absence de trafic résiduel utile sur l’ancien serveur. Réactivez les tâches une seule fois, sur la destination validée, et reconfigurez la MFA des comptes transférés.

Erreurs courantes

Éteindre la source dès la bascule DNS peut perdre des mails retardés. Lancer upcp pendant le transfert ou redémarrer les services compromet l’opération. Une réponse HTTP 200 ne vérifie pas la cohérence métier.

Recommandations en production

Migrez par petits lots, avec critères d’arrêt, propriétaire de la bascule et fenêtre de rollback. Conservez la source le temps de vérifier caches, files et sauvegardes ; sa suppression est une décision ultérieure.

Sources : cPanel, Transfer Tool, déroulement du transfert.