Si BigCommerce est retenu comme plateforme cible, la préparation doit définir comment la boutique source deviendra un catalogue BigCommerce administrable avant le début de toute exécution de migration. Products, variantes, options, modifiers, champs personnalisés, metafields, Categories, listes de prix, groupes de Customers, canaux, Customers, Orders, contenus et intégrations sont des domaines de responsabilité distincts. Une plateforme source peut en réunir plusieurs dans un même Product ou dans un même enregistrement d’extension.
Le dossier de préparation doit préciser le propriétaire prévu sur la destination, fournir des éléments représentatifs, attribuer un responsable et définir une condition de préparation. Cela donne un sens au jeu d’échantillons représentatifs de migration et permet de le relier aux données de la source.
Définir le périmètre opérationnel et le catalogue BigCommerce
Commencez par consigner les limites du futur environnement BigCommerce.
| Domaine | Décision de préparation | Élément attendu |
|---|---|---|
| Identité du catalogue | Quels enregistrements source deviennent des Products et variantes | Carte des familles de produits avec identifiants source et propriété des SKU |
| Choix de l’acheteur | Quelles valeurs sont des variantes, modifiers, champs personnalisés ou données d’application | Matrice représentative des options |
| Organisation du catalogue | Quelles Categories, marques, filtres et pages d’atterrissage de la source sont conservés | Schéma des Categories et de la découverte |
| Contexte commercial | Quels groupes de Customers, listes de prix, tarifs dégressifs, promotions et devises sont importants | Inventaire des relations tarifaires |
| Périmètre des canaux | Quels Products, Categories, contenus, devises et locales appartiennent à chaque canal ou vitrine | Matrice d’affectation des canaux |
| Données personnalisées | Quels enregistrements appartiennent aux champs personnalisés, metafields, applications ou systèmes externes | Registre des champs et dépendances |
Documentez si la « boutique » source représente une seule vitrine, plusieurs vitrines régionales, un canal marketplace, une marque, une unité commerciale ou un catalogue propre à certains Customers. Des Products similaires peuvent nécessiter une identité BigCommerce partagée avec des affectations de canaux, ou des identités séparées lorsque leur propriété commerciale diffère. La même frontière doit être appliquée de manière cohérente aux Categories, contenus, prix, devises et accès des Customers afin que le catalogue cible ne mélange pas des enregistrements appartenant à des contextes de vente différents.
Préparer les accès, exports et définitions de la source
Préparez les accès à la source et à BigCommerce nécessaires pour récupérer et interpréter les données incluses dans le périmètre. Conservez des copies datées afin que l’équipe puisse expliquer l’état de la source même si la boutique active évolue.
Collectez :
- les accès administrateur à la boutique source et à BigCommerce avec les permissions appropriées ;
- les exports de Products, variantes, Categories, Customers, Orders, contenus et redirections lorsqu’ils sont disponibles ;
- les médias et documents Product lorsque les liens de la source peuvent expirer ou nécessitent une authentification ;
- les listes de prix, groupes de Customers, tarifs dégressifs, promotions et éléments liés aux devises ;
- les affectations de canaux ou vitrines et les listes de contenus localisés ;
- les dictionnaires de champs personnalisés, metafields, applications et identifiants externes ;
- les rapports ERP, PIM, WMS, CRM, marketplace ou comptables permettant d’identifier les clés partagées ;
- un journal des changements de la source pour les enregistrements susceptibles d’évoluer avant la fenêtre de migration.
| Élément | Responsable | Condition de préparation |
|---|---|---|
| Registre des accès | Administrateurs de boutique | Les zones nécessaires de la source et de BigCommerce sont accessibles |
| Archive des exports | Responsable des données | Les fichiers s’ouvrent, contiennent les enregistrements attendus et indiquent une date d’export |
| Dictionnaire de champs | Responsable catalogue ou technique | Les champs importants ont une fonction, un type, une entité parente et un propriétaire cible |
| Éléments tarifaires | Responsable commercial | Les contextes de prix de base, par groupe, par liste, par volume et promotionnels sont distingués |
| Inventaire des canaux | Responsable des canaux | Chaque canal possède un périmètre défini de Products, Categories, contenus, locales et devises |
Préparer les Products, variantes, options et modifiers
BigCommerce distingue les variantes vendables des modifiers de l’acheteur et des données descriptives du Product. Préparez des exemples source qui rendent visibles ces différences.
Incluez :
- des Products simples ;
- des Products avec SKU enfants et prix, stock, image, poids, code-barres ou identifiants externes au niveau de la variante ;
- des options source qui modifient un Product sans créer de stock indépendant ;
- des choix de personnalisation, téléversement de fichier, date, mesure ou service ;
- des Products avec champs personnalisés, metafields, spécifications riches ou données de compatibilité ;
- des bundles, kits, abonnements, garanties ou configurations détenues par une application ;
- des Products affectés différemment selon les canaux ;
- des Products synchronisés avec des systèmes externes de catalogue ou de stock.
| Fonctionnement dans la source | Décision de préparation BigCommerce | Élément à fournir |
|---|---|---|
| Le choix identifie un article vendable distinct | Définir la propriété du Product et de la variante | Identifiants parent/enfant, valeurs d’option, SKU, prix, stock, images et identifiants externes |
| Le choix modifie le Product mais ne possède pas de stock indépendant | Définir le modifier ou une autre relation cible | Type de saisie, valeurs autorisées, effet sur le prix/poids et exemple de ligne d’Order |
| La valeur décrit le Product | Définir le champ personnalisé, metafield, contenu ou propriétaire applicatif | Type de champ, valeurs contrôlées, consommateurs d’affichage et d’intégration |
| La combinaison suit une logique personnalisée | Définir l’application ou le propriétaire cible personnalisé | Exemples de règles, identifiants de composants et exemples d’Orders historiques |
Normalisez les noms et valeurs d’options avant l’import. Des noms incohérents peuvent créer des ensembles d’options séparés et des filtres peu efficaces alors que le concept métier sous-jacent est identique.
Préparer Categories, prix, groupes de Customers et canaux
La préparation BigCommerce doit traiter la découverte et la tarification comme des structures liées mais distinctes.
Pour les Categories, préparez :
- la hiérarchie de la source et les affectations de Products ;
- les relations avec les marques et fabricants ;
- les valeurs de filtres ou facettes ;
- le contenu et les métadonnées des pages d’atterrissage ;
- les Categories internes ou obsolètes ;
- les affectations de Categories propres aux canaux ;
- les URL et priorités de redirection.
Pour les prix, préparez des éléments distincts pour les prix de base, prix promotionnels, tarifs dégressifs, prix par groupe de Customers, listes de prix, coupons et prix pilotés par une application ou un ERP.
| Relation commerciale | Question de préparation | Élément indiquant que la préparation est suffisante |
|---|---|---|
| Groupe de Customers | Quels Customers en font partie et quel sens commercial ou d’accès porte le groupe ? | Exemples de Customers et résumé de la règle du groupe |
| Liste de prix | Quels Products ou variantes, devises, Customers ou canaux l’utilisent ? | Export de la liste de prix et carte d’affectation |
| Tarification dégressive | Quels seuils de quantité et contextes d’acheteurs s’appliquent ? | Exemples de Products avec seuils |
| Affectation de canal | Quels Products et Categories appartiennent à chaque canal ? | Matrice de catalogue par canal |
| Promotion | La règle est-elle actuelle, historique ou obsolète ? | Responsable de la règle et décision conserver/reconstruire/retirer |
Ne mélangez pas les prix historiques des Orders avec la configuration tarifaire active. Les Orders historiques ont besoin de leurs valeurs enregistrées ; le futur modèle tarifaire BigCommerce exige des règles et affectations préparées indépendamment.
Préparer les Customers et Orders historiques
Préparez des échantillons de Customers couvrant les acheteurs individuels, Orders invités, plusieurs adresses, groupes de Customers, statut fiscal, contexte d’entreprise ou B2B, champs personnalisés, préférences marketing, fidélité, abonnements et identifiants de comptes externes.
Préparez des exemples d’Orders couvrant :
- les Orders payés, en attente, annulés, remboursés et partiellement remboursés ;
- plusieurs états de traitement et modes d’expédition ;
- remises, coupons, cartes cadeaux, taxes, droits et ajustements manuels ;
- sélections de variantes et modifiers ;
- contexte de groupe de Customers ou de liste de prix ;
- origine du canal ou de la marketplace ;
- références ERP, comptables, CRM et de traitement des commandes.
| Question de préparation | Élément | Condition de préparation |
|---|---|---|
| Comment les Customers en double sont-ils traités ? | Exemples de doublons et clés de rapprochement | Les règles de conservation séparée et de fusion sont documentées |
| Quels groupes de Customers restent en place ? | Liste des groupes et fonction commerciale | Chaque groupe conservé a un propriétaire et une règle associée |
| Quels détails d’Order les équipes de support doivent-elles voir ? | Dossier représentatif d’Order | Lignes, modifiers, totaux, statuts, remboursements et références sont expliqués |
| Quels identifiants externes restent opérationnels ? | Carte des clés entre systèmes | Chaque clé est attachée au bon niveau d’entité |
| Quels champs sensibles sont inutiles ? | Périmètre de champs approuvé | Les données exclues sont documentées avant migration |
Préparer les contenus, URL et entrées de redirection
Créez un inventaire des chemins pour les Products, Categories, marques, CMS Pages, Blog Posts, pages de campagne, fichiers et contenus localisés. Ajoutez leur importance pour le trafic, le chiffre d’affaires, les backlinks, les médias payants, le service client ou la conformité lorsqu’elle est connue.
Pour chaque chemin prioritaire, consignez :
- le chemin source ;
- le Product, la Category, la page, le Blog Post, le canal ou la destination externe prévu dans BigCommerce ;
- le propriétaire du contenu ;
- les métadonnées et besoins de liens internes ;
- le périmètre du canal et de la locale ;
- le besoin de redirection ou la décision de retrait.
Séparez les enregistrements de contenu de la présentation du thème et du Page Builder. Une page source peut contenir du contenu réutilisable, des références Product, formulaires, widgets, scripts et définitions de mise en page qui nécessitent des propriétaires cibles différents.
Inventorier les applications, metafields et systèmes externes
Créez un registre de dépendances pour les applications, scripts personnalisés, champs personnalisés, metafields, webhooks et systèmes connectés. Incluez les avis, la recherche, les abonnements, bundles, fidélité, B2B, personnalisation, fiscalité, expédition, paiements, marketplaces, ERP, PIM, WMS, CRM, comptabilité, analytics et systèmes de consentement.
Pour chaque dépendance, documentez :
- la fonction métier ;
- les enregistrements créés ou modifiés ;
- les Products, Customers, Orders ou contenus associés ;
- le propriétaire actuel des données et le futur propriétaire ;
- les éléments disponibles par export ou API ;
- les identifiants externes ;
- si la dépendance sera conservée, remplacée ou retirée.
Le registre est prêt lorsqu’aucune valeur personnalisée importante n’est décrite seulement comme « provenant d’une application ».
Sélectionner des échantillons représentatifs pour tester la migration BigCommerce
Choisissez un ensemble compact couvrant les relations ordinaires et exceptionnelles.
| Échantillon | Objectif de préparation |
|---|---|
| Product simple | Établir le modèle ordinaire de Product, Category, média, prix et stock |
| Product riche en variantes | Révéler l’identité Product/variante, les options, le stock, les images et identifiants externes |
| Product piloté par des modifiers | Révéler les saisies de l’acheteur qui ne doivent pas devenir des variantes suivies en stock |
| Product avec champs personnalisés ou metafields | Révéler la propriété des données personnalisées structurées |
| Product avec contexte de groupe de Customers ou de liste de prix | Révéler les relations commerciales conditionnelles |
| Product ou Category propre à un canal | Révéler les affectations de canal et le périmètre localisé |
| Customer complexe | Révéler les groupes, adresses, champs personnalisés et identifiants externes |
| Order historique complexe | Révéler modifiers, remises, traitement des commandes, remboursements et contexte de canal |
| Chemin de contenu prioritaire | Révéler la préparation des pages, métadonnées, liens internes et redirections |
Associez à chaque échantillon les identifiants source, URL source, propriétaires cible attendus, clés externes et exclusions connues. Le registre d’échantillons doit expliquer ce que représente l’enregistrement source, quelles relations comptent et quels éléments l’accompagnent. Incluez au moins un enregistrement ordinaire et un enregistrement exceptionnel pour chaque grand domaine opérationnel. Lorsque plusieurs structures source sont réellement différentes, utilisez des échantillons séparés plutôt que de demander à un seul Product ou Order de représenter des modèles contradictoires.
Vérifier le niveau de préparation à BigCommerce
| Question de préparation | Élément requis | Condition de préparation |
|---|---|---|
| Les accès sont-ils complets ? | Journal des accès | Les zones nécessaires de la source et de la destination sont disponibles |
| Les relations Product sont-elles classifiées ? | Carte des familles de Products et matrice d’options | Variantes, modifiers, champs personnalisés et données d’applications ont un propriétaire |
| Les relations tarifaires et de canaux sont-elles documentées ? | Matrices prix et canaux | Les affectations groupe, liste, Product, devise et canal sont explicites |
| Customers et Orders sont-ils représentés ? | Registre d’échantillons | Les principaux modèles de comptes et d’Orders historiques sont couverts |
| Les chemins prioritaires sont-ils définis ? | Inventaire des URL | Chaque chemin source prioritaire possède une destination ou une décision de retrait |
| Les dépendances ont-elles un propriétaire ? | Registre des applications et intégrations | Chaque dépendance importante possède un propriétaire qui continue à en être responsable |
| Les sauvegardes et exports sont-ils actuels ? | Archive datée | Les éléments de la source peuvent être récupérés indépendamment |
| Les décisions ouvertes sont-elles maîtrisées ? | Journal des décisions | Les éléments critiques ont un responsable et une échéance |
La préparation est complète lorsque l’équipe de migration peut expliquer comment chaque relation source à forte valeur doit être représentée dans BigCommerce sans dépendre d’hypothèses non documentées. Des points ouverts peuvent subsister, mais chacun doit avoir un responsable, un besoin d’élément clairement défini et une date de décision antérieure au début du travail de migration concerné.
Conclusion
La préparation BigCommerce doit produire un modèle fondé sur des éléments vérifiables pour les Products, variantes, modifiers, Categories, prix, groupes de Customers, canaux, Customers, Orders, contenus et intégrations. Le travail le plus important n’est pas d’exporter davantage d’enregistrements, mais de définir quel objet BigCommerce détient chaque relation et de collecter des échantillons qui rendent visible la complexité réelle.
Un dossier de préparation rigoureux fournit au test de migration représentatif un jeu d’échantillons source traçable et des responsabilités de préparation claires.
Questions fréquentes
Que faut-il préparer avant d’exporter un catalogue pour une migration vers BigCommerce ?
Définissez la propriété des Products et variantes, distinguez les modifiers des variantes, documentez les Categories et canaux, et identifiez les relations de prix et de données personnalisées. L’export devient plus utile lorsque l’équipe sait ce que signifie chaque valeur de la source.
Pourquoi préparer séparément les groupes de Customers et les listes de prix ?
Un groupe classifie les Customers, tandis qu’une liste de prix affecte des valeurs commerciales dans des conditions définies. Préserver l’un sans l’autre peut laisser la segmentation des Customers ou la tarification Product incomplète.
Quels Products BigCommerce doivent figurer dans le jeu d’échantillons représentatif ?
Incluez un Product simple, un Product riche en variantes, un Product piloté par des modifiers, un Product avec données personnalisées, un Product à tarification conditionnelle et un Product propre à un canal. Ajoutez toute configuration spécifique à la plateforme présentant un risque important pour le chiffre d’affaires ou les opérations.
Chaque Category source doit-elle devenir une Category BigCommerce ?
Non. Certains regroupements source sont des liens de navigation, filtres, collections de campagne, structures de marque ou classifications internes. Affectez chaque regroupement selon sa fonction qui doit continuer après migration.
Quels éléments d’Order faut-il préparer ?
Préparez des Orders contenant des sélections de variantes et modifiers, remises, taxes, expéditions, plusieurs statuts, remboursements et références de systèmes externes. Les échantillons doivent expliquer le sens historique sans définir la future configuration du checkout.
Quand la préparation BigCommerce est-elle terminée ?
Elle est terminée lorsque les accès fonctionnent, que les éléments de la source sont à jour, que les Products et relations commerciales ont des propriétaires cible, que les URL prioritaires sont mappées, que les dépendances sont inventoriées et que les échantillons représentatifs sont documentés.