Espace client
Linux•29 août 2026• 12 vues

Migrer un site d'un hébergement mutualisé vers un VPS (2026)

Migrer un site d'un hébergement mutualisé vers un VPS (2026)

Pourquoi migrer vers un VPS ?

L'hébergement mutualisé est adapté aux sites à faible trafic et aux projets qui n'ont pas besoin de contrôle sur l'environnement serveur. Certains besoins dépassent ce cadre : version PHP spécifique non disponible, accès root requis pour une dépendance système, performances affectées par le voisinage sur le noeud partagé, ou nécessité d'héberger plusieurs projets avec des configurations isolées. La migration vers un VPS répond à ces cas précis, sans que le mutualisé soit inadapté pour les usages qu'il couvre.

Étape 1 : Inventaire avant migration

Réaliser l'inventaire complet avant de toucher quoi que ce soit. Une migration ratée vient presque toujours d'un élément oublié à cette étape.

Fichiers et répertoires

  • Répertoire web principal (souvent public_html/, www/ ou htdocs/)
  • Fichiers de configuration hors racine web (fichiers .env, configs applicatives)
  • Fichiers uploadés par les utilisateurs (souvent dans un sous-dossier uploads/ ou storage/)
  • Crons configurés sur le mutualisé (lister via le panneau de contrôle de l'hébergeur actuel)

Base de données

  • Nom de la base, nom d'utilisateur, mot de passe (disponibles dans le panneau ou dans le fichier de config de l'application)
  • Version MySQL/MariaDB utilisée sur le mutualisé (vérifier la compatibilité avec la version cible)

Mails

  • Les boites mail hébergées chez l'hébergeur mutualisé ne migrent pas automatiquement vers le VPS
  • Lister les adresses mail actives et décider : les migrer sur le VPS (Postfix/Dovecot), les transférer vers un service tiers, ou les laisser chez l'hébergeur actuel avec les enregistrements MX inchangés

DNS et TTL

Avant toute migration, baisser le TTL de l'enregistrement A du domaine à 300 secondes (5 minutes). Cela réduit le délai de propagation lors de la bascule finale.

Localiser l'enregistrement A dans la zone DNS du domaine (généralement dans le panneau du registrar ou de l'hébergeur actuel) et modifier la valeur TTL :

; Avant migration : TTL habituel (souvent 3600 ou 86400)
monsite.fr.  3600  IN  A  1.2.3.4

; Modifier à 300 au moins 24h avant la bascule
monsite.fr.  300   IN  A  1.2.3.4

Attendre au moins la durée de l'ancien TTL après la modification avant de procéder à la bascule, pour que la propagation soit effective.

Étape 2 : Préparer le VPS

Installer et sécuriser le VPS avant de transférer les données. Ne pas migrer vers un serveur non configuré.

  • Sécurisation de base (SSH par clé, UFW, mises à jour) : Checklist sécurité VPS
  • Accès SSH par clé : Guide clé SSH
  • Installation de la stack web (Nginx + PHP-FPM + MariaDB) : Guide Nginx + PHP-FPM
  • Créer le répertoire de destination : sudo mkdir -p /var/www/monsite.fr
  • Vérifier que la version PHP installée sur le VPS est compatible avec l'application

Étape 3 : Transférer les fichiers

Avec rsync (accès SSH disponible côté mutualisé)

rsync est la méthode recommandée : elle transfère uniquement les fichiers modifiés, supporte la reprise en cas d'interruption et préserve les permissions. Source : man rsync

Depuis le VPS (en tirant les fichiers depuis le mutualisé) :

rsync -avz --progress \
  [email protected]:/home/utilisateur/public_html/ \
  /var/www/monsite.fr/

Ou depuis une machine locale (si accès SSH aux deux serveurs) :

rsync -avz --progress \
  [email protected]:/home/utilisateur/public_html/ \
  [email protected]:/var/www/monsite.fr/

Options utilisées :

  • -a : mode archive (préserve permissions, timestamps, liens symboliques)
  • -v : verbeux (affiche les fichiers transférés)
  • -z : compression pendant le transfert
  • --progress : affiche la progression

Sans accès SSH côté mutualisé (SFTP ou téléchargement manuel)

Si le mutualisé ne propose pas d'accès SSH, utiliser un client SFTP (FileZilla, Cyberduck) pour télécharger les fichiers localement, puis les envoyer sur le VPS :

# Depuis la machine locale vers le VPS
rsync -avz --progress /chemin/local/public_html/ \
  utilisateur@ip-vps:/var/www/monsite.fr/

Ajuster les permissions

sudo chown -R www-data:www-data /var/www/monsite.fr
sudo find /var/www/monsite.fr -type d -exec chmod 755 {} \;
sudo find /var/www/monsite.fr -type f -exec chmod 644 {} \;

Étape 4 : Exporter et importer la base de données

Export depuis le mutualisé

Si le mutualisé propose un accès SSH :

mysqldump -u utilisateur_bdd -p nom_base > export-$(date +%F).sql

Sans accès SSH, utiliser phpMyAdmin (disponible sur la plupart des hébergements mutualisés) : Exporter > Format SQL > Télécharger.

Source : dev.mysql.com : mysqldump

Transférer le fichier d'export vers le VPS

scp export-$(date +%F).sql utilisateur@ip-vps:/home/utilisateur/

Créer la base de données sur le VPS

sudo mariadb -u root
CREATE DATABASE nom_base CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'utilisateur_bdd'@'localhost' IDENTIFIED BY 'mot_de_passe_fort';
GRANT ALL PRIVILEGES ON nom_base.* TO 'utilisateur_bdd'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Importer les données

mariadb -u utilisateur_bdd -p nom_base < /home/utilisateur/export-$(date +%F).sql

Étape 5 : Reconfigurer l'application sur le VPS

Fichier de configuration de l'application

Mettre à jour les paramètres de connexion à la base de données dans le fichier de configuration de l'application (.env, wp-config.php, config.php selon le framework) :

  • Hôte de la base : localhost (la base est sur le même serveur)
  • Nom de la base, utilisateur et mot de passe : ceux créés à l'étape précédente

Chemins absolus

Vérifier et mettre à jour tous les chemins absolus codés en dur dans la configuration. Sur un mutualisé, les chemins commencent souvent par /home/utilisateur/public_html/ ; sur le VPS, ils commencent par /var/www/monsite.fr/.

URL en base de données (si applicable)

Certaines applications (notamment WordPress) stockent l'URL du site en base de données. Si l'URL change lors de la migration, mettre à jour ces valeurs. Pour WordPress, utiliser WP-CLI :

sudo -u www-data wp search-replace 'http://ancien-domaine.fr' 'https://monsite.fr' \
  --path=/var/www/monsite.fr

Pour les autres applications, consulter la documentation du framework concerné.

Vhost Nginx

Créer le vhost Nginx pour le site. Pour un site PHP générique :

server {
    listen 80;
    server_name monsite.fr www.monsite.fr;
    root /var/www/monsite.fr;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
sudo ln -s /etc/nginx/sites-available/monsite.fr /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Pour WordPress : Guide WordPress sur VPS (vhost spécifique avec gestion des permaliens).

Étape 6 : Tester le site avant la bascule DNS

Ne jamais basculer le DNS sans avoir vérifié que le site fonctionne sur le VPS. Modifier le fichier hosts local pour forcer la résolution vers la nouvelle IP, sans toucher au DNS public.

Modifier le fichier hosts local

Sur Linux ou macOS :

sudo nano /etc/hosts

Sur Windows : C:\Windows\System32\drivers\etc\hosts (ouvrir en administrateur)

Ajouter la ligne :

ip-du-vps  monsite.fr www.monsite.fr

Le navigateur résout maintenant monsite.fr vers le VPS, sans que les autres utilisateurs soient affectés.

Points à vérifier

  • Page d'accueil et pages internes s'affichent correctement
  • Formulaires de contact fonctionnent (envoi de mail)
  • Connexion à l'espace d'administration
  • Fichiers uploadés accessibles (images, documents)
  • Redirections actives (301, 302)
  • Pas d'erreur dans les logs Nginx : sudo tail -f /var/log/nginx/error.log

Supprimer l'entrée hosts après les tests

# Supprimer la ligne ajoutée dans /etc/hosts
sudo nano /etc/hosts

Étape 7 : Émettre le certificat SSL

Émettre le certificat Let's Encrypt avant la bascule DNS n'est pas possible (Certbot doit résoudre le domaine vers le VPS). Émettre le certificat juste après la bascule, pendant que le TTL bas est encore actif.

sudo certbot --nginx -d monsite.fr -d www.monsite.fr

Guide complet : Guide Certbot OuiHeberg.

Étape 8 : Basculer le DNS

Une fois les tests validés, modifier l'enregistrement A du domaine pour pointer vers l'IP du VPS :

; Avant
monsite.fr.  300  IN  A  1.2.3.4   (ancienne IP mutualisé)

; Après
monsite.fr.  300  IN  A  5.6.7.8   (nouvelle IP VPS)

Avec le TTL à 300 secondes, la propagation est effective en 5 à 10 minutes pour la majorité des résolveurs DNS. Surveiller les logs Nginx pendant cette période pour confirmer que le trafic arrive bien sur le VPS :

sudo tail -f /var/log/nginx/access.log

Une fois la propagation confirmée, remonter le TTL à une valeur standard (3600 ou 86400) :

monsite.fr.  3600  IN  A  5.6.7.8

Étape 9 : Période de recouvrement

Garder l'hébergement mutualisé actif pendant 1 à 2 semaines après la bascule. Cette période permet de :

  • Récupérer des fichiers oubliés lors de l'inventaire initial
  • Vérifier que les mails hébergés sur le mutualisé continuent d'arriver (si les MX n'ont pas changé)
  • Disposer d'un point de retour rapide en cas de problème critique

Ne pas supprimer les données du mutualisé avant d'avoir confirmé que tout fonctionne correctement sur le VPS.

Pièges courants

Les mails restent chez l'ancien hébergeur

Si le domaine avait des boites mail sur le mutualisé, les enregistrements MX pointent toujours vers l'ancien hébergeur après la bascule de l'enregistrement A. C'est souvent voulu (garder les mails chez l'hébergeur actuel pendant la transition), mais vérifier que c'est intentionnel. Décider explicitement de la stratégie mail avant la bascule DNS.

Les crons ne se déclenchent plus

Les tâches planifiées configurées dans le panneau du mutualisé ne migrent pas automatiquement. Les recréer dans le crontab du VPS :

crontab -e

Lister les crons de l'ancien hébergeur depuis son panneau de contrôle avant la migration (étape inventaire).

Le certificat SSL n'est pas émis immédiatement

Certbot ne peut pas émettre un certificat pour un domaine qui ne pointe pas encore vers le VPS. Émettre le certificat juste après la bascule DNS, pendant que le TTL bas est encore actif. Entre la bascule et l'émission du certificat, le site est accessible en HTTP uniquement.

Les chemins absolus en base de données

Certaines applications stockent des chemins absolus en base (chemin vers les fichiers uploadés, URL des images). Ces chemins doivent être mis à jour après la migration. Utiliser la fonction rechercher/remplacer de l'application ou un script SQL :

UPDATE wp_options SET option_value = REPLACE(option_value,
  '/home/ancien/public_html',
  '/var/www/monsite.fr')
WHERE option_value LIKE '%/home/ancien/public_html%';

Questions fréquentes

Combien de temps dure une migration ?

Pour un site standard (quelques centaines de Mo, une base de données de taille raisonnable), la migration technique prend 1 à 3 heures. La préparation (inventaire, baisse du TTL, configuration du VPS) représente la majorité du temps. La bascule DNS elle-même prend moins de 10 minutes avec un TTL à 300 secondes.

Peut-on migrer sans interruption de service ?

Oui, si la procédure est suivie dans l'ordre : le site reste actif sur le mutualisé pendant toute la préparation et les tests. La seule interruption potentielle est la fenêtre entre la bascule DNS et l'émission du certificat SSL (quelques minutes). Avec un TTL à 300 secondes, cette fenêtre est courte.

Faut-il prévenir les visiteurs ?

Pour un site à faible trafic, non. Pour un site e-commerce ou une application avec des utilisateurs connectés (sessions actives), planifier la migration en dehors des heures de pointe et afficher une page de maintenance pendant la bascule.

Que faire si le site ne fonctionne pas après la bascule ?

Remettre l'enregistrement A sur l'ancienne IP du mutualisé (le TTL à 300 secondes permet un retour arrière rapide). Diagnostiquer le problème sur le VPS sans pression, puis relancer la bascule une fois le problème résolu. C'est pour cela que le mutualisé doit rester actif pendant la période de recouvrement.

Vous n'avez pas encore tranché ? Notre article VPS ou hébergement mutualisé détaille les cas où la migration se justifie.

Vous migrez plusieurs sites vers le même VPS ? Préparez l'arborescence et l'isolation à l'avance : configuration multi-sites avec Nginx.

Retour à la documentation