Si CS-Cart est retenu comme plateforme cible, la préparation doit commencer par l’identification du modèle opérationnel attendu : environnement Store Builder exploité par un marchand ou marketplace Multi-Vendor. Les deux utilisent des structures de catalogue proches, mais Multi-Vendor ajoute la propriété Vendor, les administrateurs vendeurs, les Products et Orders propres aux vendeurs, les commissions, enregistrements comptables, retraits, permissions de storefront et flux financiers dépendant d’extensions.
L’objectif est de rassembler les éléments source avant de figer la configuration de migration. Pour chaque domaine majeur, il faut identifier l’action, le responsable, les éléments de vérification et la condition indiquant que la préparation est suffisante. Options, features et variations doivent rester distinctes ; le périmètre des storefronts doit être explicite ; les Vendors ne doivent pas être réduits à des comptes Customers ; et les Orders historiques doivent conserver leur contexte vendeur et financier.
Confirmer l’édition, la version, les storefronts et les accès CS-Cart
Documentez l’édition exacte de CS-Cart ou Multi-Vendor, la version, le chemin d’installation, la base de données, les storefronts actifs, sociétés ou Vendors, langues, devises, thèmes, extensions de plateforme et synchronisations externes. Une installation ancienne peut inclure des structures de Product Variations issues de mises à jour, des extensions retirées, des templates personnalisés ou des modifications de base de données qui changent les enregistrements effectivement disponibles.
Préparez les accès source nécessaires au parcours de migration choisi. Le responsable technique doit confirmer la bonne base de données, l’arborescence de fichiers, l’environnement d’administration et les éventuelles restrictions. Avec Multi-Vendor, identifiez également l’administrateur marketplace et les personnes qui connaissent les relations Vendors et les enregistrements comptables.
| Action | Responsable | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Confirmer édition et version | Responsable technique | Informations de version et d’édition/licence | Les hypothèses Store Builder et Multi-Vendor ne sont pas mélangées. |
| Documenter le périmètre des storefronts | Responsable commerce | Liste des storefronts, domaines, langues, devises et affectations société | Chaque storefront actif a une finalité métier documentée. |
| Confirmer l’accès source | Responsable hébergement/base de données | État de connexion, préfixe de base, note sur la racine de fichiers | Les enregistrements et fichiers nécessaires sont accessibles. |
| Inventorier thèmes et extensions | Développeur ou agence | Thème actif, liste des extensions, tables personnalisées et fichiers modifiés | Les données principales et le fonctionnement appartenant aux extensions peuvent être séparés. |
| Identifier les systèmes externes | Responsable intégration | Liste ERP/PIM/WMS/marketplace/comptabilité et clés stables | Les valeurs maintenues hors CS-Cart ont un système de référence identifié. |
Après la date d’arrêt des éléments de préparation, tenez un journal des changements. Toute nouvelle extension, modification des Product Variations, fusion de Vendors, évolution de storefront ou restructuration des Categories doit être enregistrée tant que la préparation reste active.
Préparer Products, options, features, variations et Categories
CS-Cart distingue propriétés Product, options sélectionnables, features, variations, Categories, remises quantitatives, fichiers téléchargeables, images, valeurs SEO et affectations aux storefronts. Les options recueillent des choix ou saisies de l’acheteur. Les features décrivent des caractéristiques structurées et peuvent servir au filtrage ou à la comparaison. Les variations regroupent des Products similaires selon des valeurs de features tout en conservant une identité Product indépendante.
Préparez un inventaire Product indiquant quelle structure est propriétaire de chaque valeur commerciale ou descriptive.
| Modèle source | Action de préparation | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Option sélectionnable | Documenter type d’option, variantes, caractère obligatoire, règles de combinaison et effets sur prix/poids | Export Product-option | Le fonctionnement du choix acheteur est explicite. |
| Product Variation | Documenter groupe de variations, valeurs de features, IDs Product, SKU, prix, stock, images et statut | Manifeste des groupes de variations | Chaque Product géré indépendamment reste identifiable. |
| Product feature | Documenter groupe, type, valeurs, périmètre Category/storefront et usage dans les filtres | Inventaire des features | Les valeurs descriptives et de découverte sont séparées des options. |
| Product dans plusieurs Categories | Documenter toutes les affectations, contexte merchandising principal et périmètre storefront | Export Product-Category | Le placement partagé est visible sans supposer des Products dupliqués. |
| Product téléchargeable | Documenter fichiers, conditions d’activation, relation Product et chemin source | Manifeste Product/fichiers | Fichiers et relations Product sont disponibles. |
| Prix par quantité ou wholesale | Documenter Product, seuil, groupe utilisateur ou contexte Customer, devise et montant | Inventaire tarifaire | Les valeurs commerciales conditionnelles ne sont pas réduites au prix de base. |
Documentez également combinaisons autorisées/interdites, pièces jointes, Products requis, bundles, relations de récompense et champs Product appartenant à des extensions lorsqu’ils sont actifs. Ne fusionnez pas des libellés d’options et de features simplement parce qu’ils se ressemblent : vérifiez d’abord si l’un représente un choix acheteur et l’autre une spécification.
Documenter le périmètre storefront, société et catalogue
CS-Cart peut exploiter plusieurs storefronts et Multi-Vendor ajoute des Vendors dont Products, administrateurs, Pages, méthodes de livraison et Orders appartiennent à des participants marketplace distincts. Préparez une matrice montrant si chaque enregistrement appartient au catalogue commun, à un storefront précis, à un Vendor ou à un canal externe.
| Domaine de périmètre | Responsable | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Domaines et langues des storefronts | Administrateur plateforme | Paramètres et liste des domaines | Chaque contexte public de boutique est identifié. |
| Disponibilité Products/Categories | Responsable catalogue | Export des affectations storefront/société | Enregistrements partagés et restreints sont distinguables. |
| Features et filtres | Responsable merchandising | Carte feature-Category et storefront | Les vocabulaires de découverte ont un périmètre explicite. |
| CMS Pages et layouts | Responsable contenu | Inventaire Pages, blocks, layouts, menus et storefronts | Contenu et présentation sont rattachés au bon storefront. |
| Propriété société ou Vendor | Responsable marketplace | Associations Product, Order, administrateur et Page | Les enregistrements appartenant aux vendeurs ne sont pas considérés par défaut comme propriété de la marketplace. |
Préparer Vendors, administrateurs, plans et relations financières
Cette partie s’applique lorsque le modèle source ou cible comprend Multi-Vendor. Un Vendor est une société vendeuse indépendante avec ses administrateurs, Products, Orders, contexte de livraison, statut et relations comptables. Vendor Plans, frais de transaction, commissions, versements, retraits et extensions de paiement marketplace peuvent ajouter d’autres enregistrements.
Préparez un registre Vendors distinguant les vendeurs actifs, en attente, désactivés, fusionnés, historiques et dupliqués. Documentez les administrateurs affectés à chaque Vendor, la propriété des Products et Orders, le contexte du plan ou de la commission, les éléments justifiant les soldes de compte, les versements/retraits et les identifiants vendeurs externes.
| Enregistrement marketplace | Action de préparation | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Identité Vendor | Documenter company ID, statut, données légales/contact, page storefront et clé externe | Inventaire Vendors | Chaque vendeur conservé possède une identité cible prévue. |
| Administrateurs Vendor | Documenter compte utilisateur, relation Vendor, statut et contexte de permissions | Carte administrateur-Vendor | Les relations d’accès vendeur sont documentées. |
| Products appartenant aux Vendors | Documenter propriété Product/Category, statut d’approbation et périmètre storefront | Export Product-Vendor | La propriété du catalogue est explicite. |
| Plans Vendor ou commissions | Documenter plan, frais, commission, dates d’effet et extension propriétaire | Inventaire plans/commissions | Les règles financières sont séparées des champs de profil Vendor ordinaires. |
| Comptabilité, versements et retraits | Documenter type de transaction, Vendor, montant, statut, date et Order associée | Échantillons d’historique financier | Le contexte financier marketplace reste traçable. |
| Orders divisées ou Vendor | Documenter relations entre Order parent et Orders propres aux vendeurs | Groupes d’Orders représentatifs | La responsabilité vendeur historique reste interprétable. |
Ne supposez pas qu’un Customer ayant un nom d’entreprise est un Vendor, ni qu’un compte administrateur Vendor contient à lui seul l’intégralité du vendeur.
Préparer Customers, groupes utilisateurs, adresses et champs de compte
Les Customers CS-Cart peuvent comporter adresses, groupes utilisateurs, statut d’approbation, champs de profil, abonnements newsletter, récompenses, avis et identifiants externes. Multi-Vendor contient aussi des administrateurs Vendors qui doivent rester distincts des Customers ordinaires.
| Domaine | Action de préparation | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Identité Customer | Identifier doublons, e-mails partagés, invités, approbations et clés externes | Liste d’exceptions Customers | Chaque exception d’identité a un responsable et une décision. |
| Groupes utilisateurs | Documenter appartenance et tout effet sur prix, taxe, accès ou contenu | Matrice groupe-règle | Le sens du groupe est documenté au-delà de son libellé. |
| Champs de profil | Documenter propriétaire, type, caractère obligatoire et usage | Inventaire des champs de profil | Chaque valeur personnalisée active a une décision de destination. |
| Adresses | Séparer profils réutilisables et instantanés au moment de l’Order | Exemples Customer et Order | Compte et transaction restent distincts. |
| Administrateurs Vendor | Maintenir l’identité vendeur-admin reliée au Vendor | Carte des administrateurs | L’accès marketplace n’est pas aplati dans la segmentation Customers. |
| IDs de compte externes | Documenter clés CRM, ERP, fidélité ou B2B | Carte des identifiants | Les systèmes qui continuent à fonctionner retrouvent le même compte. |
Préparer Orders, propriété vendeur, totaux et statut historique
La préparation des Orders doit préserver ce qui a été acheté, par qui, auprès de quel vendeur, à quel prix et dans quel contexte historique de paiement, livraison, taxe, remise et statut. Avec Multi-Vendor, une Order peut être divisée afin que chaque Vendor gère la partie qui lui revient.
| Élément d’Order | Action de préparation | Condition de préparation |
|---|---|---|
| Lignes Product et variation | Documenter Product ID, variation/features/options, vendeur, quantité, prix et texte historique | Articles achetés et propriété vendeur restent interprétables. |
| Orders parent et Vendor | Documenter Order d’origine et Orders vendeur associées | L’historique Multi-Vendor n’est pas aplati en transactions sans relation. |
| Adresses facturation/livraison | Préserver les instantanés d’Order séparément des profils Customer | L’historique d’adresse est complet. |
| Taxes, livraison, remises, frais, récompenses | Inventorier chaque total significatif et son éventuelle extension propriétaire | Le total final peut être expliqué. |
| Références paiement et traitement | Documenter libellés, IDs de transaction, modes de livraison, suivi et Vendor responsable | Le contexte historique de traitement reste traçable. |
| Statuts, remboursements et commentaires | Documenter séquence, visibilité, vendeur concerné et enregistrements associés | Les équipes peuvent interpréter le cycle de vie historique. |
| Références comptables | Relier Orders aux commissions, versements, retraits ou soldes lorsque nécessaire | L’historique financier marketplace reste connecté. |
Les Orders historiques ne doivent pas être recalculées à partir des paramètres actuels des Products, plans Vendors, commissions, livraisons ou paiements.
Inventorier extensions, thèmes, champs personnalisés et intégrations
Les extensions CS-Cart peuvent être propriétaires des Product Variations, noms SEO, Vendor Plans, paiements marketplace, récompenses, avis, layouts, champs personnalisés, totaux d’Orders, rapports ou connexions externes. Utilisez « extension de plateforme » ou le nom exact du composant afin de ne pas confondre ces fonctions avec des améliorations du service de migration.
| Effet de la dépendance | Éléments à préparer | Condition de préparation |
|---|---|---|
| Extension Product/catalogue | Champs/tables, IDs Product, réglages et exemples | Les valeurs actives ont un propriétaire défini. |
| Extension Vendor/comptabilité | Vendors, plans, commissions, versements ou retraits | Les données financières marketplace sont classées séparément. |
| Extension paiement/livraison | Références historiques et résumé de configuration | Les éléments transactionnels sont séparés de la configuration actuelle. |
| Extension SEO/routes | Noms SEO, paramètres de réécriture et tables de redirection | Les chemins source importants peuvent être reconstruits. |
| Personnalisation thème/layout | Fichiers du thème, affectations layout/block, captures de référence | Le contenu métier est séparé de la présentation. |
| Intégration ERP/PIM/WMS/marketplace | Système de référence, sens de synchronisation et IDs stables | Les systèmes conservés peuvent se reconnecter aux entités cibles. |
| Table ou champ personnalisé | Schéma, clés parent, consommateur et finalité métier | Chaque valeur active possède une décision. |
Préparer CMS Pages, noms SEO, médias et routes
Préparez les CMS Pages, Blog Posts lorsqu’ils existent, descriptions Product/Category, pages Vendors, menus, layouts, blocks, bannières, pièces jointes et médias en les rattachant à leur propriétaire et à leur storefront. Pour chaque élément, documentez langue, statut, route, storefront, relation Vendor, liens intégrés et traitement prévu.
Pour les routes Product, Category, feature, CMS, Vendor et Blog prioritaires, documentez l’objet source, le storefront, la langue, le nom SEO, le chemin actuel, l’importance métier et la décision de redirection ou d’exclusion. Blog Posts, pages storefront Vendors et blocks CMS peuvent utiliser des libellés semblables tout en appartenant à des propriétaires différents ; conservez donc séparément leurs IDs, périmètre storefront, relation auteur/Vendor, médias et emplacement dans les menus. Conservez également les images originales, fichiers téléchargeables, pièces jointes et ressources de thème en dehors de la seule sauvegarde de base de données.
Constituer le package de sauvegarde et de préparation des entrées
| Élément du package | Responsable | Éléments de vérification | Condition de préparation |
|---|---|---|---|
| Sauvegarde de base de données | Administrateur base de données | Dump horodaté et note sur le préfixe | Toutes les tables principales, d’extensions et Vendors du périmètre sont incluses. |
| Fichiers et médias | Responsable hébergement/technique | Archive de fichiers ou arborescence source accessible | Images, téléchargements, pièces jointes, thèmes et extensions sont disponibles. |
| Relevé édition/périmètre | Responsable plateforme | Version, édition, storefronts, sociétés/Vendors, langues, devises | Les relations Store Builder/Multi-Vendor sont explicites. |
| Registre des accès | Responsable projet | Propriétaire de l’accès et état de connexion | Les accès nécessaires sont disponibles sans exposer les identifiants. |
| Journal des changements | Administrateur boutique | Évolutions structurelles depuis la date d’arrêt | Les changements tardifs peuvent être intégrés volontairement. |
Sélectionner des échantillons représentatifs pour les tests de migration
Préparez un manifeste d’échantillons avec IDs source, raison métier, storefront ou Vendor propriétaire, fichiers associés et relations attendues dans la source. Le manifeste est prêt lorsque chaque attente, chaque propriétaire storefront/Vendor, chaque fichier lié et chaque identifiant sont complets et attribués à un réviseur.
Incluez au minimum :
- des Products simples et des Products avec options, features, variations, plusieurs Categories, fichiers ou tarification spéciale ;
- des enregistrements appartenant à différents storefronts ;
- des Customers ordinaires, Customers de groupes utilisateurs, administrateurs Vendors et champs de profil personnalisés ;
- des Orders standard et des Orders avec variations, totaux inhabituels, remboursements, suivi et IDs externes ;
- avec Multi-Vendor, des Products appartenant aux Vendors, Orders parent/sous-Orders, plans, commissions, versements ou retraits ;
- des routes prioritaires CMS, Blog, Product, Category, Vendor et SEO ;
- un enregistrement actif appartenant à une extension de plateforme et une relation avec un système externe.
Appliquer le dernier contrôle de préparation CS-Cart
| Question de préparation | Résultat requis |
|---|---|
| L’édition et le périmètre storefront sont-ils connus ? | Version, modèle Store Builder/Multi-Vendor, storefronts, langues et sociétés/Vendors sont documentés. |
| Les éléments du catalogue sont-ils complets ? | Products, options, features, variations, Categories, prix, médias et périmètres sont représentés. |
| Les relations marketplace sont-elles prêtes ? | Vendors, administrateurs, Products vendeurs, Orders, plans et données comptables ont un propriétaire. |
| Customers et Orders restent-ils interprétables ? | Groupes, profils, adresses, statuts, totaux, contexte vendeur et IDs externes sont documentés. |
| Extensions et données personnalisées sont-elles classées ? | Chaque dépendance active a une finalité métier et une décision de destination. |
| Contenu et routes sont-ils inventoriés ? | Relations storefront, Vendor, CMS, Blog, médias et SEO sont documentées. |
| Sauvegardes, accès et échantillons sont-ils prêts ? | Le package source est restaurable et les IDs représentatifs sont listés. |
La préparation reste ouverte si l’édition, la propriété Vendor, les Product Variations, la division des Orders, l’historique comptable, le périmètre storefront ou un enregistrement d’extension actif n’est pas encore documenté.
Conclusion
La préparation de CS-Cart doit refléter le modèle opérationnel réel. Products, options, features, variations, storefronts, Customers, Orders, contenu et extensions forment une première couche ; Multi-Vendor ajoute vendeurs, administrateurs, catalogue appartenant aux Vendors, Orders divisées, plans, commissions, versements et retraits.
Un package source maîtrisé rend ces relations explicites et fournit des enregistrements représentatifs pour configurer la migration.
Questions fréquentes
Pourquoi faut-il distinguer Store Builder et Multi-Vendor avant la migration ?
Multi-Vendor ajoute Vendors, administrateurs vendeurs, Products appartenant aux vendeurs, Orders divisées, plans, commissions, comptabilité, versements et retraits. Ces relations n’appartiennent pas au modèle de données Store Builder ordinaire.
Quelle différence entre options, features et variations dans CS-Cart ?
Les options recueillent les choix ou saisies de l’acheteur, les features décrivent et classifient les Products, et les variations regroupent des Products gérés indépendamment selon des valeurs de features. Préparez-les comme des ensembles distincts.
Comment documenter plusieurs storefronts CS-Cart ?
Pour chacun, documentez domaine, langue, devise, thème, Products, Categories, contenu, routes, features et périmètre société. Les enregistrements partagés et restreints doivent être visibles dans une seule matrice.
Quels enregistrements Vendors faut-il inclure avec Multi-Vendor ?
Profils, statuts, administrateurs, propriété des Products et Orders, plans, commissions, transactions comptables, versements, retraits et identifiants vendeurs externes lorsqu’ils existent.
Les données d’une extension CS-Cart doivent-elles être traitées comme des champs Product ou Order ordinaires ?
Pas automatiquement. Documentez l’extension, les entités concernées, tables/champs, IDs représentatifs et consommateur métier. Les enregistrements actifs exigent un propriétaire explicite ; les données obsolètes peuvent être archivées ou exclues.
Quelles Orders sélectionner pour la préparation ?
Choisissez des Orders ordinaires et complexes, avec variations/options, différents totaux et statuts, remboursements, suivi, IDs externes et, avec Multi-Vendor, relations parent/sous-Orders, responsabilité Vendor et données comptables associées.