Si WooCommerce est retenu comme plateforme cible, la préparation doit considérer la boutique comme une application e-commerce fonctionnant dans WordPress. Products et variations partagent l’infrastructure WordPress avec les contenus, mais leur sens métier vient de WooCommerce et de ses extensions. Les Orders peuvent utiliser High-Performance Order Storage ou le stockage historique des publications WordPress. Les Customers peuvent être des utilisateurs WordPress enregistrés ou des identités transactionnelles invitées. Abonnements, réservations, bundles, adhésions, tarifs de gros, champs personnalisés du processus de commande et données marketplace peuvent résider dans des structures propres aux extensions.
Le dossier de préparation doit expliquer où chaque donnée e-commerce est stockée, de quelles relations Product ou transaction elle dépend et quel système détient le fonctionnement qui doit continuer. Il doit comprendre des sauvegardes restaurables, les paramètres de stockage actuels, des éléments de compatibilité des extensions, des données représentatives et une condition de préparation finale pour chaque domaine important. Les contenus CMS WordPress restent connectés, mais ne sont pas dupliqués dans le périmètre WooCommerce.
Établir le périmètre WooCommerce, les accès et l’instantané source
Commencez par séparer les données WooCommerce natives des données CMS WordPress, des données e-commerce détenues par des extensions et des systèmes externes. Confirmez l’URL de la boutique source, l’installation WordPress ou le site Multisite, la version WooCommerce active, le thème actif, les extensions activées, le code personnalisé et les systèmes de référence actuels pour Products, stock, Customers, Orders, tarification, taxes, expédition, paiement et traitement des commandes.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Définir le périmètre e-commerce WooCommerce | Propriétaire de la boutique et responsable technique | Liste d’entités couvrant Products, variations, Customers, Orders, coupons, avis, remboursements, téléchargements, extensions et systèmes externes | Chaque donnée e-commerce a un propriétaire : cœur, extension, système externe, archive ou exclusion. |
| Confirmer les accès d’administration et d’hébergement | Administrateur et responsable d’hébergement | Accès administrateur WordPress/WooCommerce, accès base ou voie d’export, fichiers uploads/téléchargements et accès aux extensions | L’équipe peut examiner des données sélectionnées et restaurer la source si nécessaire. |
| Capturer le WooCommerce System Status Report | Responsable technique | Rapport daté avec WooCommerce, WordPress, PHP, base, thème, surcharges de modèles, extensions et environnement | Le contexte logiciel et extensions est enregistré avant les changements. |
| Créer un instantané complet de la source | Responsable hébergement ou base | Sauvegarde datée de la base, fichiers wp-content, téléchargements Product, médias, références de configuration et responsable de restauration |
Périmètre, date, emplacement, procédure de restauration et conservation sont documentés. |
| Enregistrer les systèmes externes de référence | Responsables des intégrations | Carte des identifiants ERP, PIM, WMS, CRM, fiscalité, paiement, expédition, traitement, marketplace et comptabilité | Systèmes de référence durables et clés utilisées sont explicites. |
Si la boutique source continue d’évoluer, enregistrez l’heure de l’instantané et les types de données susceptibles d’être créés ou modifiés ensuite. Ce journal de changements préserve la frontière source et identifie les données pouvant exiger un nouvel instantané.
Inventorier types de Products, attributs, variations et identité vendable
Le cœur WooCommerce prend en charge les fonctionnements simple, groupé, externe/affilié, variable, virtuel et téléchargeable, tandis que les extensions peuvent ajouter abonnements, réservations, bundles, Products composites, adhésions, acomptes, personnalisation de Products, règles de gros et propriété marketplace. Inventoriez chaque type réellement utilisé et nommez le composant qui le détient.
Les Products variables exigent une attention particulière. Des attributs globaux ou propres au Product peuvent définir les variations, et chaque variation peut porter son SKU, ses identifiants, son état activé, son prix normal ou promotionnel, son coût, son état virtuel/téléchargeable, son poids, ses dimensions, sa classe d’expédition, sa classe fiscale, son image, son stock, sa règle de rupture et son seuil de stock faible.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Inventorier les types de Products | Responsable catalogue | Comptages et exemples par type simple, groupé, externe, variable, virtuel, téléchargeable et détenu par extension | Chaque type actif a une représentation cible ou une exclusion intentionnelle. |
| Cartographier l’identité des Products et variations | Responsables catalogue et intégration | IDs parents, IDs de variations, SKUs, GTIN/UPC/EAN/ISBN utilisés, clés externes et rapport de doublons | Chaque article vendable peut être distingué et rapproché entre systèmes connectés. |
| Documenter attributs et génération de variations | Responsable catalogue | Attributs globaux, personnalisés, valeurs de termes, attributs par défaut, combinaisons et modèles « Any attribute » | Vocabulaires d’attributs et vraies combinaisons vendables sont connus avant la mise en correspondance. |
| Capturer les données commerciales au niveau variation | Responsables catalogue et stock | Prix, promotion, image, stock, rupture, poids, dimensions, taxe, classe d’expédition et téléchargement de variations représentatives | Les valeurs commerciales sont intentionnellement attribuées au parent ou à la variation. |
| Enregistrer la responsabilité des Products avancés | Responsable extension | Nom/version de l’extension, sous-type, tables/meta personnalisées, Products liés et fonctionnement opérationnel | Abonnement, réservation, bundle, composite, add-on, gros ou marketplace dispose d’un responsable défini. |
Utilisez des familles de Products représentatives plutôt que de simples exports agrégés. Incluez un Product simple, un Product variable avec plusieurs attributs, un Product virtuel ou téléchargeable le cas échéant et chaque modèle matériel défini par extension.
Préparer stock, prix, taxonomies, médias et fichiers Product
La préparation dépend aussi de la classification, de la responsabilité du stock, du contexte tarifaire, des médias et des fichiers. Categories, étiquettes, attributs globaux, classes d’expédition, classes fiscales, ventes croisées, ventes incitatives, Products groupés et données associées doivent rester distincts. Le stock peut être géré au niveau Product, variation, des deux ou par un entrepôt ou une extension externe.
| Domaine de préparation | Éléments à préparer | Responsable | Condition de préparation |
|---|---|---|---|
| Autorité du stock | Paramètres de stock Product/variation, ruptures, seuils faibles, IDs d’entrepôt externe et responsable de synchronisation | Responsable stock | Chaque article vendable a un parcours de stock de référence déclaré. |
| Prix et promotions | Prix de base/promotion, calendriers, tarification par quantité/groupe, responsable d’extension et contexte de devise | Responsable commercial | Les prix sont classés comme valeurs natives Product/variation, règles d’extension ou valeurs de système externe. |
| Categories et attributs Product | Hiérarchie, slugs des termes, affectations, usage pour variations/filtrage et termes obsolètes | Responsable catalogue | Les taxonomies restent reliées aux bons Products sans fusion de vocabulaires sans rapport. |
| Médias Product | Image mise en avant, galeries, images de variations, texte alternatif, IDs de pièces jointes, actifs distants et rapport de fichiers manquants | Responsables catalogue et médias | Les médias prioritaires sont accessibles avec des relations parentes connues. |
| Fichiers téléchargeables | URL/chemins, règles d’accès, limites, expiration, disponibilité source et liens Product/variation | Responsable produits numériques | Chaque téléchargement conservé dispose d’un fichier accessible et d’un propriétaire Product ou variation défini. |
| Classification expédition et fiscale | Classes, statut virtuel, dimensions, poids et règles d’extension spécifiques | Responsable opérations | Les éléments de classification sont complets sans confondre configuration actuelle et données d’Orders historiques. |
L’exporteur CSV Product peut fournir des éléments utiles, mais il doit être accompagné des inventaires de types de Products, extensions, fichiers et relations. Un CSV plat ne peut pas représenter pleinement chaque structure Product détenue par une extension ou dépendance à un système externe.
Préparer Customers, comptes, adresses et rôles e-commerce
Les Customers WooCommerce peuvent être des utilisateurs WordPress enregistrés ou des acheteurs invités enregistrés dans les Orders. Les Customers enregistrés peuvent avoir adresses de facturation/livraison, métadonnées de compte, historique d’Orders, droits de téléchargement et relations d’extensions. Les rôles WordPress tels que Customer ou Shop Manager définissent l’accès, tandis que des extensions d’adhésion, gros, vendeur, fidélité ou abonnement peuvent ajouter des profils et règles distincts.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Séparer Customers enregistrés et acheteurs invités | Responsable service client | Comptages, échantillons, qualité e-mail/téléphone, IDs de compte et relations Order | Les Orders invités sont préservées sans inventer de comptes, et les Customers enregistrés restent rattachables. |
| Préparer les adresses Customer | Responsable service client | Champs facturation/livraison, extensions multi-adresses, formats pays/région et Customers représentatifs | Les adresses actuelles des comptes sont distinguées des instantanés historiques des Orders. |
| Inventorier rôles et profils commerciaux | Administrateur et responsables d’extensions | Rôles WordPress, capacités personnalisées, profils gros/adhésion/vendeur et données associées | Accès natif et identité commerciale détenue par extension ont des propriétaires séparés. |
| Enregistrer les dépendances d’authentification | Responsable identité | Contexte de hash de mot de passe, connexion sociale, SSO, MFA et références de fournisseur d’identité externe | L’identité Customer reste dans le périmètre même si les identifiants nécessitent une autre voie d’accès. |
| Préparer les champs de confidentialité et consentement | Responsables confidentialité et marketing | Source du consentement, horodatages, préférences, règles de conservation et IDs des systèmes marketing | Les données sensibles et de consentement ont une décision approuvée de destination, archive, masquage ou exclusion. |
Ne fusionnez pas les Customers sur le seul e-mail lorsque foyers, comptes d’entreprise partagés, marketplace, invités ou identités historiques créent de l’ambiguïté. Préparez les candidats au doublon et la règle gouvernant toute consolidation.
Inventorier Orders, remboursements, Coupons, Reviews et contexte historique
Les Orders préservent l’historique transactionnel par leurs lignes, références Product ou variation, attributs sélectionnés, quantités, prix, remises, taxes, expédition, frais, références de paiement, instantanés de facturation/livraison, statuts, notes, remboursements, téléchargements et métadonnées d’extensions. Préparez des exemples montrant le contexte complet, pas seulement les en-têtes et totaux.
Les Coupons sont des données promotionnelles distinctes avec type de remise, montant, restrictions, limites d’utilisation, expiration et relations d’usage. Les Reviews peuvent utiliser les commentaires WordPress plus des métadonnées de note ou d’achat vérifié WooCommerce. Remboursements, retours, abonnements, réservations et Orders marketplace peuvent dépendre de données d’extension supplémentaires.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Inventorier états et historiques d’Orders | Responsables opérations et service client | Comptages et exemples pour pending, processing, completed, canceled, failed, refunded et statuts personnalisés | Chaque statut conservé a un sens historique et un responsable compris. |
| Préparer des Orders complexes | Responsable opérations | Orders avec variations, frais, Coupons, taxes, traitement partiel, notes, remboursements, téléchargements et champs personnalisés | Les échantillons représentent les relations transactionnelles réellement utilisées. |
| Enregistrer références paiement et traitement | Responsables finance et traitement | IDs de transaction, expédition/suivi, entrepôt/export, origine marketplace et clés externes d’Order | Les références historiques sont distinguées de la configuration active. |
| Inventorier remboursements et après-vente | Responsables finance et service client | Remboursements partiels/complets, lignes touchées, montants, motifs, retours et responsable extension | L’historique de remboursement et retour a une destination ou archive définie. |
| Préparer les Coupons | Responsable marketing | Règles actives/historiques, limites, restrictions, expiration, Products/Categories inclus ou exclus et exigences d’historique | Les Coupons sont classés en configuration active, élément historique ou exclusion. |
| Préparer les Reviews | Responsable contenu/service client | Note, auteur, statut, relation Product, sens d’achat vérifié, réponses et décision de modération | Les Reviews commerciales sont séparées des commentaires WordPress ordinaires. |
Les éléments d’Order doivent préserver l’état de la transaction historique. Les prix Product actuels, adresses Customer, méthodes d’expédition, paramètres fiscaux et configurations de passerelles ne doivent pas servir à recréer ou réinterpréter d’anciennes Orders.
Enregistrer la préparation HPOS et du stockage des Orders
High-Performance Order Storage utilise des tables WooCommerce dédiées plutôt que seulement publications et métadonnées WordPress. Une boutique existante peut utiliser HPOS, le stockage historique ou un mode de compatibilité synchronisant les deux. Les extensions et le code personnalisé lisant ou écrivant directement les données Order doivent être identifiés car le stockage de référence peut différer.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Enregistrer le stockage Order de référence | Responsable technique | Paramètre de stockage WooCommerce, statut HPOS, état du mode de compatibilité et System Status daté | L’équipe sait si HPOS ou les tables de publications WordPress font autorité. |
| Enregistrer l’état de synchronisation | Responsable technique | Nombre d’Orders non synchronisées ou élément équivalent lorsque le mode compatibilité est utilisé | Plus aucune ambiguïté sur le datastore contenant l’Order à jour. |
| Inventorier les extensions sensibles à HPOS | Responsables extensions | Déclarations de compatibilité, accès direct SQL/post-meta connu, rapports, exports et code de modification des Orders | Chaque extension importante a une décision de compatibilité ou restructuration. |
| Cartographier les métadonnées Order personnalisées | Responsables opérations/extensions | Noms de clés, objectif, exemples, propriétaire Order/ligne, emplacement et usage recherche/analyse | Les champs importants peuvent être identifiés indépendamment de leur implémentation de stockage source. |
| Capturer les tables Order personnalisées | Responsables base/extensions | Schéma, nombre de lignes, clés parentes, statuts, dates et identifiants externes | Les données Order critiques hors cœur WooCommerce ont une destination ou archive. |
HPOS n’est pas une simple note de version. Il détermine où résident Orders et métadonnées de référence et si le code personnalisé peut les interpréter. La préparation doit résoudre stockage et responsabilité des extensions avant de considérer les extractions d’Orders comme complètes.
Préparer les champs du processus de commande et les éléments de configuration opérationnelle
Processus de commande, paiement, taxes, expédition, traitement, e-mails, comptes et notifications contrôlent le futur fonctionnement de la boutique. Ils doivent être inventoriés parce qu’ils expliquent données source et dépendances, mais la configuration active ne doit pas être traitée comme une donnée ordinaire à migrer.
| Domaine de préparation | Éléments à préparer | Responsable | Condition de préparation |
|---|---|---|---|
| Champs du processus de commande | Nom, type, emplacement, caractère obligatoire, responsable de stockage, usage historique et propriétaire extension/code | Responsable commande | Les champs historiques nécessaires et les champs de configuration future sont séparés. |
| Moyens de paiement | Liste de passerelles, références de transactions, propriété token/vault, dépendances d’abonnement et libellés historiques | Responsable finance | Les éléments de paiement historiques sont dans le périmètre sans supposer la réutilisation d’identifiants ou tokens actifs. |
| Expédition et traitement | Zones, méthodes, classes, intégrations transporteur/entrepôt, suivi, extensions retrait/livraison et références Order | Responsable traitement | Dépendances de configuration et données historiques d’expédition sont classées séparément. |
| Taxes | Taux/classes, service fiscal externe, valeurs fiscales historiques et responsabilité juridictionnelle | Responsable fiscal | Les éléments fiscaux historiques restent séparés de la configuration fiscale actuelle. |
| Notifications et webhooks | Modèles e-mail, déclencheurs de statut, endpoints webhook, files d’attente et auditeurs externes | Responsable opérations/technique | Les processus automatisés créant ou mettant à jour des données e-commerce sont connus. |
| Paramètres de compte et confidentialité | Commande invité, création de compte, conservation des données, téléchargements et outils de confidentialité | Administrateur et responsable confidentialité | Fonctionnement des comptes et données Customer conservées ont des responsables documentés. |
L’objectif est d’identifier le fonctionnement source, les données qu’il produit et le responsable de chaque dépendance devant continuer.
Inventorier extensions, code personnalisé, tables et intégrations externes
Les boutiques WooCommerce dépendent souvent d’extensions pour abonnements, réservations, adhésions, bundles, Products composites, personnalisation de Products, acomptes, tarification de gros, marketplaces, fidélité, points, retours, facturation, fiscalité, expédition et paiement. Construisez un registre d’extensions plutôt que de vous fier uniquement à l’écran des plugins actifs.
| Action de préparation | Responsable | Éléments à préparer | Condition de préparation |
|---|---|---|---|
| Construire un registre d’extensions | Responsable technique | Nom, version, objectif, état actif, entités détenues, tables/meta, actions planifiées et services externes | Chaque extension critique possède un responsable de ses données et de son fonctionnement. |
| Identifier le code personnalisé | Responsable développement | Plugin personnalisé, fonctions du thème, snippets, SQL direct, handlers REST/webhook et modèles WooCommerce modifiés | Le fonctionnement personnalisé qui crée ou interprète des données est documenté. |
| Cartographier les identifiants externes | Responsables intégration | Clés Product, variation, Customer, Order, abonnement, expédition, facture et marketplace | Chaque clé conservée est attachée à l’entité cible représentant le même objet métier. |
| Classer les données générées ou temporaires | Responsable extension | Caches, journaux, sessions, tables transitoires, files, index et données abandonnées | Les données techniques non autoritatives sont volontairement exclues. |
| Enregistrer les dépendances inter-entités | Responsables métier/techniques | Relations Product-abonnement, Customer-adhésion, Order-réservation, vendeur-Product et similaires | Les données liées ne seront pas migrées comme tables déconnectées. |
Les fichiers de plugins ne remplacent pas ce registre. Une extension peut être inactive alors que ses données restent importantes, ou active sans stocker de données appartenant au périmètre de migration.
Préparer contenus WordPress, médias, URL et routes e-commerce
WooCommerce dépend de WordPress pour contenu, médias, utilisateurs, menus et routes. La checklist WooCommerce doit capturer les dépendances orientées commerce sans dupliquer l’inventaire CMS WordPress complet.
| Domaine de préparation | Éléments à préparer | Responsable | Condition de préparation |
|---|---|---|---|
| URL de Products et Categories | Routes prioritaires, slugs, hiérarchie, fil d’Ariane, données canoniques et intention cible | Responsables SEO/catalogue | Chaque route prioritaire a une décision : conserver, modifier, consolider, retirer ou rediriger. |
| Routes boutique, panier, commande, compte et endpoints | Affectations de Pages, slugs d’endpoints, portée langue/site et dépendances plugins | Administrateur et responsable technique | Les routes applicatives sont distinguées des Pages CMS ordinaires. |
| Médias et téléchargements Product | Relations de pièces jointes/fichiers, actifs distants, galeries, images de variations et accès fichiers | Responsables catalogue/médias | Les fichiers et références e-commerce prioritaires sont disponibles. |
| Contenus CMS connectés | Guides d’achat, articles de blog, landing Pages, liens internes, blocs/shortcodes Product et campagnes | Responsable contenu | Le contenu lié au commerce a une responsabilité WordPress et des dépendances de routes connues. |
| SEO et redirections | Responsable métadonnées, source sitemap, règles de redirection existantes, entrées de données structurées et URL à forte valeur | Responsable SEO | Données SEO e-commerce et continuité des routes ont des responsables explicites. |
| Langues ou Multisite | Responsabilité boutique/site/langue, relations de traduction, domaine/chemin et utilisateurs partagés | Responsable localisation/technique | Products et contenus ne seront pas fusionnés entre portées de sites ou langues distinctes. |
La préparation générale des Posts, Pages CMS, types de publication personnalisés, utilisateurs, builders et applications plugins WordPress relève du périmètre CMS WordPress. Cette section ne capture que les données WordPress influençant matériellement la continuité e-commerce WooCommerce.
Sélectionner des échantillons représentatifs de test de migration
Sélectionnez des cas qui exposent les vraies relations commerciales de la boutique. Le registre d’échantillons doit noter IDs source, SKUs, URL publiques, relations parent/enfant, responsables d’extensions, clés externes et raison du choix.
| Échantillon | Éléments à préparer | Objectif de préparation |
|---|---|---|
| Product simple | Prix, stock, classes fiscales/expédition, médias, Categories et clé externe | Établit la référence Product de base. |
| Product variable | Attributs globaux/personnalisés, variations, SKUs, prix, stock, images, ruptures et valeurs par défaut | Représente structure parent-variation et identité vendable. |
| Product virtuel ou téléchargeable | Fichier, limite/expiration d’accès, état d’expédition et Orders pertinentes | Représente traitement non physique et propriété des fichiers. |
| Modèle Product détenu par extension | Abonnement, réservation, bundle, composite, add-on, gros, marketplace ou similaire | Expose tables d’extension et relations inter-données. |
| Customer enregistré et Order invitée | Adresses, identité compte/invité, rôles, liens Order et IDs externes | Représente les deux modèles d’identité Customer. |
| Order historique complexe | Lignes de variations, coupon, frais, taxes, expédition, référence paiement, notes, remboursement et champs personnalisés | Représente le contexte commercial historique. |
| Order sensible à HPOS | État stockage, métadonnées personnalisées, dépendances extensions et usage externe d’analyse | Expose les hypothèses de stockage et compatibilité. |
| Échantillon URL/contenu e-commerce | Product, Category, endpoint, média, SEO, redirection et contenu CMS lié | Représente les dépendances de routes WordPress-WooCommerce. |
Le jeu d’échantillons doit inclure les cas limites réellement utilisés, pas une complexité hypothétique. Chaque cas doit disposer d’éléments source, données d’extension liées, fichiers associés et d’un réviseur nommé.
Terminer le contrôle final de préparation WooCommerce
Consolidez les éléments dans un registre de préparation avant exécution. Toute dépendance non résolue doit avoir un responsable, une décision requise et une conséquence sur le périmètre.
| Domaine de préparation | Condition prête |
|---|---|
| Source et restauration | Accès, System Status Report, sauvegarde complète, inventaire logiciel, instantané et responsable de restauration enregistrés. |
| Products et stock | Types, variations, attributs, identifiants, responsabilité du stock, prix, médias, fichiers, Categories, taxes et classes d’expédition documentés. |
| Customers et identité | Identités enregistrées/invitées, adresses, rôles, profils d’extensions, champs de confidentialité et dépendances d’authentification classés. |
| Orders et historique | États, lignes, totaux, taxes, Coupons, frais, remboursements, Reviews, références paiement/expédition et IDs externes disposent d’éléments source. |
| HPOS | Stockage Order de référence, état de synchronisation, métadonnées personnalisées, accès direct et compatibilité des extensions sont connus. |
| Opérations | Champs de commande, paiement, expédition, fiscalité, traitement, notifications et données générées ont des responsables nommés. |
| Extensions et intégrations | Extensions critiques, code personnalisé, tables, systèmes externes et relations inter-données sont inventoriés. |
| Dépendances WordPress | Routes e-commerce, médias, SEO, redirections, contenu CMS connecté, langue et portée du site sont documentés. |
| Échantillons | Le registre couvre chaque modèle important de Product, Customer, Order, HPOS, extension et route. |
Le périmètre WooCommerce est prêt lorsque l’équipe peut relier chaque donnée e-commerce sélectionnée à son stockage source, son responsable métier, ses données associées, son propriétaire cible ou système conservé et ses éléments justificatifs.
Conclusion
Préparer WooCommerce exige des éléments coordonnés sur Products, variations, attributs, stock, Customers, Orders, HPOS, coupons, avis, remboursements, champs du processus de commande, opérations, extensions, routes WordPress et systèmes externes. Un export Product ou une liste de plugins ne suffit pas à expliquer les relations qui rendent la boutique commercialement utilisable.
Un dossier solide établit le stockage de référence, conserve des sauvegardes restaurables, identifie données natives et détenues par extensions, sépare transactions historiques et configuration actuelle, sélectionne des échantillons représentatifs et résout chaque dépendance importante avant le début de l’exécution de migration.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers WooCommerce ?
Définissez le périmètre e-commerce WooCommerce et capturez un instantané source restaurable. Enregistrez les systèmes de référence pour Products, stock, Customers, Orders, tarification, taxes, expédition, paiement et traitement avant le début de la mise en correspondance détaillée.
Pourquoi les Products variables nécessitent-ils une préparation distincte ?
Chaque variation peut détenir son SKU, ses identifiants, prix, image, stock, règle de rupture, poids, dimensions, classe d’expédition, classe fiscale et champs de téléchargement. Des éléments limités au parent peuvent donc masquer les données réellement achetées et traitées.
Quels éléments HPOS faut-il collecter ?
Enregistrez le stockage Order de référence, l’état du mode compatibilité, la synchronisation, les métadonnées Order personnalisées, l’accès direct à la base, les tables Order personnalisées et la compatibilité des extensions. Cela montre où résident les Orders actuelles et quels composants dépendent du modèle de stockage.
Faut-il inventorier les extensions WooCommerce même lorsqu’elles sont inactives ?
Oui, lorsqu’elles ont créé des données encore importantes commercialement ou historiquement. Le seul état actif ne prouve pas si une extension détient Products, profils Customer, Orders, abonnements, réservations, vendeurs ou tables personnalisées restant dans le périmètre.
Comment répartir la préparation entre WordPress et WooCommerce ?
La préparation WordPress couvre Posts CMS, Pages CMS, types de publication personnalisés, taxonomies, utilisateurs, builders, médias et limites applicatives des plugins. La préparation WooCommerce couvre Products, variations, Customers, Orders, HPOS, coupons, avis et extensions e-commerce, tout en documentant uniquement les dépendances WordPress nécessaires à ces données.
Quelles données choisir pour un test de migration représentatif ?
Sélectionnez de vrais exemples représentant Products simples et variables, Products non physiques, modèles détenus par extensions, identités enregistrées et invitées, Orders complexes, métadonnées sensibles à HPOS et routes e-commerce. Chaque échantillon doit inclure ses données liées et la raison de sa sélection.