1) Stratégie de migration

L’idée est simple : préparer tout sur le nouveau serveur pendant que l’ancien tourne encore.
On ne touche au DNS qu’à la toute fin, quand on a vérifié que tout fonctionne. Ça évite le downtime.

Ordre recommandé

1. Sites statiques — les plus simples, parfaits pour valider la procédure
2. WordPress — migration via plugin, rapide et fiable
3. PrestaShop — les plus complexes, migration manuelle + Softaculous Premium

Les deux serveurs ont VestaCP / MyVestaCP — la structure des fichiers est identique
(/home/{{USER_VESTA}}/web/domaine.fr/public_html/), ce qui simplifie les copies.

Prérequis

• Accès SSH (root) aux deux serveurs (ancien + nouveau)
• Les domaines déjà créés dans MyVestaCP sur le nouveau serveur (voir article précédent)
• Ne pas toucher au DNS pour l’instant — l’ancien serveur continue de servir les visiteurs

1.1 Préparer l’accès SSH entre les deux serveurs

Pour copier les fichiers avec rsync, le nouveau serveur doit pouvoir se connecter
en SSH à l’ancien. Si l’ancien serveur a un 2FA (TOTP) activé,
rsync ne pourra pas s’authentifier de manière interactive.
La solution : créer une clé SSH dédiée au transfert et autoriser le nouveau serveur par IP.

Étape 1 — Générer une clé SSH sur le nouveau serveur

Copie la clé publique affichée (la ligne entière commençant par ssh-ed25519 ...).

Étape 2 — Ajouter la clé sur l’ancien serveur

Colle la clé publique sur une nouvelle ligne à la fin du fichier. Sauvegarde.

Étape 3 — Autoriser le nouveau serveur sans 2FA

Toujours sur l’ancien serveur, ajouter à la fin de /etc/ssh/sshd_config :

Ajouter tout en bas :

Remplacer {{IP_NOUVEAU}} par l’adresse IP du nouveau serveur.
Cette règle dit : « depuis cette IP, accepter la clé SSH seule, sans mot de passe ni code TOTP,
et autoriser le login root ». Sans PermitRootLogin yes dans le bloc Match,
la connexion sera refusée si le paramètre global est no.
Tous les autres accès restent protégés par le 2FA.

Étape 4 — Tester la connexion

Si tu vois OK sans qu’on te demande de mot de passe ni de code TOTP, c’est prêt.

« Connection refused » ? Si tu as tenté de te connecter plusieurs fois avant de configurer la clé,
l’IP du nouveau serveur a pu être bannie. Deux endroits à vérifier sur l’ancien serveur :

1. Fail2ban (débannir l’IP) :

2. iptables / firewall VestaCP — VestaCP gère ses propres règles iptables,
parfois sous un nom de chaîne différent (ex : fail2ban-SSH au lieu de f2b-sshd).
Même après un unbanip, l’IP peut rester bloquée dans iptables :

Sécurité : une fois la migration terminée, pense à supprimer le bloc
Match Address de l’ancien serveur et à retirer la clé du fichier authorized_keys.
Pas besoin de laisser cet accès ouvert indéfiniment.

2) Migrer un site statique (ex : {{DOMAINE_STATIQUE}})

Un site statique n’a pas de base de données — ce sont uniquement des fichiers HTML, CSS, JS et images.
La migration se résume à copier les fichiers et vérifier les permissions.

2.1 Copier les fichiers depuis l’ancien serveur

Depuis le nouveau serveur (en root), on utilise rsync pour copier le contenu du site :

rsync est préférable à scp : il ne copie que les fichiers modifiés (pratique si tu relances la commande),
et il préserve les permissions.

2.2 Corriger les permissions

Important : MyVestaCP s’attend à ce que les fichiers appartiennent à l’utilisateur du panel (ici {{USER_VESTA}}).
Si les permissions sont mauvaises, Nginx/Apache retournera une erreur 403.

2.3 Tester sans toucher au DNS

Avant de basculer le DNS, on peut forcer son PC à résoudre le domaine vers le nouveau serveur
en modifiant le fichier hosts :

Sur Windows — ouvrir en administrateur :

Sur Mac / Linux :

Ajouter la ligne :

Puis ouvrir http://{{DOMAINE_STATIQUE}} dans le navigateur.
Si le site s’affiche correctement, la migration est prête.

Pense à supprimer cette ligne du fichier hosts après avoir basculé le DNS,
sinon tu ne verras jamais le vrai DNS depuis ton PC.

2.4 Basculer le DNS

Quand le test est concluant, changer l’enregistrement A du domaine
pour pointer vers l’IP du nouveau serveur :

• Chez ton registrar (OVH, Gandi, Cloudflare…) ou dans la zone DNS
• Modifier le A record de {{DOMAINE_STATIQUE}} → {{IP_NOUVEAU}}
• Idem pour www (A record ou CNAME vers le domaine principal)

La propagation DNS prend entre 5 minutes et 24 heures selon les TTL et les FAI.
Pendant ce temps, certains visiteurs voient l’ancien serveur, d’autres le nouveau — c’est normal et transparent.

2.5 Activer le SSL (Let’s Encrypt)

Une fois le DNS propagé (le domaine pointe vers le nouveau serveur), activer le certificat SSL :

Ou depuis le panel : domaine → Edit → cocher Let’s Encrypt Support.

Attendre que le DNS soit propagé avant de demander le certificat.
Let’s Encrypt vérifie que le domaine pointe bien vers le serveur sur le port 80.
Si le DNS n’a pas encore basculé, la demande échouera.

3) Migrer un site WordPress (via Softaculous)

Softaculous Premium permet d’importer un WordPress directement depuis l’ancien serveur :
il copie les fichiers et la base de données en une seule opération.
Plus besoin de plugin de migration.

3.1 Lancer l’import depuis Softaculous

Dans le panel MyVestaCP → onglet APPS (Softaculous) → WordPress
→ Import → onglet Import From Remote Server.

Section « Destination » (nouveau serveur)

• Protocol : http://
• Domain : sélectionner le domaine cible (ex : {{DOMAINE_WP}})
• In Directory : laisser vide (installation à la racine)

Section « Source » (ancien serveur)

• Domain Name : le domaine du site (ex : {{DOMAINE_WP}})
• Server Host : l’IP de l’ancien serveur (ex : {{IP_ANCIEN}})
• Protocol : SFTP (pas FTP — on passe par SSH)
• Port : le port SSH de l’ancien serveur (ex : {{PORT_SSH_ANCIEN}})
• Username : root (on réutilise la clé SSH configurée à l’étape 1.1)
• Authentication method : SSH Key
• Private Key : coller le contenu de la clé privée du nouveau serveur
  (cat /root/.ssh/id_ed25519 — tout le bloc, y compris les lignes BEGIN/END)
• Passphrase : laisser vide (clé sans passphrase)
• SFTP Path : /home/{{USER_VESTA}}/web/{{DOMAINE_WP}}/public_html

Grâce au bloc Match Address configuré dans la section 1.1, la connexion SFTP
utilise la clé SSH directement — pas besoin de mot de passe ni de code 2FA.

Alternative FTP : si le SFTP ne fonctionne pas, tu peux utiliser le protocole
FTP (port 21) avec l’utilisateur FTP créé par VestaCP pour le domaine
(ex : {{FTP_USER}}). Dans ce cas, le FTP Path est simplement
/public_html (chemin relatif au home de l’utilisateur FTP).

Section « Database » (ancien serveur)

Les identifiants de la base de données sur l’ancien serveur.
Tu les trouves dans wp-config.php du site source :

• Database Name : la valeur de DB_NAME
• Database User : la valeur de DB_USER
• Database Password : la valeur de DB_PASSWORD
• Database Host : localhost

Cliquer sur Import et patienter — Softaculous copie les fichiers via SFTP et exporte/importe la BDD.

Softaculous crée automatiquement la base de données sur le nouveau serveur
et adapte le wp-config.php avec les nouveaux identifiants.

3.2 Vérifier et basculer

1. Tester via le fichier hosts (même méthode que pour le site statique)
2. Vérifier le front-office et le back-office (se connecter avec les identifiants de l’ancien site)
3. Basculer le DNS (A record → nouvelle IP)
4. Activer Let’s Encrypt une fois le DNS propagé
5. Vérifier les permaliens : Réglages → Permaliens → sauvegarder

4) Migrer un site PrestaShop (via Softaculous)

Même principe que WordPress : Softaculous Premium importe le PrestaShop depuis l’ancien serveur
(fichiers + BDD). C’est la méthode la plus sûre pour un CMS complexe avec des centaines de tables,
des modules custom et des thèmes modifiés.

4.1 Lancer l’import depuis Softaculous

Panel MyVestaCP → APPS (Softaculous) → PrestaShop
→ Import → onglet Import From Remote Server.

Section « Destination »

• Protocol : http://
• Domain : sélectionner le domaine cible
• In Directory : laisser vide

Section « Source »

• Domain Name : le domaine du site PrestaShop
• Server Host : l’IP de l’ancien serveur
• Protocol : SFTP
• Port : le port SSH de l’ancien serveur
• Username : root
• Authentication method : SSH Key (même clé que pour WordPress)
• Private Key : contenu de /root/.ssh/id_ed25519 du nouveau serveur
• Passphrase : vide
• SFTP Path : /home/{{USER_VESTA}}/web/domaine.fr/public_html

Section « Database »

Les identifiants de la BDD source. Selon la version de PrestaShop :

PrestaShop 1.7+ :

PrestaShop 1.6 :

• Database Name, Database User, Database Password : les valeurs trouvées ci-dessus
• Database Host : localhost

Cliquer sur Import et patienter.

Softaculous adapte automatiquement la configuration (identifiants BDD, chemins)
et prend en charge le site pour les futures sauvegardes et mises à jour.

4.1bis Problème Cloudflare : « Could not Resolve Domain Name »

Si le domaine source est derrière Cloudflare (proxy activé, icône nuage orange),
Softaculous échouera avec l’erreur Could not Resolve Domain Name.
Le serveur ne peut pas résoudre le domaine vers la vraie IP car Cloudflare masque celle-ci.

Solutions possibles :

1. Désactiver temporairement le proxy Cloudflare (nuage gris = DNS Only) le temps de l’import
2. Ajouter une entrée dans /etc/hosts du nouveau serveur pointant le domaine vers l’IP réelle de l’ancien serveur
3. Méthode alternative : backup/restore via rsync (recommandée si on ne veut pas toucher à Cloudflare)

Méthode backup/restore via rsync

Plutôt que d’importer depuis le serveur distant, on crée un backup Softaculous sur l’ancien serveur
puis on le transfère et le restaure sur le nouveau :

1. Sur l’ancien serveur, dans Softaculous → le site PrestaShop → Backup → créer un backup
2. Transférer le backup vers le nouveau serveur via rsync :
   
   # Depuis le nouveau serveur rsync -avz -e "ssh -p {{PORT_SSH_ANCIEN}}" \ root@{{IP_ANCIEN}}:/home/{{USER_VESTA}}/softaculous_backups/NOM_BACKUP.tar.gz \ /home/{{USER_VESTA}}/softaculous_backups/

   1 2 3 4

   # Depuis le nouveau serveur rsync -avz -e "ssh -p {{PORT_SSH_ANCIEN}}" \   root@{{IP_ANCIEN}}:/home/{{USER_VESTA}}/softaculous_backups/NOM_BACKUP.tar.gz \   /home/{{USER_VESTA}}/softaculous_backups/

3. Sur le nouveau serveur, dans Softaculous → Backups (menu de gauche) →
   le backup apparaît → cliquer sur Restore

Attention : avec cette méthode de restore, Softaculous restaure le parameters.php
tel quel depuis le backup — il contient donc les anciens identifiants BDD de l’ancien serveur
(et non pas un fichier vide comme lors d’un import direct). Le résultat est le même :
le site ne fonctionne pas tant que parameters.php n’est pas corrigé
(voir section 4.3 ci-dessous).

4.2 Version PHP : compatibilité PrestaShop

PrestaShop 1.7.x n’est pas compatible avec PHP 8.2 (erreur fatale dans bootstrap.php).
Il faut utiliser PHP 7.4, installé via la procédure décrite dans l’article MyVestaCP (section 5.1.1).

4.3 Problème courant : parameters.php incorrect après import ou restore

Selon la méthode utilisée, le fichier app/config/parameters.php peut être
dans deux états problématiques :

• Import direct (« Import From Remote Server ») : le fichier est vide (0 octet).
  Le site affiche des erreurs PHP et Error: "install" directory is missing.
• Restore depuis un backup : le fichier contient les anciens identifiants
  de l’ancien serveur (ancien nom de BDD, ancien utilisateur, ancien mot de passe).
  Le site affiche une page blanche ou une erreur de connexion à la base de données.

Dans les deux cas, il faut reconstruire ou corriger la configuration :

1. Récupérer le parameters.php original depuis l’ancien serveur :
   
   ssh -p {{PORT_SSH_ANCIEN}} root@{{IP_ANCIEN}} \ "cat /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php"

   1 2	ssh -p {{PORT_SSH_ANCIEN}} root@{{IP_ANCIEN}} \   "cat /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php"

2. Identifier les identifiants BDD sur le nouveau serveur :
   
   # Nom de la BDD mysql -e "SHOW DATABASES;" | grep domaine # Utilisateur et grants mysql -e 'SHOW GRANTS FOR "{{USER_VESTA}}_nombase"@"localhost";'

   1 2 3 4 5

   # Nom de la BDD mysql -e "SHOW DATABASES;" | grep domaine   # Utilisateur et grants mysql -e 'SHOW GRANTS FOR "{{USER_VESTA}}_nombase"@"localhost";'

3. Créer le parameters.php sur le nouveau serveur en reprenant la structure
   de l’ancien, mais en adaptant :
   • database_name → le nom de la BDD sur le nouveau serveur
   • database_user → l’utilisateur MySQL créé par Softaculous
   • database_password → un nouveau mot de passe (à définir via ALTER USER)
   • ps_caching → CacheFs (si Memcached n’est pas installé sur le nouveau serveur)
   • ps_cache_enable → false (désactiver temporairement le cache)
4. Corriger les permissions :
   
   chown {{USER_VESTA}}:{{USER_VESTA}} /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php chmod 600 /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php

   1 2	chown {{USER_VESTA}}:{{USER_VESTA}} /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php chmod 600 /home/{{USER_VESTA}}/web/domaine.fr/public_html/app/config/parameters.php

4.4 Vérifications post-import

Après l’import (et la correction éventuelle de parameters.php) :

1. Vider le cache :
   
   # PrestaShop 1.7+ rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/var/cache/* # PrestaShop 1.6 rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/cache/smarty/compile/* rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/cache/smarty/cache/*

   1 2 3 4 5 6

   # PrestaShop 1.7+ rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/var/cache/*   # PrestaShop 1.6 rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/cache/smarty/compile/* rm -rf /home/{{USER_VESTA}}/web/domaine.fr/public_html/cache/smarty/cache/*

2. Tester via le fichier hosts : front-office et back-office
3. Basculer le DNS (A record → nouvelle IP)
4. Activer Let’s Encrypt une fois le DNS propagé
5. Dans le back-office : Préférences → SEO & URLs → activer SSL si nécessaire

5) Reconfigurer les sauvegardes automatiques Softaculous

Les crons de sauvegarde automatique Softaculous de l’ancien serveur utilisent
des identifiants d’installation (--insid=XXX_XXXXX, etc.)
qui sont propres à chaque serveur. Ils ne sont pas réutilisables
sur le nouveau serveur. Il faut reconfigurer les backups automatiques depuis le panel.

5.1 Transférer les anciens backups (optionnel)

Pour conserver l’historique des sauvegardes et pouvoir restaurer une version
antérieure si nécessaire après la migration :

Espace disque : vérifier que le nouveau serveur a assez de place
avant de lancer le transfert. Les sauvegardes PrestaShop peuvent peser plusieurs Go chacune
(base + fichiers + images). Vérifier la taille sur l’ancien serveur avec
du -sh /home/{{USER_VESTA}}/softaculous_backups/.

Si les backups n’apparaissent pas dans Softaculous :
Softaculous indexe les sauvegardes à partir des installations qu’il connaît.
Si le site a été importé via « Import From Remote Server »,
les anciens backups seront reconnus automatiquement.
Si le site a été copié manuellement (rsync), il faudra d’abord l’enregistrer
dans Softaculous via Import → Import an existing installation.

5.2 Activer les sauvegardes automatiques sur le nouveau serveur

Pour chaque installation (WordPress, PrestaShop, Matomo, etc.) :

1. MyVestaCP → APPS (Softaculous)
2. Cliquer sur l’installation concernée
3. Onglet Backup → cocher Automated Backups
4. Configurer la fréquence (quotidien, hebdomadaire, mensuel)
   et la rétention (nombre de backups à conserver)
5. Save

Softaculous génère automatiquement les crons avec les bons --insid=
du nouveau serveur. Vérifier qu’ils apparaissent :

Ne pas oublier cette étape. Sans sauvegardes automatiques,
une erreur de manipulation, un piratage ou une mise à jour ratée peut entraîner
une perte de données irréversible. Configurer les backups automatiques
immédiatement après la migration de chaque site.

---

6) Migrer les crons VestaCP

VestaCP stocke les tâches planifiées (crons) dans
/usr/local/vesta/data/users/<user>/cron.conf.
Il faut migrer uniquement les crons custom (PrestaShop, Matomo, etc.)
— les crons système VestaCP (disk, traffic, webstats, backup, rrd, letsencrypt)
existent déjà sur le nouveau serveur.

6.1 Lister les crons de l’ancien serveur

6.2 Identifier les crons à migrer

Parmi les crons trouvés, ne pas migrer :

• Crons système VestaCP (v-update-sys-queue, v-backup-users, v-update-sys-rrd, v-update-letsencrypt-ssl, etc.) — déjà présents sur le nouveau serveur
• Crons suspended (colonne yes) — inutile de réimporter des crons désactivés
• Crons Softaculous (cli.php –backup) — les sauvegardes Softaculous seront reconfigurées sur le nouveau serveur
• Crons ownCloud — gérés par le conteneur Docker owncloud-cron
• Crons liés à des plugins VestaCP (v-df-snapshot, v-fix-website-permissions) — spécifiques à l’ancien serveur

Règle simple : ne migrer que les crons qui appellent des URLs de sites web
(via curl) ou exécutent des scripts PHP liés aux applications
(PrestaShop, Matomo, etc.).

6.3 Ajouter les crons sur le nouveau serveur

Utiliser la commande v-add-cron-job de MyVestaCP pour chaque cron à migrer.
Syntaxe : v-add-cron-job <user> <min> <hour> <day> <month> <wday> '<command>'

Exemples de crons PrestaShop ({{DOMAINE_PS_1}}) :

Exemples de crons PrestaShop ({{DOMAINE_PS_2}}) :

Exemples de crons Matomo :

6.4 Vérifier les crons importés

Tokens et URLs : les tokens dans les URLs PrestaShop (faceted search,
admin search, etc.) sont générés par chaque installation.
Si le site a été réinstallé (et non copié) sur le nouveau serveur,
il faudra régénérer les tokens depuis le back-office de chaque module.

Chemins PHP : les crons qui exécutent des scripts PHP locaux
(ets_seo, ets_reviews, Matomo) dépendent du chemin
/home/{{USER_VESTA}}/web/domaine/public_html/.
Vérifier que ces chemins existent sur le nouveau serveur
et que PHP est accessible via /usr/bin/php ou php.

Récapitulatif : adapter le nombre de crons custom à migrer selon vos sites —
typiquement quelques crons par site PrestaShop + Matomo.
Les crons système VestaCP, les crons suspended, les crons Softaculous
et les crons ownCloud ne sont pas migrés ici.

---

7) Checklist de migration par site

Pour chaque site migré, vérifier :

• Fichiers copiés et permissions corrigées ({{USER_VESTA}}:{{USER_VESTA}})
• Base de données importée (si applicable)
• Configuration adaptée (identifiants BDD, host)
• Test via fichier hosts : front-office OK
• Test via fichier hosts : back-office OK (WordPress/PrestaShop)
• DNS basculé (A record → nouvelle IP)
• Let’s Encrypt activé (après propagation DNS)
• Ligne retirée du fichier hosts local
• Cache vidé (navigateur + serveur)
• Sauvegardes automatiques Softaculous activées
• Crons custom migrés (PrestaShop, Matomo, etc.)

---

À suivre

Les sites web sont migrés et fonctionnels sur le nouveau serveur.
Dans les prochains articles :

• Odoo en Docker avec reverse proxy Nginx
• Akeneo PIM : gestion centralisée des produits (Docker)
• ownCloud : migration des données et Docker Compose
• Serveurs de jeux : CS 1.6, TeamSpeak 3, EmuLinker
• Sauvegardes : stratégie et automatisation