Migrer WordPress vers un autre hébergeur sans perdre vos commandes

9 min de lecture

Une migration de WordPress vers un autre hébergeur, avec le même domaine, doit préserver les commandes, leurs paiements et les mises à jour de stock. Le point critique n’est pas la copie : c’est le moment où l’ancien serveur cesse d’écrire et où le nouveau devient l’unique autorité.

Une sauvegarde restaure un état passé. Une migration organise la continuité entre deux états. Préparez le nouveau serveur pendant que la boutique reste ouverte, puis gelez les écritures, synchronisez et ouvrez uniquement après validation.

Fixer l’autorité et les accès avant toute copie

Réunissez les accès aux deux hébergements, au DNS et aux services de paiement. Identifiez qui autorise le gel, qui exécute la bascule et qui valide les commandes. Le responsable boutique doit pouvoir refuser la réouverture.

Dressez l’inventaire des versions PHP et WordPress, des extensions, du stockage des commandes, des médias, des tâches planifiées, des expéditeurs de mails et des connexions logistiques. Ajoutez les webhooks entrants et sortants, les API modifiant le stock et les données stockées ailleurs.

WordPress demande de sauvegarder les fichiers du site et sa base avant un changement de serveur ^[3]. Une restauration complète nécessite bien ces deux ensembles ^[2]. Vérifiez aussi leur restauration dans un environnement isolé.

Convenez d’une règle d’exploitation : un seul serveur pourra accepter des écritures. Validez les conditions de traitement des données chez le nouvel hébergeur, restreignez les accès aux clones et prévoyez leur suppression après validation.

Copier pour préparer, sans ouvrir une seconde boutique

L’exemple est fictif et ne décrit pas un client de 4SYSTEM : une boutique de pièces détachées reçoit encore des commandes pendant la copie préparatoire. L’ancien site reste la référence. Le clone sert à vérifier l’hébergement, les médias, le panier et les connexions, pas à produire des commandes réelles.

Isolez ce clone avant son premier démarrage : bloquez l’envoi des mails, les paiements réels, les appels logistiques et l’exécution des tâches. Une prévisualisation locale avec le domaine habituel ne constitue pas une protection.

Avec WooCommerce Subscriptions, conserver le même domaine après copie de la base ne déclenche pas le mode staging : les renouvellements peuvent être traités en mode réel ^[9]. Ne vous fiez donc pas au mot « préproduction » dans le panneau d’hébergement.

Conservez les URL publiques habituelles et ajustez la connexion à la base si ses paramètres changent : WordPress distingue le maintien du domaine et le changement de configuration ^[3]. Reportez les mises à jour fonctionnelles : elles compliqueraient le diagnostic et le retour arrière.

Migration de WordPress vers un autre hébergeur : geler puis synchroniser

La copie préparatoire devient périmée dès qu’une nouvelle commande arrive. Pour obtenir l’état de bascule, suivez cet ordre :

1. Fermez le passage de commande et suspendez les modifications du back-office, les imports, les synchronisations et les appels API en écriture. Une simple page de maintenance ne suffit pas.
2. Rapprochez les paiements déjà engagés avec les commandes de l’ancien site. Les notifications en transit doivent y être traitées avant la coupure ou conservées dans une file durable pour un rejeu testé.
3. Vérifiez les possibilités de reprise du prestataire de paiement. Ne confirmez pas la réception d’un webhook sans conservation durable. Sans rejeu documenté ni rapprochement possible, reportez la bascule.
4. Arrêtez les tâches WordPress, les crons de l’hébergement et les files des extensions. Consignez le dernier état autorisé et les événements encore en attente.
5. Constituez la sauvegarde finale, base puis fichiers ; restaurez les fichiers puis la base sur la destination isolée, conformément à l’ordre recommandé par WordPress ^[2].

La synchronisation finale remplace l’état préparatoire par l’ensemble cohérent des données figées, y compris les tables des extensions et les médias récents. Ne recopiez pas seulement les commandes : stocks, comptes, notes et statuts liés doivent suivre. Exigez une preuve du gel et le rapprochement des commandes en attente avant d’autoriser le DNS.

Basculer le DNS sans créer deux sites actifs

Relevez les enregistrements qui dirigent réellement le trafic web : IPv4, IPv6 et éventuel CDN. Vérifiez que la modification prévue ne touche pas les enregistrements de messagerie. Si vous réduisez le TTL, faites-le en amont et notez sa valeur précédente.

Le DNS ne bascule pas tous les visiteurs simultanément. Des caches peuvent encore conduire à l’ancien serveur alors que d’autres atteignent le nouveau. Choisissez donc le nouveau comme autorité d’écriture, indépendamment de ce que voit votre navigateur.

L’ancien serveur doit rester incapable d’accepter des commandes, des callbacks ou des modifications administratives. Maintenez-le en maintenance ; un relais vers la destination n’est acceptable qu’après validation technique du routage et des signatures de webhooks.

Contrôlez HTTPS, le domaine canonique, l’administration et les caches depuis plusieurs accès. L’affichage ne prouve ni que la bonne base répond, ni que tous les paiements la rejoignent. Gardez une preuve de l’adresse serveur contactée.

Recetter la reprise et neutraliser les anciens automatismes

La recette commence avant l’ouverture : connexion administrateur, médias, panier, livraison, taxes et parcours de paiement en mode test, sans encaissement réel sur le clone. Comparez ensuite les commandes témoins et les paiements en attente avec l’état final sauvegardé et les références du prestataire. Vérifiez leurs statuts, notes et stocks associés.

Réactivez les traitements sur le nouveau serveur seulement après cette validation. Contrôlez chaque file avant son lancement pour éviter de rejouer une action déjà exécutée. Le rejeu des webhooks doit contrôler leurs identifiants pour éviter les doubles traitements. Rouvrez les commandes, puis suivez une commande autorisée jusqu’à sa notification et à son traitement logistique.

L’ancien hébergement conserve ses automatismes tant que vous ne les neutralisez pas. Pour Subscriptions, le mode staging n’arrête pas tous les événements programmés, et d’autres extensions peuvent encore envoyer des mails ^[9]. Contrôlez séparément Action Scheduler, WP-Cron, les crons externes et l’expéditeur SMTP. L’arrêt du runner d’Action Scheduler peut aussi bloquer les événements d’autres extensions utilisant cette bibliothèque ^[9].

Documentez les contrôles récurrents dans votre démarche de maintenance et de sauvegardes. Ne supprimez l’ancien environnement qu’après rapprochement des événements différés et confirmation du routage et de l’absence d’écritures résiduelles.

Journal de bascule : des décisions traçables

Le journal suivant propose des entrées remplies pour la boutique fictive. Le pilote technique tient les preuves ; le responsable boutique signe la décision d’ouverture. Les pièces indiquées sont des validations attendues, pas des résultats observés.

Renseignez pour chaque ligne l’heure réelle, l’intervenant et l’emplacement sécurisé de la preuve. Notez les identifiants utiles au rapprochement, jamais les données de carte.

Revenir en arrière sans effacer les nouvelles écritures

Le retour arrière dépend des écritures, pas seulement du fonctionnement du serveur. Appliquez cet arbre de décision :

• Aucune écriture nouvelle sur la destination ? Gardez les deux sites fermés, confirmez cette absence, puis rétablissez l’ancien comme autorité avant de modifier le DNS et de réactiver ses traitements.
• Des commandes, paiements, comptes ou stocks ont changé ? Préservez immédiatement le nouvel état. Privilégiez une correction sur le nouveau serveur ; une ancienne sauvegarde effacerait ces changements.
• Le retour d’hébergement reste nécessaire ? Gelez la destination, sauvegardez son état complet et restaurez cet état récent sur l’ancien serveur isolé. Revalidez les intégrations et les événements en attente avant de lui redonner l’autorité.
• Les deux serveurs ont écrit ? Gelez toutes les écritures sur les deux serveurs selon la procédure ci-dessus, puis conservez leurs états séparément. Faites rapprocher commandes, paiements et actions logistiques avant toute reprise ; aucune fusion SQL improvisée ne garantit leur cohérence.

Un remboursement, un mail ou une expédition déjà déclenchés ne s’annulent pas par restauration. Rapprochez les références du prestataire et les journaux logistiques pour décider quels événements reprendre. Si l’absence de nouvelles écritures n’est pas démontrable, traitez le cas comme une reprise après écritures.

Questions fréquentes

Un webhook arrive sur l’ancien serveur après l’ouverture : que faire ?

N’essayez pas de réactiver sa boutique pour traiter ce seul événement. Vérifiez si le prestataire prévoit une nouvelle tentative et si la notification figure dans votre file durable. Rapprochez sa référence avec le paiement enregistré sur le nouveau site, puis appliquez le mécanisme de reprise testé. Sans preuve suffisante, gardez le cas en vérification manuelle.

Peut-on garder l’ancien hébergement uniquement pour les mails ?

Oui, si les boîtes et leurs enregistrements DNS restent volontairement chez ce prestataire. Séparez alors le maintien de la messagerie de celui de WordPress : l’application ancienne, ses tâches et son envoi automatique doivent rester neutralisés. Vérifiez les dépendances du contrat avant résiliation et testez réception, envoi et authentification depuis le service retenu.

Un panier ouvert avant le gel peut-il être garanti ?

Pas avec la seule copie des commandes. Un panier peut dépendre de sessions, de cookies ou d’un stockage externe dont la reprise doit être vérifiée. Prévenez les acheteurs du gel et testez ce cas sur la destination. Ne confondez pas panier abandonné et paiement engagé : ce dernier exige un rapprochement avant de demander au client de recommencer.

Préparer la prochaine bascule

Commencez par remplir l’inventaire des écritures et attribuer les décisions du journal. Planifiez ensuite le gel seulement lorsque la copie isolée et la reprise des notifications sont validées. Si personne ne peut confirmer l’autorité unique ou préserver les commandes apparues après ouverture, différez la bascule. Pour cadrer cette préparation, vous pouvez consulter les services web de 4SYSTEM.

Sources

• Backups : Advanced Administration Handbook | Developer.WordPress.org (consulté le 2026-10-08)
• Migrating WordPress : Advanced Administration Handbook | Developer.WordPress.org (consulté le 2026-10-08)
• How Subscriptions Handles Staging Sites and Migrations Documentation - WooCommerce (consulté le 2026-10-08)