Si X-Cart est retenu comme plateforme cible, la préparation doit commencer par l’identification exacte de la génération de la source et de l’ensemble de modules installés. Les boutiques X-Cart peuvent différer sensiblement selon les versions, éditions, mises à niveau et générations de modules. Les attributs Product peuvent servir de spécifications, de valeurs sélectionnables par le client ou de dimensions de variation. Les anciennes installations peuvent utiliser des Product Variants, tandis que les environnements source plus récents peuvent utiliser des Product Variations ainsi qu’une autre structure de modules ou d’API. Les adhésions, données multi-vendeurs, modules personnalisés et intégrations externes peuvent encore modifier ce qu’un enregistrement Product, Customer ou Order signifie.
L’objectif de la préparation consiste à décrire la boutique réelle, pas un schéma X-Cart générique supposé. Chaque domaine de préparation doit associer une action, un propriétaire, un élément justificatif et une condition de préparation. Cette base contrôlée permet ensuite de configurer la migration de manière fiable.
Établir la version, l’édition, les accès et l’historique des modules X-Cart
Consignez la version exacte de X-Cart, le contexte d’édition ou de package, l’historique des mises à niveau, les modules actifs, les modules personnalisés, le thème, la configuration de la vitrine ou de la marketplace, la génération d’API et l’environnement d’hébergement. L’historique des versions est particulièrement important lorsque le catalogue a connu une transition entre Product Variants et Product Variations, des remplacements de modules ou des migrations personnalisées de base de données.
| Action | Propriétaire | Élément justificatif | Condition de préparation |
|---|---|---|---|
| Identifier la version exacte de X-Cart et l’historique des mises à jour | Responsable technique | Capture d’administration, informations de package, notes de mise à niveau | La génération source et les mises à niveau connues sont consignées. |
| Inventorier les modules actifs et inactifs | Administrateur de la boutique ou développeur | Liste des modules avec auteur, version, état et objectif | Chaque module critique pour l’activité possède un propriétaire. |
| Identifier l’utilisation de Product Variants ou Product Variations | Responsables catalogue et technique | État du module, Products représentatifs et emplacements de données pertinents | Le modèle de variation actif est explicite. |
| Confirmer la connexion à la source et l’accès aux fichiers | Responsable hébergement ou technique | État des accès, liste d’autorisation ou notes d’authentification | L’installation source prévue est accessible. |
| Consigner le thème et les couches de code personnalisé | Développeur ou agence | Nom du thème, chemins des modules personnalisés, surcharges et notes de déploiement | La présentation et le fonctionnement personnalisé sont distinguables des enregistrements du cœur. |
| Consigner les API et synchronisations | Responsable des intégrations | Version d’API, propriétaire des identifiants, liste des webhooks ou tâches planifiées | Les systèmes externes et leurs clés d’enregistrement sont connus. |
Ne déduisez pas la structure actuelle de la boutique d’un ancien document de projet ou d’une facture de module. La liste réelle des modules, la base de données, l’arborescence du code et les enregistrements représentatifs doivent être cohérents entre eux.
Préparer Products, classes Product, attributs et variations
La préparation des Products X-Cart doit distinguer le Product de base, la classe Product, la définition d’attribut, la valeur d’attribut, la valeur sélectionnable par le client, la spécification et la variation vendable. Un attribut nommé « Color » peut être un champ descriptif sur un Product et une dimension de variation avec son propre SKU, prix, stock, poids ou image sur un autre.
Créez un inventaire du catalogue comprenant l’identifiant Product, le SKU, le nom, le statut, le type Product lorsqu’il est pertinent, les affectations aux Categories, la classe Product, les attributs, variations ou variants, les prix, le stock, le poids, les images, les fichiers, les adhésions, les classes de taxe, la propriété vendeur lorsqu’elle s’applique et les identifiants externes.
| Structure source | Action de préparation | Élément justificatif | Condition de préparation |
|---|---|---|---|
| Attribut au niveau de la classe | Consigner la classe, le groupe d’attributs, le type, les valeurs autorisées et les Products affectés | Export des classes Product et attributs | Les définitions partagées peuvent être distinguées des valeurs propres aux Products. |
| Attribut simple ou spécification | Consigner si la valeur est descriptive, filtrable ou saisie par le client | Products représentatifs et captures de la vitrine | Les spécifications ne sont pas prises à tort pour des variations vendables. |
| Dimension de variation sélectionnable | Consigner les attributs utilisés pour construire les variations et toutes les combinaisons actives | Manifeste des variations avec SKU, stock, prix, poids et image | Chaque combinaison vendable possède une identité stable. |
| Ancien module Product Variants | Consigner la génération du module, l’état de mise à niveau et les enregistrements de variants | Éléments liés au module et identifiants Product représentatifs | Les structures de variations anciennes et actuelles ne sont pas mélangées silencieusement. |
| Product avec fichiers ou livraison numérique | Consigner les références de fichiers et les règles d’accès | Liste Product/fichiers et exemples d’Orders | Les fichiers et relations historiques d’achat sont disponibles. |
| Product restreint par adhésion ou appartenant à un vendeur | Consigner la relation d’accès ou de propriété | Matrice adhésion/vendeur | La visibilité ou la propriété du Product est documentée au-delà de la ligne Product. |
Normalisez les noms d’attributs uniquement après confirmation par le responsable catalogue que deux valeurs ont réellement la même signification. Les classes Product partagées peuvent amplifier une mauvaise modification sur de nombreux Products.
Préparer Categories, navigation, visibilité par adhésion et périmètre du catalogue
Categories, menus, classes Product, adhésions, vendeurs et présentation de la vitrine peuvent tous influencer la découverte. Préparez la hiérarchie des Categories et les affectations Product, mais ne supposez pas que l’appartenance à une Category recrée à elle seule la navigation ou les règles d’accès.
Pour les boutiques qui utilisent des adhésions, documentez quels Products, Categories, prix, contenus ou fonctions de compte dépendent de l’adhésion. Dans un environnement marketplace ou multi-vendeur, consignez la propriété vendeur, les identifiants propres au vendeur, les Products du vendeur, les références de commission ou de règlement lorsqu’elles existent, ainsi que la relation entre les vendeurs et les Orders.
| Domaine du périmètre catalogue | Propriétaire | Élément justificatif | Condition de préparation |
|---|---|---|---|
| Hiérarchie des Categories | Responsable catalogue | Liste parent-enfant et affectations Product | Les Categories conservées ont un objectif et un parent clairs. |
| Navigation et menus | Responsable de la vitrine | Captures de menus et liste des destinations | La présentation des menus est séparée des données Category. |
| Classes Product | Architecte catalogue | Carte classe-vers-Product et classe-vers-attribut | L’héritage des attributs partagés est visible. |
| Restrictions par adhésion | Responsable B2B ou des comptes | Matrice adhésion-vers-Product/Category/prix | Les effets sur l’accès et les prix sont explicites. |
| Périmètre vendeur | Responsable marketplace | Échantillons vendeur-vers-Product et vendeur-vers-Order | La propriété vendeur n’est pas aplatie dans des champs fabricant ou marque. |
Préparer Customers, adhésions, adresses et Orders
Les données Customer X-Cart peuvent inclure utilisateurs, adresses, adhésions, rôles, champs de profil, statut du compte, préférences marketing, profils vendeurs et identifiants externes. Séparez l’identité de connexion des rôles de Customer, membre du personnel, administrateur, vendeur ou adhérent.
La préparation des Orders doit préserver les descriptions Product au moment de la commande, SKU, attributs, variations sélectionnées, prix, remises, taxes, frais d’expédition, libellés de paiement, statuts, notes, expéditions, remboursements, retours, contexte vendeur et références externes lorsqu’elles existent. Consignez quels modules créent des lignes d’Order supplémentaires, surtaxes, enregistrements d’abonnement, transactions de paiement, données de traitement logistique ou détails de règlement marketplace.
| Domaine d’enregistrement | Action de préparation | Élément justificatif | Condition de préparation |
|---|---|---|---|
| Utilisateurs et Customers | Classer Customer, administrateur, vendeur et autres rôles | Inventaire des rôles utilisateur | Les comptes ne sont pas fusionnés uniquement parce qu’ils partagent une même table. |
| Adhésions | Consigner la signification actuelle et historique des adhésions | Liste d’adhésions et échantillons Customer | Le fonctionnement catalogue ou prix dépendant des adhésions possède un propriétaire. |
| Adresses | Séparer les adresses de profil des snapshots d’Order | Échantillons d’adresses Customer et Order | Les adresses historiques restent interprétables. |
| Statuts d’Order | Consigner les noms de statuts, leur signification opérationnelle et leurs dépendances de modules | Carte des statuts et Orders représentatifs | L’état historique est compréhensible sans l’ancienne couleur ou icône d’administration. |
| Lignes et totaux d’Order | Inclure les valeurs de variations, remises, taxes, frais, expédition et lignes créées par les modules | Détails d’Orders représentatifs | La transaction peut être reconstruite à partir de ses éléments historiques. |
| Identifiants externes | Consigner les clés de paiement, ERP, marketplace, expédition ou comptabilité | Registre des identifiants | Les systèmes qui restent actifs peuvent retrouver le même enregistrement. |
Évitez de « nettoyer » les Orders historiques en remplaçant d’anciens noms Product ou attributs par les valeurs actuelles du catalogue. Le snapshot source fait partie des éléments historiques à conserver.
Inventorier modules, code personnalisé, tables personnalisées et systèmes externes
Les modules X-Cart peuvent étendre ou remplacer des structures de données du cœur, ajouter des tables, modifier le fonctionnement des modèles, créer des ressources API, ajouter des champs ou contrôler le rendu en vitrine. Les générations actuelles et historiques de X-Cart utilisent aussi des chemins de modules et frameworks différents. Préparez un registre de responsabilité plutôt qu’une simple liste de modules installés.
| Effet du module | Éléments à préparer | Condition de préparation |
|---|---|---|
| Champ Product ou Customer | Clé du champ, type de données, propriétaire de l’entité, identifiants représentatifs | La valeur possède un propriétaire de destination ou une exclusion volontaire. |
| Extension de variation ou de stock | Enregistrements de combinaisons, source du stock, clé SKU externe | L’identité vendable et l’autorité du stock sont explicites. |
| Enregistrement d’abonnement, réservation, bundle ou service | Relations avec Product parent, Customer, Order et planification | Les enregistrements spécialisés ne sont pas réduits à des métadonnées Product. |
| Module marketplace | Relations vendeur, offre, commission, paiement et Order | Les données marketplace sont séparées de l’identité catalogue du cœur. |
| Module de paiement ou traitement logistique | Références historiques de transaction, expédition ou statut | L’historique peut être séparé de la future configuration. |
| Code ou table personnalisée | Schéma, relations de clés, processus actif, propriétaire des données | L’entité métier, et pas seulement la table, est documentée. |
| PIM, ERP, WMS, CRM ou marketplace externe | Autorité par champ et identifiants stables | Le système de référence qui reste actif est nommé. |
Classez les modules comme actifs et requis, actifs mais remplaçables, uniquement historiques, inactifs avec données conservées ou obsolètes. Un module inactif peut encore posséder des données nécessaires à l’interprétation d’Orders historiques.
Préparer contenus, médias, URL et éléments de vitrine
Le contenu X-Cart peut inclure des descriptions Product et Category, des Pages statiques ou CMS, des Blog Posts lorsqu’un module les fournit, des menus, bannières, libellés, traductions, modèles d’e-mail, blocs de thème et pages générées par des modules. Préparez le contenu selon son propriétaire plutôt que de traiter tout texte visible comme un seul export CMS.
Consignez les routes importantes de Products, Categories, contenus, adhésions, vendeurs et modules. Incluez les chemins canoniques, la langue ou le périmètre de vitrine, l’importance du trafic, le module qui génère la route et la disposition prévue. Les thèmes et modules peuvent créer des routes qui ne sont pas représentées par des enregistrements de contenu ordinaires.
Préparez les médias et fichiers originaux avec leurs relations de base de données. Consignez le stockage externe, les tailles générées, les originaux manquants, les chemins sensibles à la casse et les fichiers protégés par des règles d’accès propres aux modules.
Construire un package source X-Cart restaurable
Un package source X-Cart auto-hébergé doit inclure une sauvegarde de la base de données, les fichiers applicatifs et publics pertinents, les détails de l’environnement, les manifestes de modules, les notes de déploiement ou de mise à niveau, l’état des accès et un relevé des changements structurels intervenus après la date de collecte des éléments justificatifs.
| Composant du package | Propriétaire | Élément justificatif | Condition de préparation |
|---|---|---|---|
| Base de données | Administrateur de base de données | Dump horodaté et note de préparation à la restauration | Les tables du cœur et des modules proviennent du même état de boutique. |
| Fichiers applicatifs et publics | Responsable technique | Archive de fichiers ou arborescence source accessible | Modules, thèmes, médias et fichiers protégés sont disponibles. |
| Environnement | Responsable technique | Notes sur PHP, base de données, files d’attente, cache, stockage et serveur web | Les fonctionnements sensibles aux versions peuvent être interprétés. |
| Manifeste des modules | Développeur ou administrateur de la boutique | Liste des modules actifs/inactifs avec versions | Les entités appartenant aux modules peuvent être retracées. |
| Journal des changements | Responsable du projet | Changements tardifs après la collecte des éléments | Les nouveaux Products, modules ou modifications de schéma sont visibles. |
Sélectionner des échantillons représentatifs pour les tests de migration
Préparez un manifeste d’échantillons comprenant les identifiants source, les enregistrements associés de modules ou systèmes externes, les fichiers médias et les relations source attendues. Le manifeste est prêt lorsque les éléments sélectionnés sont complets, traçables et attribués à un réviseur.
Incluez :
- des Products simples et des Products appartenant à plusieurs classes Product ;
- des Products avec attributs descriptifs, valeurs saisies par le client et variations actives ;
- un cas d’ancien variant ou de variation migrée si la boutique a connu ce changement de module ;
- des Products restreints par adhésion ou appartenant à des vendeurs lorsqu’ils existent ;
- des Customers avec adhésions, plusieurs adresses, identifiants externes ou rôles vendeur ;
- des Orders invités et enregistrés avec variations, totaux inhabituels, remboursements, expéditions et enregistrements créés par des modules ;
- des exemples importants de Category, contenu, média et route ;
- un enregistrement de module personnalisé actif et une relation avec un système externe.
Appliquer le contrôle final de préparation X-Cart
| Question de préparation | Résultat requis |
|---|---|
| L’historique de la source est-il connu ? | Version, contexte d’édition, historique des mises à niveau, génération des modules et environnement sont consignés. |
| La signification du catalogue est-elle complète ? | Classes Product, attributs, variations, Categories, adhésions, vendeurs et médias sont représentés. |
| Les comptes et Orders sont-ils interprétables ? | Rôles, adhésions, adresses, snapshots d’Order, statuts et références externes ont des propriétaires. |
| Les modules et données personnalisées sont-ils classés ? | Les enregistrements actifs et historiques appartenant à des modules ont une disposition définie. |
| Les contenus et routes sont-ils inventoriés ? | Chemins publics, routes de modules, médias et éléments de présentation sont documentés. |
| Le package source est-il restaurable ? | La base de données et les fichiers correspondent au même état de boutique. |
| Le manifeste d’échantillons est-il représentatif ? | Cas du cœur, complexes, historiques, appartenant à des modules et liés à des systèmes externes sont inclus. |
Les inconnues critiques doivent rester des décisions ouvertes avec un propriétaire. Ne finalisez pas la préparation tant que le modèle de variation, le propriétaire d’un module, une relation vendeur ou un identifiant externe reste non classé.
Conclusion
La préparation d’une migration vers X-Cart dépend de l’historique de la source. Version, génération des modules, classes Product, attributs, variations, adhésions, vendeurs, extensions d’Orders, modules personnalisés et systèmes externes déterminent quels enregistrements existent et comment ils sont reliés.
Un package source restaurable et un manifeste d’éléments représentatifs permettent de configurer la migration en fonction de la boutique réelle.
Questions fréquentes
Pourquoi faut-il consigner la version de X-Cart et la génération des modules ?
Les structures X-Cart et la mise en œuvre des modules ont évolué au fil des générations. Un même concept visible dans la vitrine peut être stocké via des modules, entités ou API différents ; la version réelle et l’ensemble de modules déterminent donc quels éléments font autorité.
Les attributs X-Cart et les Product variations sont-ils la même chose ?
Non. Les attributs peuvent décrire des Products, collecter des valeurs saisies par le client ou participer à des variations vendables. Seules les relations qui définissent un SKU, un stock, un prix, un poids ou une image distincts doivent être traitées comme identité de variation.
Que faut-il préparer pour les adhésions X-Cart ?
Consignez les définitions d’adhésion, les affectations Customer, les restrictions Product ou Category, les effets sur les prix, les règles de compte et des Orders représentatifs. Un simple libellé d’adhésion ne préserve pas sa signification commerciale ou d’accès.
Faut-il ignorer les modules X-Cart inactifs ?
Pas automatiquement. Un module inactif peut encore posséder des enregistrements historiques d’Order, des champs Customer ou des identifiants externes. Déterminez si ses données restent nécessaires avant de le classer comme obsolète.
Que doit contenir le manifeste d’échantillons X-Cart ?
Incluez des Products simples et basés sur des classes, des attributs et variations, des adhésions ou vendeurs lorsqu’ils existent, des Orders complexes, des routes importantes, des enregistrements appartenant à des modules et des relations avec des systèmes externes. Utilisez les identifiants source exacts et les éléments associés.
Pourquoi faut-il sauvegarder à la fois la base de données et les fichiers ?
La base contient les enregistrements du cœur et des modules, tandis que les fichiers peuvent contenir modules, thèmes, médias, ressources téléchargeables, configuration et code personnalisé. Un package source complet doit réunir les deux à partir du même état de boutique.