Migrer un VPS OVH vers XProvider sans downtime

On reçoit beaucoup de migrations depuis OVH — généralement parce que le support d'OVH a mis 3 jours à répondre sur un ticket, ou parce que le manager client a encore eu un bug. Voici la procédure qu'on suit pour migrer sans downtime visible côté utilisateur.

Si tu ne veux pas le faire toi-même : migration gratuite sur toutes nos offres VPS Pro et au-dessus. On s'occupe de tout.

Avant de commencer : inventaire

Liste ce que tu as sur ton VPS actuel. Sans inventaire, tu vas oublier un cron, un worker, une app qui tourne dans un screen.

OS et version du kernel
Services en écoute : ss -tlnp
Process persistants : systemctl list-units --type=service --state=running
Crons : crontab -l -u <chaque-user>
Bases de données : noms, tailles, users
Certificats SSL : certbot certificates
Volumes montés : df -h et /etc/fstab
Firewall actif : iptables -L -n ou ufw status

Étape 1 : commander le nouveau VPS

Prends une offre XProvider dimensionnée correctement — pas juste la même que chez OVH. Le CPU Ryzen 9 7950X qu'on utilise est environ 40% plus rapide que le Xeon d'OVH en mono-cœur. Pour des services web standards, tu peux descendre d'un palier.

Choisis le même OS pour simplifier : Debian 12 ou Ubuntu 24.04 LTS. Récupère l'IP du nouveau VPS dans l'espace client dès que la machine est provisionnée.

Étape 2 : réduire le TTL DNS

Fais-le 24h à l'avance minimum. Si ton TTL actuel est à 3600 (1h) ou plus, tu vas traîner une fenêtre de propagation au moment du switch.

Passe le TTL à 300 (5 minutes) pour tous les enregistrements A et AAAA concernés. Quand tu swapperas l'IP, la propagation sera complète en 5-10 min.

example.com.     300  IN  A      <ip-ovh>
api.example.com. 300  IN  A      <ip-ovh>

Étape 3 : installer les services sur le nouveau VPS

Classe les services en deux piles :

Stateless (nginx, apache, ton app, workers) : tu peux les installer et les configurer dès maintenant sur le nouveau VPS. Ils ne stockent rien de critique, juste du code et de la config.

Stateful (bases de données, redis, volumes utilisateur) : tu vas les synchroniser au dernier moment.

Pour la config nginx/apache/php-fpm, copie les fichiers tels quels depuis OVH, ça marche directement en général.

Étape 4 : synchroniser les données

Pour les fichiers utilisateur (uploads, médias, etc.) :

rsync -avz --delete \
  -e 'ssh -p 22' \
  /var/www/example.com/uploads/ \
  root@<ip-xprovider>:/var/www/example.com/uploads/

Fais ce rsync deux fois :
1. Maintenant, avec tout le volume → long premier transfert
2. Au moment du switch, avec le delta → rapide

Pour MySQL/MariaDB :

mysqldump --single-transaction --routines --triggers \
  --databases mydb | gzip > mydb.sql.gz
scp mydb.sql.gz root@<ip-xprovider>:/root/
# Sur XProvider :
zcat mydb.sql.gz | mysql

Pour PostgreSQL, utilise pg_dump avec la même logique.

Étape 5 : tester avant le switch

Avant de toucher au DNS, teste ton service sur le nouveau VPS avec un /etc/hosts local :

<ip-xprovider>  example.com api.example.com

Tu parcours ton site, tu testes les formulaires, les paiements (en mode sandbox), les webhooks. Tout doit fonctionner parfaitement à ce stade.

Étape 6 : le switch DNS

J-0, heure creuse (2h du matin en semaine idéalement) :

Re-sync final des données stateful (rsync + dump DB)
Stop des writes sur OVH : mets ton app en mode maintenance 2 minutes
Dernière sync pour capter les dernières transactions
Switch DNS : change l'IP dans ton provider DNS
Génère les certs SSL sur XProvider : certbot --nginx -d example.com
Surveille : logs nginx, erreurs app, métriques externes

Tu dois voir le trafic arriver sur XProvider en 5-10 min. OVH va continuer à recevoir du résiduel pendant 1-2h (caches DNS clients mal configurés).

Étape 7 : garde OVH en backup 7 jours

Ne résilie pas OVH tout de suite. Garde-le en lecture seule pendant 7 jours pour :

Récupérer d'éventuelles données oubliées
Avoir un rollback immédiat si un bug majeur apparaît
Vérifier que toutes les notifications externes (webhooks) pointent bien vers le nouveau

Après 7 jours sans incident, résilie OVH proprement depuis leur manager.

Checklist post-migration

[ ] HTTPS fonctionne avec Let's Encrypt renouvelé
[ ] Mails transactionnels partent (test avec mail-tester.com)
[ ] Cron jobs s'exécutent
[ ] Backups automatiques actifs sur Proxmox
[ ] Monitoring externe (Uptime Kuma, Better Stack) reconfigure sur nouvelle IP
[ ] Webhooks externes (Stripe, GitHub, etc.) pointent vers nouvelle URL
[ ] Logs d'erreurs checkés pendant 48h

En cas de pépin

Tu peux revenir en arrière à tout moment en changeant l'IP DNS pour pointer à nouveau sur OVH — c'est pour ça qu'on garde le TTL à 300. Aucune donnée n'est perdue.

Et si vraiment tu bloques, notre support répond en 30 min maxi en journée : contact@xprovider.fr ou Discord.