Migrer un site vers un VPS : guide étape par étape

Sur un hébergement mutualisé, le prestataire gère le serveur web, PHP, la base de données, la messagerie, les sauvegardes et les mises à jour de sécurité. Sur un VPS non infogéré, tout cela vous revient. L’avantage : le contrôle et des ressources prévisibles ; la contrepartie : rien n’est configuré tant que vous ne l’avez pas fait. Organisez la migration en deux projets : construire le serveur, puis y déplacer le site.

Partez d’une version de Linux prise en charge. Les commandes ci-dessous valent pour Ubuntu ou Debian ; adaptez les noms de paquets pour les autres distributions.

# Updates and a non-root user with sudo
apt update && apt upgrade -y
adduser deploy && usermod -aG sudo deploy

# Firewall: SSH, HTTP and HTTPS only
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

# Automatic security updates
apt install -y unattended-upgrades

Connectez-vous avec une clé SSH, puis désactivez la connexion SSH par mot de passe. Installez la pile dont le site a besoin, par exemple nginx ou Apache, PHP-FPM dans la même version et avec les mêmes extensions que chez l’ancien hébergeur, et MySQL ou MariaDB. Garder la même version de PHP évite les surprises ; mettez-la à niveau plus tard, comme une étape à part.

1. 1

   Étape 1 : Réduire le TTL

   Passez les enregistrements A à un TTL de 300 secondes la veille de la bascule. Vérifiez la valeur actuelle avec le vérificateur de TTL.

2. 2

   Étape 2 : Sécuriser le VPS et installer la pile

   Appliquez les mises à jour, créez un utilisateur sudo, activez les clés SSH et un pare-feu, puis installez les versions du serveur web, de PHP et de la base de données dont le site a besoin.

3. 3

   Étape 3 : Copier les fichiers

   Copiez le site avec rsync -avz via SSH, ou téléchargez une archive depuis l’ancien hébergeur et envoyez-la sur le VPS. Attribuez la propriété à l’utilisateur du serveur web.

4. 4

   Étape 4 : Importer la base de données

   Exportez-la chez l’ancien hébergeur, créez une base de données et un utilisateur sur le VPS, importez le dump et mettez à jour la configuration de l’application avec les nouveaux identifiants.

5. 5

   Étape 5 : Configurer l’hôte virtuel

   Ajoutez un bloc server pour le domaine et www, traduisez les éventuelles règles .htaccess et rechargez le serveur web.

6. 6

   Étape 6 : Tester sur l’IP du VPS avant le DNS

   Créez un lien d’aperçu avec le domaine et l’IP du VPS, et utilisez le mode HTTP uniquement ou Ignorer la vérification jusqu’à l’installation d’un certificat. Parcourez le site, envoyez des formulaires, connectez-vous.

7. 7

   Étape 7 : Lancer un rapport QA

   Explorez l’aperçu avec un rapport QA pour repérer les pages par défaut du serveur web, les erreurs 502 de PHP-FPM, les règles de réécriture manquantes et les erreurs PHP.

8. 8

   Étape 8 : Basculer les DNS et émettre le certificat

   Faites une synchronisation finale des fichiers et de la base, faites pointer les enregistrements A vers le VPS, puis émettez le certificat et suivez la propagation avec le vérificateur de propagation DNS.

Le serveur web choisit le site d’après le nom de domaine de la requête. Configurez un bloc server pour example.com et www.example.com :

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.php index.html;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Si le site s’appuyait sur des règles .htaccess chez l’ancien hébergeur, traduisez-les pour nginx : URL propres, redirections et restrictions d’accès ne suivent pas d’elles-mêmes. Adaptez le chemin du socket PHP-FPM à la version installée. Testez la configuration avec nginx -t avant chaque rechargement, et vérifiez les réglages du pool PHP-FPM : le nombre de processus par défaut est faible, et un site très fréquenté qui en manque répond avec des erreurs 502 ou 504.

Le challenge HTTP habituel de Let’s Encrypt ne fonctionne qu’une fois le domaine pointé vers le VPS. Vous avez trois options : émettre le certificat juste après la bascule (quelques minutes en HTTP simple ou avec un certificat auto-signé), utiliser le challenge DNS, qui fonctionne avant la bascule si votre fournisseur DNS propose une API, ou copier le certificat existant depuis l’ancien hébergeur.

Pour les tests, un VPS neuf sans certificat fonctionne avec un aperçu DNSPeek en mode HTTP uniquement : les visiteurs ouvrent toujours l’aperçu en HTTPS, et DNSPeek parle en HTTP simple au serveur. Faites d’abord en sorte que l’application fasse confiance au HTTPS du proxy, sinon une redirection forcée vers HTTPS tournera en boucle. La documentation donne les réglages PHP et nginx : Origine sans SSL.

Si l’ancien hébergeur mutualisé gérait aussi votre messagerie, la migration est le bon moment pour les séparer. Bien faire tourner un serveur de messagerie (filtrage du spam, réputation, DKIM, listes de blocage) est un métier à part entière, et de nombreux fournisseurs cloud bloquent par défaut le port 25 sortant. Transférez les boîtes mail chez un prestataire de messagerie dédié, mettez à jour MX, SPF, DKIM et DMARC, et faites envoyer les e-mails transactionnels du site via un service SMTP authentifié. Vérifiez les enregistrements avec la recherche MX, le vérificateur SPF et le vérificateur DMARC.

• Émettez ou vérifiez le certificat et contrôlez-le avec le vérificateur SSL.
• Mettez en place des sauvegardes qui quittent le serveur : dumps de la base et fichiers, vers un stockage objet ou une autre machine, et testez une restauration.
• Ajoutez une supervision de base : disponibilité, espace disque et expiration du certificat.
• Recréez les tâches cron de l’ancien hébergeur.
• Suivez la checklist après migration.