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/admin/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_SERVEUR 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 : 2manygames.fr)

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 :

Remplacer :

• PORT_ANCIEN : le port SSH de l’ancien serveur
• IP_ANCIEN : l’adresse IP de l’ancien serveur

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 admin).
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://2manygames.fr 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 OVH
• Modifier le A record de 2manygames.fr → IP_NOUVEAU_SERVEUR
• 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 : mcdavidian.fr)
• In Directory : laisser vide (installation à la racine)

Section « Source » (ancien serveur)

• Domain Name : le domaine du site (ex : mcdavidian.fr)
• Server Host : l’IP de l’ancien serveur (ex : 54.36.51.208)
• Protocol : SFTP (pas FTP — on passe par SSH)
• Port : le port SSH de l’ancien serveur (ex : 38596)
• 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/admin/web/mcdavidian.fr/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 : admin_timo). 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/admin/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.2 Vérifications post-import

Après l’import, quelques vérifications spécifiques à PrestaShop :

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

   1 2 3 4 5 6

   # PrestaShop 1.7+ rm -rf /home/admin/web/domaine.fr/public_html/var/cache/*   # PrestaShop 1.6 rm -rf /home/admin/web/domaine.fr/public_html/cache/smarty/compile/* rm -rf /home/admin/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) Checklist de migration par site

Pour chaque site migré, vérifier :

• Fichiers copiés et permissions corrigées (admin:admin)
• 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)

---

À suivre

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

• Odoo 17 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