Hetzner ou VHosting pour migrer WooCommerce sans perdre les commandes récentes

Conserver une seule boutique qui accepte les commandes

Une boutique prépare une migration WordPress pendant que les ventes continuent. Le premier export sert à monter une copie et à vérifier les versions de PHP, le thème et les extensions. Pendant ce travail, l’ancienne boutique reçoit de nouvelles commandes. Des paiements et des remboursements peuvent aussi changer l’état de commandes qui existaient déjà au premier export. Une copie qui s’ouvre dans le navigateur peut donc être prête sur le plan technique tout en étant en retard sur les ventes.

L’équipe choisit dès le départ l’instance qui fait foi. Tant que la recette n’est pas validée, la boutique d’origine accepte seule les commandes. La cible reste privée ou incapable d’accepter des écritures réelles. Les essais utilisent des comptes fictifs et un circuit de paiement en bac à sable. Avant d’importer les données finales, prévoyez la suppression de ces essais ou utilisez une base vide distincte pour la version destinée à la production.

Fixez deux repères datés dans le même fuseau. T0 désigne le premier export, T1 le point auquel les écritures ont été arrêtées ou traitées et la base finale est exportée. Préparez un registre minimal des écarts entre ces repères. Relevez les références de commande, l’heure, la devise, les montants, le statut et les identifiants de transaction nécessaires au rapprochement. Limitez l’accès aux exports et évitez d’utiliser des données de clients dans une maquette.

Inventorier trois périmètres de reprise

Les fichiers comprennent le code, le thème, les extensions et les médias. Ils portent aussi des réglages propres à l’environnement dans des fichiers comme `wp-config.php`. Une reprise de médias ou de code peut être réalisée séparément si les versions restent compatibles. Un fichier d’origine ne doit pas remplacer les identifiants de connexion ou les clés propres à la cible. Vérifiez les documents téléchargeables ou pièces associées à des extensions dont les liens peuvent dépendre d’un dossier ou d’un stockage externe.

La base comprend les commandes et leurs relations, mais aussi les produits, les réglages, les comptes et les tâches différées. Relevez le stockage des commandes WooCommerce qui fait autorité et vérifiez si HPOS est utilisé avec ou sans compatibilité. Dans WooCommerce, le mode de compatibilité synchronise deux représentations sur une même boutique. Il ne réconcilie pas les écritures de deux boutiques distinctes après une bascule.

Le troisième périmètre est le journal des changements intervenus depuis T0. Comparez l’état des anciennes commandes aussi bien que la liste des nouvelles. Il faut pouvoir expliquer les lignes d’articles, les statuts et les événements de paiement, ainsi que le stock ou les effets d’extensions lorsqu’ils font partie du scénario. Une reprise complète depuis une sauvegarde antérieure à T1 risque d’effacer ces changements. Le choix de la source et du point de reprise doit donc précéder la commande de restauration.

Hetzner Webhosting et les destinations de restauration

Le guide Webhosting S, M, L et XL annonce une sauvegarde nocturne conservée quatorze jours dans un autre centre de données. Dans konsoleH, sélectionnez le compte concerné, puis Services et Backup. Choisissez la date et le périmètre. Pour `public_html`, le guide décrit la sélection de fichiers ou de sous-répertoires et la possibilité de les restaurer dans un nouveau dossier. Il décrit aussi des opérations qui écrasent ou suppriment des fichiers existants. Pour une recette, la destination séparée permet de comparer le fichier avant de le copier au bon endroit.

La restauration de la base est un autre choix. Hetzner documente la création d’une nouvelle base à partir de la copie et l’écrasement d’une base existante. Pour un SQL provenant d’un autre hébergeur, le guide de migration propose de créer une base vide, d’importer le fichier puis d’actualiser la connexion WordPress. PhpMyAdmin convient à un import compatible avec les limites de l’interface. Hetzner recommande la ligne de commande pour les fichiers plus lourds lorsque l’offre donne accès à SSH. SFTP permet de transférer les fichiers, mais ne fournit pas un terminal.

Le 10 novembre 2026, les plafonds mensuels de la grille en EUR sont de 1,60 pour S, 4,12 pour M, 8,32 pour L et 16,72 pour XL, hors TVA. Pour un client résidant en France sans numéro de TVA intracommunautaire valide, les plafonds calculés avec 20 % de TVA s’établissent à 1,92, 4,94, 9,98 et 20,06 EUR TTC. La facturation à l’heure jusqu’au plafond concerne les mois partiels. Vérifiez la TVA applicable à votre compte et le prix du domaine. SSH figure sur L et XL, alors que S et M doivent être évalués avec la voie panneau et le traitement local du SQL. S prévoit une seule base. Vérifiez le quota si vous voulez conserver une base de production et une base d’essai dans le même compte. Le domaine et les frais éventuels suivent leur propre échéance.

VHosting Cloud WordPress et le périmètre de JetBackup

La grille WordPress annonce JetBackup quotidien. Les plans 01 et 02 affichent trente jours de rétention pour les fichiers et la base. Les plans 03 et 04 en affichent soixante. La rétention du courrier, quatorze jours sur ces cartes, est distincte. La page mentionne aussi une réplication horaire pour la reprise d’infrastructure. Vérifiez le point disponible dans JetBackup pour l’application, car la durée de rétention et la réplication ne donnent pas l’heure du dernier export exploitable de vos commandes.

Dans cPanel, le guide VHosting ouvre JetBackup 5 puis Restore & Download. La section Home Directory permet de choisir une date et une sélection de fichiers. La section Databases permet de sélectionner une base et sa copie. Préférez le téléchargement puis l’import dans une base vide lorsque vous avez besoin d’une destination distincte. Le guide cPanel documente la création de bases et l’import ou l’export avec phpMyAdmin. Les cartes WordPress affichent SSH. Il reste à vérifier l’utilisateur, les permissions et les limites sur le compte.

Le 10 novembre 2026, VHosting affiche 47 et 62 EUR HT par an pour Cloud WordPress 01 et 02, puis 73 et 89 EUR HT par an pour Cloud WordPress+ 03 et 04. La FAQ annonce un prix reconduit hors remise de première année. Les conditions générales prévoient le tarif en vigueur au renouvellement et la possibilité d’une révision. Vérifiez le montant dans le récapitulatif de renouvellement. Le domaine éventuellement offert la première année est facturé séparément au renouvellement. Le tarif publié de 25 EUR plus TVA concerne la restauration exécutée par l’équipe VHosting sur un service actif. Le téléchargement autonome des sauvegardes disponibles n’est pas facturé par cette prestation. L’offre de migration entrante couvre un site éligible. La page décrit une copie par extension ou par transfert des fichiers et de la base, à demander dans les trente jours suivant l’achat. Elle demande les accès à la source et exclut notamment WordPress Multisite. Confirmez à l’avance quels accès temporaires suffisent. Planifiez séparément le traitement des commandes et paiements qui arrivent après cette copie.

Fermer la fenêtre de divergence avant l’export final

Fixez avec l’équipe boutique et l’opérateur du paiement l’heure de fermeture des nouvelles commandes. Identifiez aussi les créations par API, les tâches d’abonnement, les imports du stock et les modifications manuelles. Le mode maintenance du site ne suffit pas si ces canaux continuent à écrire. Les paiements en cours demandent un traitement explicite. Certains événements arrivent après la fermeture de la page de paiement. Gardez un circuit de réception contrôlé ou une file prévue pour la reprise, selon les capacités du prestataire. Vérifiez les transactions en cours et les erreurs de notification avant de fixer T1.

Quand les écritures sont arrêtées ou rapprochées, exportez une base finale cohérente depuis l’instance qui fait foi. Consignez la date de capture, les tables, la méthode et l’empreinte du fichier. Si possible, comparez l’export aux commandes, au registre du paiement et au stock. Comparez les totaux par devise et ne déduisez pas d’un total égal que toutes les lignes sont présentes. Contrôlez aussi les états des anciennes commandes modifiées et les références de transactions qui permettent de rapprocher les notifications.

Importez cette base finale dans une destination isolée, sans écraser l’ancienne boutique ou une cible qui aurait déjà reçu des ventes. Cette méthode garde les relations qui existent dans la source. Si le délai impose une migration par incréments, testez un outil compatible avec la version et les extensions qui sait rejouer des événements sans doublonner. Le simple filtrage sur la date de création ou le numéro de commande ne couvre pas les modifications tardives.

Vérifier les données et les effets avant la réouverture

Contrôlez l’ordre des versions. La première copie peut avoir utilisé un thème de test ou une extension mise à jour qui a changé le schéma. Vérifiez la compatibilité avec le dernier export de la source avant de connecter le WordPress cible. Préparez les médias ajoutés depuis T0 et vérifiez qu’un import de base ne remet pas le site sur l’ancienne adresse. Conservez une copie des réglages propres à chaque environnement avant tout remplacement ciblé.

Dans la cible encore fermée, ouvrez des commandes témoins. Vérifiez l’article, la quantité, le statut, la devise et le montant. Vérifiez le stock attendu et les effets des extensions pertinentes, notamment les autorisations de téléchargement, les notes, les remboursements ou le suivi d’expédition. Comparez aussi les files de tâches avec l’équipe d’exploitation. Une copie peut avoir récupéré une tâche destinée à envoyer une notification ou lancer une expédition. Réactivez les circuits réels uniquement sur l’instance désignée.

Les critères d’arrêt sont fixés avant l’essai. Un événement de paiement sans commande expliquée, une commande sans ses lignes, un stock incohérent, un export incomplet ou un doute sur les écritures de la cible bloquent la réouverture. Gardez les journaux et les deux états accessibles. Un fichier média manquant peut se corriger sans restauration de base si le code et les références restent compatibles. Vérifiez ensuite à nouveau les mêmes témoins.

Rejouer les commandes récentes et la restauration d’un média

Le ZIP fournit un premier export T0, les écritures suivantes et un fichier séparé pour les paiements tardifs. SQLite charge réellement le SQL. La base T0 contient deux commandes. La source reçoit ensuite deux commandes, puis deux confirmations tardives, dont une pour une commande déjà présente. Le scénario contrôle le lien entre les références du paiement fictif et les commandes, avec la devise et le montant. Un candidat qui omet ces événements s’arrête, même s’il possède déjà la liste des quatre commandes.

Le script fabrique un point final puis le restaure dans une base distincte. Il vérifie les lignes, le stock, les totaux séparés en EUR et CHF, ainsi que les contraintes de la base. Une variante retire une ligne tout en conservant les montants et les événements. Elle échoue au rapprochement. Le script répète l’import sur cette destination de recette sans ajouter de doublons. Ce résultat concerne le remplacement d’une base isolée par sa copie et ne démontre pas qu’un import incrémental de commandes serait rejouable.

Le volet fichiers compare deux versions d’un média, copie la version finale dans un dossier temporaire et vérifie que la base et le réglage de la cible sont conservés. Les seize contrôles incluent les trois décisions de retour avant toute nouvelle écriture, après une commande sur la cible et après divergence des deux côtés. Les montants, statuts et événements sont des données fictives. Le modèle SQLite permet de vérifier les différences et les effets d’un écrasement, sans reproduire le schéma ou les tâches de WooCommerce.

• Téléchargez la maquette ZIP dans « Pour aller plus loin », extrayez l’archive dans un dossier séparé puis exécutez python exercice.py.
• Comparez les 16 contrôles au fichier attendu.json. Repérez la commande CIBLE-105, puis la collision entre SRC-105 et CIBLE-105 qui impose un rapprochement avant la reprise.

Organiser le retour avant et après les premières ventes

Avant toute écriture sur la cible, un retour est envisageable si l’ancienne boutique reste exploitable et contient l’état final rapproché. Gardez les deux sites fermés à la prise de commandes pendant le changement de route. Vérifiez le nom public, le certificat, les médias et l’état des commandes sur l’origine avant de rouvrir. Selon la propagation, des visiteurs peuvent encore atteindre la cible. Laissez-la fermée à l’écriture jusqu’à ce que l’équipe ait vérifié le routage.

Après la première vente sur la cible, un retour DNS vers l’ancienne base abandonnerait une partie des données. Fermez les prises de commandes et convenez du traitement des notifications en cours. Exportez les deux bases et conservez les références de paiement, les données d’exécution des tâches et les éléments de stock utiles. Si la cible est devenue la seule source des écritures et qu’elle est cohérente, la reprise peut consister à reconstruire l’ancien environnement à partir de cet état dans une copie isolée. Rejouez ensuite les contrôles avant de modifier le routage.

Si les deux côtés ont accepté des écritures, préparez un rapprochement avant toute fusion. Le même identifiant interne peut appartenir à deux commandes différentes. Une référence de paiement ou de boutique permet d’identifier certains cas, mais ne dispense pas de vérifier les lignes, les remboursements et les effets sur les autres systèmes. La maquette marque ce cas comme un arrêt. En exploitation, une fusion demanderait une méthode validée avec les versions et les extensions utilisées, ainsi qu’un moyen d’éviter les doubles notifications, remboursements et expéditions.

Choisir l’offre selon la reprise que l’équipe peut vérifier

Hetzner Webhosting convient lorsque l’équipe veut utiliser les destinations séparées décrites dans konsoleH et peut traiter l’import SQL avec les accès du plan. Le passage de M à L change notamment la disponibilité de SSH. Une fenêtre de sauvegarde de quatorze jours peut suffire pour récupérer le fichier retenu, sous réserve de vérifier l’heure et le contenu. La capture finale de la boutique reste une opération à préparer en dehors de la sauvegarde nocturne.

VHosting convient à une équipe qui veut télécharger un point JetBackup et retrouver des composants séparés dans cPanel. Choisir entre trente et soixante jours peut allonger la fenêtre de récupération des fichiers et de la base. Cette différence ne dit rien sur la présence d’un paiement arrivé quelques minutes avant la bascule. Vérifiez l’offre, les droits cPanel et SSH, la disponibilité de la base de recette et la prestation éventuelle de restauration avant d’établir le coût.

Dans les deux cas, l’accès au panneau n’accorde pas automatiquement l’administration WooCommerce, l’accès au prestataire de paiement ou la modification du DNS. Répartissez ces accès avant le gel. Identifiez la personne qui approuve le dernier export et celle qui décide de rouvrir ou de revenir en arrière. Le meilleur témoin est un ensemble de commandes et d’événements que l’équipe sait retrouver après la restauration, avec le fichier de référence et le bon état du site.

Pour aller plus loin

• Consulter la fiche Hetzner Webhosting
• Consulter la fiche VHosting
• Vérifier la synchronisation des commandes WooCommerce avec HPOS
• Télécharger la maquette de reprise des commandes (ZIP)