Une migration de serveur réussie ne consiste pas à copier des fichiers puis à changer les DNS. Il faut déplacer un système vivant : site, base de données, courriels transactionnels, tâches planifiées, certificats, intégrations et nouvelles commandes qui continuent d’arriver.
L’objectif réaliste est de réduire l’interruption à un niveau acceptable, de prévenir la perte de données et de pouvoir revenir rapidement en arrière.
Pourquoi change-t-on de serveur?
Documentez le problème à résoudre : performance, fiabilité, coût, soutien, conformité, capacité ou fin de vie technologique. Définissez ensuite des critères mesurables. Sans cela, la migration peut déplacer les mêmes problèmes vers une nouvelle infrastructure.
Ce qu’il faut inventorier avant la migration
- domaines, sous-domaines, DNS et responsables des accès;
- code, fichiers téléversés, bases de données et volumes;
- versions de PHP, Node, base de données et extensions;
- certificats, redirections, règles serveur et tâches planifiées;
- formulaires, paiements, CRM, API, webhooks et services externes;
- courriels transactionnels, sauvegardes, surveillance et journaux;
- données qui peuvent changer pendant la transition.
Consignez aussi les personnes capables de valider chaque fonction. Une migration technique ne peut pas confirmer seule qu’un paiement, une réservation ou un formulaire produit le bon résultat d’affaires.
Les questions à poser avant de signer avec l’hébergeur
Demandez où résident les données et sauvegardes, quels engagements de disponibilité existent, comment fonctionne le soutien, qui gère les mises à jour, quels accès sont fournis, comment restaurer une sauvegarde et comment quitter le service. Validez les limites de calcul, stockage, bande passante, envoi de courriel et nombre de fichiers.
Migration directe ou environnement parallèle?
Pour un site important, préparez le nouveau serveur en parallèle. Le site actuel reste public pendant l’installation et les tests. Une migration directe peut convenir à un petit site statique, mais elle offre moins de marge et rend le retour arrière plus difficile.
Préparer le nouvel environnement
Installez les bonnes versions, appliquez les réglages de sécurité, configurez les sauvegardes et la surveillance, puis importez une première copie. Ne placez pas de secrets dans le dépôt. Générez ou transférez les variables d’environnement par un canal sécurisé et limitez les accès au strict nécessaire.
Tester sans rendre le nouveau serveur public
Utilisez un domaine de préproduction protégé ou une résolution locale du domaine. Assurez-vous que l’environnement de test ne soit pas indexable et qu’il n’envoie pas de vrais courriels ou paiements. Certaines applications dépendent du nom de domaine; testez donc également avec le domaine final résolu localement lorsque c’est possible.
Préparer une matrice de compatibilité
| Composant | Ancien | Nouveau | Validation |
|---|---|---|---|
| Langage et extensions | Version actuelle | Version cible | Tests automatisés et pages clés |
| Base de données | Moteur/version | Moteur/version | Import, encodage, requêtes |
| Serveur web | Règles actuelles | Configuration cible | Redirections et en-têtes |
| Tâches planifiées | Liste actuelle | Planificateur cible | Exécution contrôlée |
La liste de tests avant la bascule
- pages principales, recherche, connexion et administration;
- formulaires, pièces jointes et messages de confirmation;
- panier, taxes, paiement, remboursement et inventaire;
- API, webhooks, CRM, analytics et gestionnaire de balises;
- redirections, pages 404, sitemap et robots.txt;
- HTTPS, en-têtes de sécurité, permissions et sauvegarde restaurable;
- performance mobile et charge sur les parcours critiques.
Comment gérer les nouvelles données pendant la transition?
Choisissez explicitement une stratégie : courte période de maintenance, base de données répliquée, synchronisation finale ou gel temporaire de certaines fonctions. Pour un commerce, ne faites jamais une seconde importation qui écrase silencieusement les commandes arrivées sur le nouveau serveur. Définissez la source d’autorité pour chaque type de donnée.
Préparer la bascule DNS
Réduisez le TTL suffisamment à l’avance, confirmez l’accès au registraire et exportez la zone DNS. Ne modifiez que les enregistrements nécessaires. Le DNS du site et celui du courriel sont liés dans la même zone : une mauvaise manipulation des enregistrements MX, SPF, DKIM ou DMARC peut perturber les courriels même si le site fonctionne.
Définir un vrai plan de retour arrière
Le plan doit préciser le seuil de décision, la personne autorisée à revenir en arrière, les changements DNS à annuler, la façon de préserver les nouvelles données et la durée pendant laquelle l’ancien serveur reste disponible. Testez la restauration avant la bascule; une sauvegarde non restaurée n’est qu’une hypothèse.
Que surveiller pendant les 72 premières heures?
- disponibilité, temps de réponse, erreurs 4xx et 5xx;
- utilisation du processeur, mémoire, disque et connexions;
- transactions, formulaires, courriels et tâches planifiées;
- certificat HTTPS, DNS et webhooks;
- journaux applicatifs, sécurité et anomalies de trafic;
- données Analytics comparées à une période normale.
Quand fermer l’ancien serveur?
Attendez la fin de la fenêtre de surveillance, la propagation DNS, la validation des données et la confirmation des responsables métiers. Conservez une sauvegarde finale conforme à votre politique de rétention, puis révoquez les accès et secrets devenus inutiles.
Les erreurs les plus coûteuses
- migrer sans inventaire ni responsable de validation;
- tester seulement la page d’accueil;
- oublier les données créées pendant la copie;
- changer toute la zone DNS à la fois;
- découvrir après la bascule que les courriels ou tâches planifiées ne fonctionnent plus;
- fermer l’ancien serveur avant la fin de la validation;
- ne pas disposer d’un retour arrière chronométré.
Vous préparez une migration? Beriox peut construire le plan de tests, coordonner la bascule et surveiller les fonctions critiques afin de réduire le risque opérationnel.