WHM Transfer Tool copie des comptes et propose Live Transfer pour réduire l’interruption. Sa documentation précise aussi des exceptions : préparez donc une recette par compte, plutôt que de considérer la fin de copie comme une preuve de migration complète.
1. Préparer la destination et le retour arrière
Inventoriez comptes, bases, boîtes mail, DNS externes, certificats, versions PHP, extensions, cron et réglages personnalisés. Vérifiez les licences, l’espace disponible, les versions compatibles et la résolution du hostname de destination.
Conservez une sauvegarde hors des deux serveurs. Préparez la nouvelle IP et son reverse DNS si elle envoie du courrier. Abaissez les TTL suffisamment avant la bascule pour que les anciennes durées aient expiré ; un DNS externe reste à modifier chez son opérateur.
Définissez le moment où les écritures seront arrêtées et la personne qui autorise leur reprise. Un retour DNS vers l’ancien serveur après de nouvelles commandes sur le nouveau exige une réconciliation des données : ce n’est pas un bouton d’annulation.
2. Transférer avec un compte pilote
Depuis le WHM de destination, ouvrez Transfer Tool, renseignez la source et l’authentification administrative, récupérez la liste puis sélectionnez un compte pilote. Examinez les options DNS et Live Transfer avant lancement : elles peuvent modifier le routage et l’état du compte source.
Vérifiez le résultat de restauration et testez le pilote avant de poursuivre par groupes. Évitez de lancer une mise à jour système pendant le transfert. Live Transfer peut relayer des services et recopier les boîtes mail, mais ne doit pas être assimilé à une réplication générale des écritures applicatives.
Pour une boutique, prévoyez une maintenance contrôlée sur la source avant la copie finale cohérente de sa base et de ses fichiers modifiables. Si une copie pilote a précédé cette maintenance, actualisez ces données avec une méthode validée pour l’application avant réouverture. Désignez un seul serveur exécutant les cron.
Contrôlez les certificats restaurés et leurs noms. Réexaminez aussi les réglages PHP-FPM : la documentation signale une restauration manuelle possible depuis les fichiers transférés. Prévoyez la réinscription MFA des utilisateurs, qui n’est pas transférée.
3. Valider chaque service avant retrait
Testez le nouvel hôte avant la bascule DNS publique. Exemple avec une adresse réservée à la documentation :
curl --resolve example.com:443:192.0.2.20 \ -I https://example.com/Remplacez domaine et IP. Ce contrôle teste HTTPS avec le bon nom ; il ne valide pas le panier, les données ou les pièces jointes.
Pour chaque compte, vérifiez connexion, lecture et écriture applicatives, contenu récent de la base, envoi et réception mail, accès IMAP, routage MX et réponses A/AAAA. Comparez les derniers objets créés avec votre relevé avant gel.
Basculez les DNS réellement autoritaires et observez erreurs et trafic sur les deux serveurs. Gardez la source accessible pour les mécanismes de transition et le diagnostic. Ne la retirez qu’après validation des comptes, traitement des derniers messages et confirmation qu’aucune écriture utile n’y reste isolée.
Sources : cPanel — Transfer Tool, cPanel — after the transfer.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.