Migrer de cPanel vers un VPS sans interruption de service

La plupart des gens restent sur un hébergement mutualisé bien après l'avoir dépassé, et c'est rarement parce qu'un VPS coûte trop cher. C'est parce que le déménagement paraît risqué. Une douzaine de sites, quelques bases de données, des boîtes mail que les clients utilisent tous les jours, des DNS répartis entre deux registrars — et la crainte lancinante que quelque chose reste hors ligne une journée entière le temps de comprendre. La bonne nouvelle : une migration menée dans le bon ordre n'a aucune interruption visible. L'astuce, c'est que presque tout le travail se fait avant de modifier le moindre enregistrement DNS. Voici la marche à suivre.

Étape 0 : faire l'inventaire avant de toucher à quoi que ce soit

Toutes les migrations douloureuses commencent par « on avait oublié… ». Avant de copier le moindre octet, notez ce qui vit réellement sur l'ancien compte :

• Domaines : domaine principal, domaines additionnels et parqués, sous-domaines, et l'endroit où le DNS de chacun est hébergé (le registrar, l'hébergeur mutualisé, Cloudflare…).
• Bases de données : chaque base MySQL et le site qui l'utilise. Les vieux comptes cPanel accumulent des bases orphelines issues d'installations abandonnées ; c'est le moment de les supprimer.
• Version de PHP et extensions par site. Un site qui tourne discrètement en PHP 7.4 depuis des années ne survivra pas forcément à 8.3 dès le premier jour.
• Tâches cron, invisibles jusqu'au jour où l'export nocturne n'arrive plus.
• E-mail : boîtes, redirections, répondeurs automatiques, adresses fourre-tout — et, en gros, le volume de courrier stocké.
• Règles .htaccess : redirections, dossiers protégés par mot de passe, règles de réécriture. Si votre nouveau serveur tourne sous Nginx, aucune n'est lue. Il faut les traduire.
• SSL : quels domaines ont un certificat, et s'il y a des certificats payants à reprendre.

Cette liste devient votre plan de test à la fin.

Étape 1 : baisser le TTL DNS un ou deux jours avant

Les enregistrements DNS portent un TTL (time to live) : la durée pendant laquelle les résolveurs peuvent mettre la réponse en cache. Les hébergeurs mutualisés utilisent souvent 14400 secondes (4 heures), voire 86400 (une journée entière). Si vous changez l'enregistrement A alors que le TTL est d'une journée, certains visiteurs continuent d'arriver sur l'ancien serveur pendant jusqu'à une journée.

Donc 24 à 48 heures avant le déménagement, baissez le TTL des enregistrements A, AAAA et MX à 300 secondes. Puis attendez que l'ancien TTL expire. Vérifiez ce que le monde voit actuellement :

dig +noall +answer example.com A
dig +noall +answer example.com MX

La deuxième colonne est le TTL restant. Dès qu'elle affiche 300, une bascule se propage en cinq minutes environ — et un retour arrière aussi, si besoin.

Étape 2 : récupérer une archive de sauvegarde complète

Sur cPanel, utilisez Sauvegarde → Télécharger une sauvegarde complète du compte. Si vous avez l'accès root sur l'ancien serveur, /scripts/pkgacct utilisateur produit la même archive plus vite. Sur Plesk, passez par le Gestionnaire de sauvegardes. L'archive contient le répertoire personnel (avec public_html), chaque base sous forme de dump SQL, les boîtes mail et les données de zone DNS.

Rapatriez-la directement sur le nouveau serveur plutôt que via votre ordinateur — cPanel peut pousser la sauvegarde vers un serveur distant en SCP, ou vous pouvez la télécharger avec wget depuis la nouvelle machine. Les archives de plusieurs gigaoctets sur une connexion domestique, c'est là que les migrations s'enlisent.

Si vous ne faites pas confiance à l'archive complète (les très gros comptes dépassent parfois le délai), copiez fichiers et bases séparément :

# sur le nouveau serveur : copier la racine web
rsync -avz --progress olduser@old-host:public_html/ /var/www/example/public_html/

# sur l'ancien hébergeur : exporter une base
mysqldump --single-transaction --routines --triggers olduser_wp > olduser_wp.sql

--single-transaction vous donne un instantané InnoDB cohérent sans verrouiller le site en production.

Étape 3 : reconstruire le site sur le VPS

Sur le nouveau serveur, créez le site — son propre utilisateur Linux, sa racine web, son pool PHP-FPM et son vhost — puis importez fichiers et données :

mysql -e "CREATE DATABASE example_wp; CREATE USER 'example_wp'@'localhost' IDENTIFIED BY 'un-long-mot-de-passe-aleatoire'; GRANT ALL ON example_wp.* TO 'example_wp'@'localhost';"
mysql example_wp < olduser_wp.sql

cPanel préfixe les noms de bases avec le nom du compte (olduser_wp). Sur le nouveau serveur, vous utiliserez presque certainement d'autres noms, utilisateurs et mots de passe : mettez donc à jour la configuration de l'application — wp-config.php, le .env de Laravel, etc. Corrigez ensuite les droits pour que l'utilisateur du site possède ses fichiers, et reprenez la version de PHP sur laquelle le site tournait. Montez de version plus tard, comme une étape séparée et délibérée.

Étape 4 : tester le nouveau serveur avant que le DNS ne le connaisse

Vous pouvez naviguer sur le nouveau serveur avec le vrai domaine sans toucher au DNS public. Faites pointer le domaine vers la nouvelle IP dans votre fichier hosts local, ou testez en ligne de commande :

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Parcourez le site, connectez-vous à l'administration, envoyez un formulaire, regardez le journal d'erreurs. C'est là que vous trouvez l'extension PHP manquante, le chemin absolu codé en dur vers /home/olduser/ et la redirection qui n'existait que dans .htaccess.

Étape 5 : l'e-mail, la partie que tout le monde sous-estime

Un site web est suffisamment statique pour être copié deux fois ; l'e-mail, non. Du courrier continue d'arriver pendant le déménagement, et les utilisateurs remarquent immédiatement quand quelque chose manque. Vous avez trois options :

1. Laisser l'e-mail où il est pour l'instant et ne déplacer que les sites. Les enregistrements MX continuent de pointer vers l'ancien hébergeur. C'est parfaitement valable, et ça découpe un déménagement risqué en deux faciles.
2. Déplacer l'e-mail chez un fournisseur de messagerie dédié.
3. Héberger l'e-mail sur votre VPS. Créez les boîtes sur le nouveau serveur, puis copiez les messages existants en IMAP avec imapsync :

imapsync --host1 old-host.example --user1 info@example.com --password1 'ancien' \
         --host2 new-host.example --user2 info@example.com --password2 'nouveau'

Lancez-le une fois avant la bascule, puis à nouveau après le changement de MX pour récupérer les retardataires. Avant d'héberger le courrier sur votre propre serveur, renseignez-vous sur SPF, DKIM, DMARC et le DNS inverse — une nouvelle IP sans réputation, c'est exactement ce dont les filtres anti-spam se méfient.

Étape 6 : la bascule

Avec un TTL de 300 secondes et un serveur testé, la bascule elle-même n'a rien de dramatique :

1. Gelez les modifications sur les sites dynamiques (pas de nouveaux articles, commandes ou mises à jour d'extensions pendant l'heure qui suit).
2. Faites une dernière synchronisation différentielle : relancez rsync (seuls les fichiers modifiés transitent) et refaites l'export puis l'import des bases.
3. Basculez les enregistrements A et AAAA vers la nouvelle IP. Ne changez les MX que si vous déplacez l'e-mail maintenant.
4. Émettez les certificats SSL dès que le DNS résout vers le nouveau serveur — le challenge HTTP de Let's Encrypt exige que le domaine pointe vers la machine qui demande le certificat.
5. Surveillez le journal d'accès de l'ancien serveur. Quand le trafic s'y tarit, la propagation est terminée.
6. Gardez l'ancien hébergement au moins une semaine. C'est votre retour arrière et l'archive de tout ce que vous auriez oublié.

Les pièges à l'origine des histoires « c'était en panne tout le week-end »

• Basculer le DNS avec un TTL de 24 heures. On ne rattrape pas un TTL long après coup. Baissez-le d'abord.
• .htaccess sous Nginx. Redirections et dossiers protégés cessent de fonctionner sans bruit. Traduisez-les dans la configuration du serveur.
• Chemins et URL codés en dur. Cherchez dans le code et dans la base /home/olduser et les versions http:// du domaine.
• Tâches cron oubliées. Recréez-les, avec le bon binaire PHP pour la version du site.
• Résilier l'ancien compte trop tôt. Ne le résiliez que lorsque le nouveau serveur a tout servi — web et mail — pendant une semaine.
• Tout changer d'un coup. Nouveau serveur, nouvelle version de PHP, nouvelle messagerie et mise à jour du thème le même soir : vous ne saurez pas quel changement a tout cassé. Déménagez d'abord, modernisez ensuite.

Comment ShadowPanel automatise le déménagement

ShadowPanel est un panneau de contrôle d'hébergement auto-hébergé, et quitter cPanel ou Plesk y est un processus intégré plutôt qu'un après-midi de commandes shell.

• Importez une archive de sauvegarde cPanel ou Plesk. Déposez l'archive dans le dossier de migrations du panel via SFTP (le bon choix pour les grosses sauvegardes) ou téléversez les plus petites depuis le navigateur. Le panel l'inspecte en lecture seule, détecte si elle provient de cPanel ou de Plesk et liste les domaines, bases et boîtes mail trouvés.
• Choisissez ce que vous reprenez. Indiquez le domaine cible et la version de PHP, si les fichiers doivent être importés, quelles bases et quelles boîtes mail. La migration tourne ensuite en tâche de fond : elle crée le site avec son propre utilisateur Linux isolé, son pool PHP-FPM et son vhost Nginx, copie la racine web en place et importe chaque base sous un nouveau nom, utilisateur et mot de passe gérés. Le résultat associe chaque base d'origine à son nouveau nom : mettre à jour la configuration de l'application prend deux minutes.
• Les boîtes mail sont créées avec de nouveaux mots de passe, affichés une seule fois à la fin pour que vous puissiez les distribuer — les empreintes de mots de passe de l'ancien hébergeur ne sont pas réutilisables. Les messages stockés ne sont pas copiés : l'imapsync de l'étape 5 reste d'actualité.
• Vous avez déjà copié un site à la main ? La fonction Importer un site existant reprend un site déjà présent sur le disque du serveur. Elle affiche un aperçu de la taille, du nombre de fichiers, de l'application détectée et de la version de PHP, et devine la base de données depuis wp-config.php ou .env. Elle copie ensuite les fichiers dans l'arborescence gérée — sans jamais les déplacer, l'original reste donc intact —, sauvegarde le vhost existant éventuel, et reprend ou émet le certificat SSL.
• Le vide laissé par .htaccess est comblé par les redirections et les chemins protégés par mot de passe, par site, dans le panel, et les certificats sont émis et renouvelés automatiquement (voir le SSL gratuit avec Let's Encrypt).

Les deux outils d'import sont réservés aux administrateurs, puisqu'ils agissent sur l'ensemble du serveur. Si vous n'avez pas encore choisi de serveur, installer un panneau d'hébergement sur un VPS Hetzner couvre la mise en place de bout en bout.

En résumé

Une migration sans interruption, c'est surtout une question d'ordre : faire l'inventaire, baisser le TTL tôt, reconstruire et tester sur le nouveau serveur pendant que l'ancien continue de servir, traiter l'e-mail comme un projet à part, puis basculer le DNS avec un TTL court et l'ancien hébergeur comme filet de sécurité. Aucune étape n'est difficile. C'est d'en sauter une qui fait mal. ShadowPanel prend une archive cPanel ou Plesk et transforme la reconstruction — site, isolation, fichiers, bases, boîtes mail — en import guidé, pour que vous consacriez votre attention aux tests plutôt qu'à la plomberie.

curl -fsSL https://shadowpanel.de/install.sh | bash

Voir les tarifs et télécharger →