Migrer un site ou une app vers un nouveau serveur cloud
Pour migrer vers un serveur cloud en toute sécurité, laissez l'ancienne machine intacte tant que la nouvelle n'a pas servi de trafic réel. Ce guide est un plan pour un site, une boutique ou une application : trois checklists (avant, bascule, retour arrière), des commandes à adapter et des limites honnêtes sur l'indisponibilité. Dimensionnez d'abord la cible avec le guide de dimensionnement des serveurs cloud et choisissez la région avec le guide des emplacements en Europe.
Choisir la méthode de migration
Quatre méthodes couvrent presque tous les déménagements. Beaucoup de projets en combinent deux.
| Méthode | Idéale pour | Risque principal |
|---|---|---|
| rsync des fichiers | Sites statiques, envois, code applicatif | Les données changent pendant la copie, une synchronisation finale est nécessaire |
| Image ou restauration de sauvegarde | Même système et même disposition, restauration testée | Anciens pilotes et noms réseau, volume plus important |
| Redéploiement de l'application | Conteneurs et code dans git | L'état caché de l'ancien disque est oublié |
| Réplication de base de données | Bases volumineuses ou très actives | Effort de mise en place et limites de version |
Partez d'un serveur cloud dès EUR 15.00/mois, vérifié 2026-10 et répétez-y tout le plan.
Checklist avant la migration
- Inventaire - listez services, ports, tâches cron, réglages de messagerie, certificats, règles de pare-feu et chaque nom d'hôte qui pointe vers l'ancienne IP.
- État caché - cherchez les fichiers hors de la racine web : envois, files d'attente, sessions, licences, secrets dans les variables d'environnement.
- Sauvegardes - faites une sauvegarde complète de l'ancien serveur et restaurez-la une fois ailleurs, car une sauvegarde non testée n'est qu'un espoir.
- Accès - clés SSH uniquement, un pare-feu et un utilisateur de déploiement sans droits root sur le nouveau serveur.
- Snapshot - créez un snapshot du nouveau serveur avant la première vraie synchronisation, pour qu'une erreur ne coûte que quelques minutes.
Copier les fichiers et les données
Les exemples utilisent l'adresse de documentation 203.0.113.10 comme nouveau serveur. Remplacez noms et chemins par les vôtres. Les étapes 1 et 2 peuvent être répétées sans danger ; l'étape 5 ne s'exécute qu'une fois l'ancien site en lecture seule.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
L'option --delete supprime sur la cible les fichiers qui n'existent plus à la source. Ne l'utilisez que lors de la dernière exécution, et seulement si vous savez quel côté fait référence.
Tester d'abord avec le fichier hosts
Avant tout changement DNS, faites résoudre le site vers le nouveau serveur par votre propre ordinateur. Ajoutez une ligne au fichier hosts (/etc/hosts, ou C:\Windows\System32\drivers\etc\hosts sous Windows) : 203.0.113.10 example.com www.example.com. L'option --resolve de curl (étape 3) fait de même pour une seule requête. Retirez ensuite la ligne, sinon vous testerez le nouveau serveur pendant des semaines sans le remarquer.
Baisser le TTL DNS et basculer
Abaissez le TTL des enregistrements A et AAAA à environ 300 secondes, au moins une période complète de l'ancien TTL avant le déménagement. Sinon les résolveurs gardent l'ancienne adresse aussi longtemps que l'ancien TTL le permet. Certains résolveurs ignorent un TTL court : attendez-vous à une traîne de visiteurs sur l'ancienne IP pendant des heures (une estimation, pas une mesure).
Checklist de bascule :
- TTL - la valeur réduite est active et l'ancienne a expiré.
- Lecture seule - l'ancien site est en maintenance ou en lecture seule.
- Synchronisation finale - dernier dump de la base et étape 5 du code ci-dessus effectués.
- DNS - les enregistrements A et AAAA pointent vers la nouvelle IP ; ceux du courrier restent inchangés sauf si la messagerie déménage aussi.
- Test rapide - connexion, commande, envoi, e-mail, cron et certificat vérifiés sur le nom public.
- Ancien serveur - laissez-le allumé, joignable et intact.
Checklist de retour arrière
- Seuil - décidez à l'avance ce qui compte comme un échec, par exemple des paiements refusés ou un taux de 5xx, et qui tranche.
- DNS en arrière - repointez les enregistrements vers l'ancienne IP ; avec un TTL bas, la plupart des visiteurs reviennent en quelques minutes à quelques heures.
- Écritures - rouvrez l'ancien site. Si le nouveau a accepté des commandes ou des envois depuis la bascule, exportez-les d'abord et rejouez-les sur l'ancien.
Ce que demande vraiment le zéro interruption
Le zéro interruption dépend de l'architecture de votre application et n'est promis pour aucun projet. Il faut une application sans état, une base qui réplique ou accepte les écritures des deux côtés, un stockage partagé ou répliqué et une bascule testée. Un site classique avec une seule base a généralement une courte fenêtre en lecture seule de quelques minutes.
Après le déménagement
Surveillez pendant au moins une semaine les journaux d'erreurs, le disque, la mémoire, les temps de réponse et la livraison du courrier. Remontez le TTL DNS quand tout est stable. Ne retirez l'ancien serveur qu'après un cycle complet de sauvegardes sur le nouveau ; une sauvegarde hebdomadaire est incluse dans chaque preset. Testez avant de vous engager avec la checklist de la période d'essai ; un court essai peut être possible en écrivant à sales@dcxv.com, à la discrétion de DCXV et sans garantie.
Configurer le serveur cloud de destination ou demander à un ingénieur à propos de la migration.
