Migrer un site cPanel vers un VPS sans interruption

Publié le 10 septembre 2026

Pour migrer un site cPanel vers un VPS sans panne surprise, traitez le DNS comme le basculement final, pas comme la première tâche. Préparez le serveur de destination, copiez le compte, testez-le sur la nouvelle adresse IP, réduisez le TTL DNS, puis modifiez les enregistrements uniquement après validation des contrôles de l'application, du courrier et du SSL. Le site reste disponible pendant que le travail se fait en arrière-plan.

Pour le site d'une petite entreprise, un compte d'agence ou une boutique avec des commandes en direct, la migration consiste moins à déplacer des fichiers qu'à préserver le comportement du service. Les versions de PHP, les autorisations de base de données, les tâches cron, le routage des e-mails, les redirections et les règles de pare-feu doivent tous arriver dans un état validé et fonctionnel. Les fichiers sont généralement la partie facile. Ce sont les petits réglages cachés autour d'eux qui donnent des cheveux gris aux migrations.

Avant de migrer un site cPanel vers un VPS

Commencez par dresser un inventaire du compte existant. Notez les noms de domaine et sous-domaines, l'utilisation disque du compte, la version de PHP et ses extensions, la taille des bases de données, les tâches cron, les comptes e-mail, les redirecteurs, les réponses automatiques, les enregistrements DNS, les certificats SSL et tous les services externes qui dépendent de l'adresse IP du serveur. Pour les charges de travail e-commerce et SaaS, identifiez également les rappels de paiement, les listes d'autorisation API, les fournisseurs d'e-mails transactionnels et les workers en arrière-plan.

Vérifiez si le VPS cible dispose d'une marge de capacité suffisante. L'espace disque doit couvrir le compte source, l'archive de migration temporaire, les bases de données, les sauvegardes et la croissance normale. Les besoins en RAM et en CPU dépendent du trafic et de la pile logicielle. Un site vitrine peut fonctionner confortablement sur un VPS modeste ; WooCommerce, Magento, un grand multisite WordPress ou une application très sollicitée nécessitent normalement plus de mémoire et de capacité de base de données.

La destination doit être préparée avant que des données de production ne soient copiées. Définissez le nom d'hôte du serveur, installez et mettez à jour cPanel et WHM si c'est le panneau de contrôle choisi, configurez les serveurs de noms si le VPS hébergera le DNS, et activez un pare-feu avec uniquement les ports nécessaires ouverts. Confirmez que les sauvegardes sont configurées indépendamment du serveur source. Une sauvegarde stockée uniquement sur le VPS est utile, mais ce n'est pas un plan de reprise complet si le VPS lui-même rencontre un problème.

Si vous passez d'un hébergement cPanel mutualisé à un VPS, vérifiez ce qui était auparavant géré pour vous. L'ancien hébergeur gérait peut-être le filtrage des e-mails, le DNS, le renouvellement automatique du SSL, l'analyse anti-malware ou les sauvegardes hors serveur. Sur un VPS géré, ces éléments peuvent être vérifiés et maintenus avec vous. Sur un serveur non géré, ils deviennent votre responsabilité opérationnelle. Aucune des deux approches n'est mauvaise, mais les suppositions coûtent cher.

Réduire le TTL DNS avant le basculement

Environ 24 à 48 heures avant le changement prévu, réduisez le TTL des enregistrements DNS concernés à 300 secondes si c'est possible. Cela permet aux enregistrements A, AAAA et MX mis à jour de se propager plus rapidement lorsque le moment du basculement arrive. Ne le réduisez pas cinq minutes avant le déplacement en vous attendant à ce qu'internet adopte une attitude philosophique à ce sujet. Les résolveurs récursifs peuvent déjà avoir l'ancienne valeur en cache.

Conservez un enregistrement de la zone DNS actuelle avant de la modifier. Si quelque chose d'inattendu apparaît après le basculement, restaurer des enregistrements connus est plus rapide que de les reconstruire de mémoire.

Choisir la bonne méthode de transfert

Le Transfer Tool de WHM est généralement la méthode la plus propre pour déplacer des comptes cPanel complets entre des serveurs compatibles. Il transfère les données du compte, les bases de données, les e-mails, les informations de zone DNS et de nombreux paramètres au niveau du compte dans un processus contrôlé unique. Utilisez un accès root ou de niveau revendeur lorsque c'est possible, et vérifiez que le serveur source autorise la connexion SSH requise.

Une sauvegarde cPanel complète peut également bien fonctionner lorsqu'un transfert direct de serveur à serveur n'est pas disponible. Générez la sauvegarde, transférez-la en toute sécurité vers le nouveau VPS, puis restaurez-la via WHM. Cette approche est plus manuelle, et la sauvegarde peut représenter un instantané plutôt que les changements les plus récents ; planifiez donc soigneusement la synchronisation finale.

Pour les applications avec des configurations inhabituelles, une migration manuelle peut être plus sûre. Copiez les fichiers du site web avec rsync ou une autre méthode de transfert sécurisée, exportez et importez les bases de données, recréez les utilisateurs et les autorisations, puis reconstruisez la configuration en dehors du compte. Cela prend plus de temps, mais offre davantage de contrôle lorsque le système source comporte des règles Nginx personnalisées, des chemins non standard, un stockage externe ou des workers d'application.

Évitez de copier uniquement le répertoire public_html à moins d'avoir confirmé qu'il n'y a rien d'autre à préserver. Les e-mails, les bases de données, les fichiers cachés, les définitions cron, les éléments SSL et les fichiers de configuration se trouvent souvent en dehors de ce dossier.

Tester le VPS avant les changements DNS publics

Une fois le compte restauré, validez le site sur l'IP de destination sans modifier le DNS public. Une entrée locale dans le fichier hosts permet à votre ordinateur de résoudre le domaine vers le nouveau VPS pendant que tout le monde continue d'atteindre l'ancien serveur. C'est le bon moment pour repérer une extension PHP manquante, une règle de réécriture cassée ou un utilisateur de base de données qui n'a pas été transféré.

Testez les pages principales, le flux de connexion, les formulaires de contact, le paiement, la zone d'administration, les téléversements d'images et les tâches planifiées. Examinez les journaux de l'application et le journal des erreurs du serveur web pendant cette étape. Vérifiez que le site utilise la version de PHP prévue et que le propriétaire des fichiers est correct. Une page qui se charge une fois ne constitue pas un test complet. Elle doit aussi écrire dans la base de données, envoyer les messages nécessaires et gérer normalement les sessions authentifiées.

Vérifiez également le SSL avant le basculement. Si le certificat est réémis après que le DNS pointe vers le VPS, confirmez que l'hôte virtuel du serveur web est correct et que les ports 80 et 443 sont accessibles. Si vous apportez un certificat existant, installez sa chaîne de certificats et sa clé en toute sécurité. Les navigateurs sont assez honnêtes sur les erreurs de certificat, parfois avec plus de drame que nécessaire.

Traiter l'e-mail séparément du trafic web

L'e-mail est la partie la plus souvent oubliée d'une migration vers un VPS. Si le domaine utilise un service d'e-mail externe comme Google Workspace ou Microsoft 365, conservez les enregistrements MX, SPF, DKIM et DMARC existants. Ne les remplacez pas accidentellement par des enregistrements de messagerie cPanel locaux.

Si l'e-mail est hébergé dans cPanel, migrez les boîtes aux lettres et testez l'envoi et la réception sur le VPS. Pendant la transition DNS, les nouveaux messages peuvent arriver sur l'un ou l'autre serveur. Gardez l'ancien compte d'hébergement actif pendant au moins 48 à 72 heures après le basculement, et effectuez une synchronisation finale du courrier et des fichiers si la source reste active. Pour un volume élevé de courrier ou des boîtes de réception critiques pour l'activité, planifiez un basculement de messagerie plus réfléchi au lieu de le traiter comme une idée de dernière minute.

Basculez avec précaution et gardez l'ancien serveur disponible

Lorsque les tests sont concluants, placez brièvement les parties dynamiques du site en mode maintenance si l'application le permet. Effectuez une exportation finale de la base de données ou une synchronisation du compte afin de capturer les commandes, les soumissions de formulaires, les changements utilisateur et les mises à jour de contenu effectués depuis le transfert initial. Restaurez ou synchronisez ces données finales sur le VPS, puis retirez le mode maintenance une fois le nouvel environnement prêt.

Mettez à jour l'enregistrement A vers la nouvelle adresse IPv4 et l'enregistrement AAAA uniquement si IPv6 est configuré et testé. Si les serveurs de noms changent aussi, effectuez ce changement délibérément et confirmez que la nouvelle zone contient tous les enregistrements requis. Changer les serveurs de noms et reconstruire le DNS au même moment ajoute des variables. C'est parfois nécessaire, mais ce n'est pas la plus élégante des situations DNS.

Surveillez le nouveau serveur pendant les premières heures. Vérifiez les journaux d'accès web, les erreurs PHP et applicatives, la charge CPU, la pression mémoire, l'utilisation disque, l'état de la file d'attente des e-mails et l'activité de la base de données. Confirmez que les sauvegardes automatisées s'exécutent correctement et que la supervision peut atteindre le nouveau VPS. Chez kodu.cloud, c'est là que les opérations gérées et la supervision FASTCARE sont utiles : le service redevient calme parce que quelqu'un surveille le comportement réel du serveur, pas seulement la page d'accueil.

N'annulez pas immédiatement l'ancien service. Laissez-le en ligne jusqu'à ce que la propagation DNS soit stabilisée, que le flux de messagerie soit confirmé, que les sauvegardes soient vérifiées et que les utilisateurs clés aient testé le site en production. Pour la plupart des sites standard, 72 heures constituent une fenêtre de sécurité raisonnable. Conservez un plan de retour arrière pendant cette période : gardez les anciennes valeurs DNS, évitez les modifications destructrices sur la source et sachez qui prendra la décision si un retour est nécessaire.

Vérifications post-migration qui évitent des problèmes plus tard

Après le déplacement, passez en revue les sauvegardes planifiées, les périodes de rétention, les tests de restauration, les mises à jour de sécurité, le comportement du pare-feu et les tendances de ressources. Supprimez les anciennes entrées de test de votre fichier hosts local. Mettez à jour toutes les listes d'autorisation externes, les cibles de supervision, les endpoints de webhook et la documentation qui font référence à l'ancienne adresse IP.

Un VPS vous donne aussi l'occasion de nettoyer un désordre d'hébergement installé depuis longtemps. Supprimez les comptes e-mail inactifs, les anciennes copies de préproduction, les bases de données abandonnées et les plugins ou extensions qui ne sont plus nécessaires. Faites-le une fois la migration stabilisée, pas pendant la fenêtre critique de transfert. Les changements calmes sont plus faciles à annuler.

Une bonne migration laisse plus qu'un site qui se charge par hasard. Elle laisse un serveur que vous pouvez superviser, restaurer, mettre à jour et auquel vous pouvez faire confiance lorsque le trafic arrive à une heure inopportune. Intégrez cette marge opérationnelle au déplacement, et la prochaine tâche de maintenance ressemblera beaucoup moins à une opération de sauvetage.

Andres Saar Ingénieur Customer Care