Si Wix est retenu comme plateforme cible, la préparation doit séparer enregistrements commerciaux, contenu du site, identité Member, données CRM, collections CMS, applications et code personnalisé avant toute exécution. Wix Stores, Wix Contacts, Wix Members, Wix CMS, Wix Blog et l’écosystème d’applications Wix peuvent tous participer à un même site, mais ils ne possèdent pas les mêmes enregistrements.
Un dossier de préparation utile consigne quatre éléments pour chaque domaine majeur : action requise, responsable, éléments à fournir et condition de préparation. Cela évite de confondre un enregistrement Product avec une implémentation complète de l’interface de vente, un Contact avec un Member ou une collection CMS avec des données possédées par une application.
Confirmer le modèle opérationnel du site et du commerce Wix
Définissez quels produits Wix et quelles couches du site fonctionneront dans la boutique cible.
| Domaine de préparation | Décision à consigner | Responsable | Élément de préparation |
|---|---|---|---|
| Wix Stores | Déterminer si Products, processus de commande, Orders, stock et traitement sont centraux dans la cible | Responsable commerce | Synthèse du fonctionnement de la boutique |
| Structure du site Wix | Définir pages, menus, pages dynamiques, espaces Member et routes régionales requis | Responsable site | Carte des pages et de la navigation |
| Wix Contacts et Members | Définir quelles identités sont Contacts, Customers, Members, abonnés ou participants d’applications | Responsable Customer | Matrice de classification des identités |
| Wix CMS | Définir collections personnalisées, références, permissions et pages dynamiques nécessaires | Responsable contenu/données | Inventaire des collections et relations |
| Applications Wix | Identifier les enregistrements appartenant à Wix Blog, Bookings, Pricing Plans, Reviews, Events ou autres applications | Responsables applicatifs | Registre de dépendances application par application |
| Systèmes externes | Définir quels ERP, PIM, WMS, CRM, marketplace, systèmes fiscaux, expédition ou analytique restent autoritaires | Responsable technique | Carte des systèmes de référence |
Le modèle opérationnel est prêt lorsque chaque famille d’enregistrements possède un propriétaire Wix ou externe prévu et que l’équipe distingue clairement ce qui relève des données migrées de ce qui relève de la configuration du site Wix.
Préparer accès, archives source et responsabilité des changements
Collectez :
- accès administrateur à la plateforme source et au site Wix ;
- permissions requises pour Wix Stores, Contacts, Members, CMS, Blog, applications, domaines et SEO ;
- exports ou sauvegardes datés de Products, Customers, Orders, contenu, médias, Categories, URLs, Reviews et données personnalisées ;
- exports d’applications et documentation API lorsqu’ils existent ;
- identifiants externes utilisés par ERP, CRM, entrepôt, marketplace ou systèmes de traitement ;
- un responsable des changements source pour Products, Customers, Orders, contenu et stock pendant la fenêtre de migration.
| Élément | Pourquoi il compte | Condition de préparation |
|---|---|---|
| Registre d’accès | Confirme que les zones source et Wix nécessaires peuvent être inspectées | Les responsables disposent des permissions nécessaires. |
| Archive source datée | Préserve un état de référence récupérable | Les fichiers s’ouvrent correctement et comportent les dates d’export. |
| Archive média | Protège médias Product, pages, Blog Posts et CMS | Les fichiers et relations source peuvent être identifiés. |
| Inventaire des applications | Rend visibles les enregistrements hors des exports ordinaires catalogue/contenu | Chaque application active possède un responsable et une source d’éléments. |
| Registre des IDs externes | Protège synchronisation et rapprochement | Chaque clé est affectée au bon niveau d’entité. |
| Journal des changements | Consigne les mises à jour après l’archive de référence | Changements Product, Order, Customer, contenu et stock ont des responsables identifiés. |
Lorsqu’une application source ne fournit pas d’export, consignez la limite et le responsable au lieu de traiter ces données comme absentes.
Préparer Products, options, variantes, modifiers et médias
Catalog V3 représente chaque Product au moyen d’au moins une variante. Les options Product créent des variantes, tandis que les modifiers collectent des informations supplémentaires sans créer de variante. Préparez des familles Product représentatives qui révèlent ces différences.
Incluez :
- Products simples avec une variante par défaut ;
- Products avec plusieurs combinaisons d’options ;
- SKU, code-barres, prix, coût, poids, médias et stock propres aux variantes ;
- modifiers tels que messages cadeaux, personnalisation ou sélections supplémentaires ;
- Products numériques et fichiers numériques au niveau variante lorsque pertinent ;
- Products comportant Brands, Ribbons, Info Sections, Categories et Customizations réutilisables ;
- bundles, subscriptions, bookings ou fonctionnement Product possédé par des applications ;
- identifiants ERP, PIM, marketplace, fournisseur et traitement.
| Fonctionnement source | Décision de préparation | Éléments requis | Condition de préparation |
|---|---|---|---|
| Un choix crée une combinaison vendable | Définir choix d’option et responsabilité de variante | IDs parent/enfant, SKU, prix, poids, médias et stock | Chaque combinaison possède une variante Wix prévue. |
| Un choix collecte une information acheteur | Définir responsabilité du modifier ou de l’application | Type de saisie, valeurs autorisées, effet sur le prix et exemple de ligne Order | La valeur n’est pas mal classée comme porteuse de stock. |
| Un Product possède des données descriptives structurées | Définir propriétaire : champ Product, Info Section, Brand, Category, CMS ou application | Schéma de champ et consommateur durable | Chaque champ possède un propriétaire Wix ou externe identifié. |
| Le fonctionnement Product appartient à une application | Identifier l’application durable ou son remplacement | Enregistrements Product liés et éléments de configuration | Les données applicatives requises figurent dans le registre de dépendances. |
| Le Product utilise des données maîtres externes | Définir système de référence et clé | IDs ERP/PIM et exemples de recherche | Chaque identifiant reste attaché à la bonne variante ou au bon Product. |
Le catalogue est prêt lorsque chaque modèle Product majeur possède une structure Product-variante-option-modifier définie et que les éléments source distinguent les données Product réutilisables des saisies acheteur ou enregistrements possédés par une application.
Préparer emplacements de stock et règles de disponibilité
Dans Catalog V3, le stock est suivi au niveau variante-emplacement. Chaque Inventory Item relie une variante à un emplacement et peut utiliser quantité ou statut de disponibilité, avec paramètres de précommande lorsque pertinent.
Préparez :
- liste des entrepôts, boutiques, centres de traitement et emplacements virtuels ;
- emplacement de stock Wix par défaut ;
- IDs Product et variante utilisés par chaque source de stock ;
- exemples de quantité, disponibilité, illimité, précommande et indisponible ;
- affectations des emplacements source vers Wix ;
- futur système de référence du stock ;
- quantités d’ouverture et horodatage ou instantané source qu’elles représentent.
| Cas de stock | Responsable | Élément | Condition de préparation |
|---|---|---|---|
| Stock mono-emplacement | Responsable stock | Rapport de quantité par variante | Chaque quantité correspond à une variante Wix à l’emplacement par défaut. |
| Stock multi-emplacements | Responsable opérations | Matrice variante-emplacement | Chaque emplacement source possède une destination Wix ou externe prévue. |
| Stock possédé par ERP/WMS | Responsable intégration | Clé système et exemple de synchronisation | Valeurs d’ouverture Wix et autorité future sont documentées. |
| Product en précommande | Responsable merchandising | Règles de précommande variante-emplacement | Capacité de précommande et responsabilité de disponibilité sont claires. |
| Suivi de disponibilité sans quantité | Responsable catalogue | Products représentatifs et états source | Les états de disponibilité ne sont pas confondus avec des quantités numériques. |
Ne cumulez pas le stock propre à plusieurs emplacements sauf si la cible utilise volontairement un pool consolidé. La condition de préparation est une correspondance maîtrisée entre identité vendable source, emplacement et Inventory Item Wix prévu.
Préparer Contacts, Members, Customers et contexte marketing
Wix Contacts et Wix Members sont reliés mais distincts. Contacts peut porter identité, labels, état d’abonnement et champs étendus. Members possède IDs Member, statut de compte, visibilité du profil et relations Members Area. Customers commerciaux et participants d’applications peuvent ajouter d’autres contextes.
Préparez :
- acheteurs enregistrés, invités, abonnés, Contacts, Members et participants d’applications ;
- exemples de doublons d’emails et téléphones ;
- labels Contact, champs personnalisés, état d’abonnement et éléments de consentement ;
- exigences de statut Member, confidentialité, profil, badge et champs personnalisés ;
- adresses et relations historiques Order ;
- responsabilité fidélité, booking, pricing plan, communauté ou CRM ;
- identifiants externes Contact, Customer et Member.
| Type d’identité | Responsable | Éléments requis | Condition de préparation |
|---|---|---|---|
| Acheteur ou invité | Opérations Customer | Exemples Customer et Order | Le contexte commercial historique est relié à l’enregistrement Contact ou Customer prévu. |
| Contact | Responsable CRM | Labels, champs, état d’abonnement et source du consentement | La signification Contact est documentée indépendamment du membership. |
| Member du site | Responsable Members Area | Member ID, Contact ID, statut, profil et attentes d’accès | IDs Member et Contact ne sont pas considérés interchangeables. |
| Participant d’application | Responsable application | Enregistrements booking, plan, fidélité, Review ou communauté | La relation applicative possède un propriétaire durable. |
| Enregistrement CRM externe | Responsable intégration | ID CRM et règle de correspondance | La clé durable est attachée à l’identité Wix correcte. |
L’authentification doit être préparée séparément de l’identité. Si les mots de passe source ne peuvent pas être réutilisés, consignez le responsable et le besoin de communication Customer sans traiter la portabilité des mots de passe comme une donnée Customer ordinaire.
Préparer les Orders historiques et le contexte des transactions
Sélectionnez des Orders qui révèlent identité Product/variante, modifiers, remises, taxes, facturation, expédition, paiement, transactions, traitement, remboursements et références externes.
Incluez :
- Orders ordinaires, annulés, remboursés et partiellement traités ;
- Orders avec variantes Product et modifiers ;
- Orders d’invités et de Customers enregistrés ;
- plusieurs expéditions ou enregistrements de traitement ;
- Orders provenant d’applications pertinentes pour Wix ou de canaux externes ;
- références marketplace, comptabilité, ERP, WMS, CRM ou support.
| Domaine historique | Élément | Condition de préparation |
|---|---|---|
| Articles achetés | Exemples Product, variante, modifier, quantité et prix | La configuration achetée est explicable à partir du dossier source. |
| Contexte Customer | Identité invité/enregistré et adresses | Relation Contact, Customer ou Member prévue est documentée. |
| Contexte paiement/remboursement | Exemples de méthode, transaction, remboursement et total | Références historiques séparées de la configuration de paiement Wix actuelle. |
| Contexte de traitement | Expédition, suivi, statut et allocation de lignes | Le traitement passé est compréhensible sans configurer l’expédition active. |
| Filiation externe | IDs Order des systèmes connectés | Les clés de rapprochement sont conservées au bon niveau Order. |
Les Orders historiques préservent le commerce passé. Le processus de commande Wix actuel, les paiements, le traitement, les notifications et les paramètres de mise à jour du stock restent une préparation séparée appartenant aux équipes site et opérations responsables.
Préparer collections CMS, pages, Blog Posts, médias et URLs
Wix CMS peut contenir collections personnalisées, Data Items, champs de référence, permissions, index, relations de pages dynamiques et connexions à des bases externes. Les collections d’applications Wix peuvent refléter des données possédées par les applications. Préparez ces couches séparément.
Collectez :
- schémas, champs, références, permissions et index des collections CMS ;
- Data Items représentatifs et références parent-enfant ;
- pages dynamiques et champs de collection utilisés dans leurs routes ;
- CMS Pages, Wix Blog Posts, contenu Product/Category et contenu possédé par des applications ;
- inventaires d’images, vidéos, fichiers et textes alternatifs ;
- URLs à forte valeur, métadonnées, liens internes, menus, redirections et plans de domaine ;
- responsabilité des bases externes et dépendances de connexion.
| Domaine de contenu | Responsable | Éléments requis | Condition de préparation |
|---|---|---|---|
| Collection CMS | Responsable données/contenu | Schéma, champs, références, permissions et items exemples | Chaque collection possède une finalité métier et une route ou un consommateur. |
| Collection d’application Wix | Responsable application | Nom de l’application, enregistrements source et attentes lecture/écriture | Les données applicatives ne sont pas considérées comme une collection personnalisée ordinaire. |
| CMS Page ou Blog Post | Responsable éditorial | Contenu, contexte auteur/date, médias, métadonnées et URL source | Chaque enregistrement possède un propriétaire de contenu Wix et une route prévus. |
| Page dynamique | Responsable site | Collection, champ slug, champs de référence et correspondance de page | La page peut être reconstruite à partir des relations documentées. |
| URL prioritaire | Responsable SEO | Chemin source, destination, redirection et décision de retrait | Chaque chemin à forte valeur possède un résultat approuvé. |
Les redirections d’URL Wix ont des contraintes propres à la plateforme ; les modèles source non pris en charge doivent donc être identifiés dans le registre de routes avant l’exécution plutôt qu’après le retrait des chemins source.
Inventorier applications, logique Velo, APIs et systèmes externes
Créez un registre de dépendances pour chaque application Wix, application source, API, webhook, automatisation, fonction Velo, service plugin, base externe et plateforme métier connectée.
Pour chaque dépendance, consignez :
- finalité métier ;
- Products, variantes, Contacts, Members, Orders, items CMS ou contenu affectés ;
- système faisant autorité et IDs externes ;
- disponibilité d’un export ou d’une API ;
- responsable de la configuration et des identifiants ;
- destination durable, remplacement ou décision de retrait ;
- éléments source nécessaires avant la configuration du processus cible.
Les dépendances prioritaires incluent ERP, PIM, WMS, CRM, fiscalité, expédition, marketplace, fidélité, subscriptions, bookings, events, pricing plans, memberships, Reviews, recherche, analytique et plateformes marketing.
Le registre est prêt lorsque chaque champ personnalisé ou enregistrement applicatif actif possède un propriétaire, une entité parent, un consommateur durable et une clé stable.
Sélectionner des échantillons représentatifs de migration
| Échantillon | Objectif de préparation |
|---|---|
| Product simple | Établir le modèle ordinaire Product et variante par défaut. |
| Product avec plusieurs options et variantes | Exposer responsabilité des options, SKU, médias, prix et variantes. |
| Product avec modifiers | Exposer saisies acheteur et relations de ligne Order. |
| Inventory Item multi-emplacements | Exposer responsabilité variante-emplacement et autorité du stock. |
| Contact lié à un Member | Exposer IDs Contact/Member distincts et contexte de profil. |
| Order historique complexe | Exposer variantes, modifiers, paiement, remboursement, traitement et IDs externes. |
| Collection CMS avec références | Exposer schéma, liens parent-enfant, permissions et pages dynamiques. |
| Route de contenu prioritaire | Exposer responsabilité CMS, Blog, médias, URL et redirection. |
| Enregistrement possédé par une application ou externe | Exposer l’application durable et les identifiants parent stables. |
Pour chaque échantillon, consignez ID source, URL source si pertinente, raison métier, propriétaire Wix prévu, exclusions connues, clés externes et reviewer responsable.
Compléter le seuil de préparation Wix
| Question de préparation | Éléments requis | Condition de préparation |
|---|---|---|
| Accès et archives source sont-ils récupérables ? | Registre d’accès et exports/sauvegardes datés | Les enregistrements requis peuvent être inspectés indépendamment de la source en ligne. |
| Le modèle opérationnel Wix est-il défini ? | Carte de responsabilité site, Stores, Contacts, Members, CMS et applications | Chaque grande famille d’enregistrements possède un propriétaire prévu. |
| Structures Product et stock sont-elles préparées ? | Matrices Product/variante/modifier et variante-emplacement | Chaque grand modèle vendable possède une représentation définie. |
| Relations d’identité sont-elles préparées ? | Classification Contact/Member/Customer et règles de rapprochement | IDs, consentement, accès et relations applicatives sont documentés. |
| Éléments Orders et contenu sont-ils complets ? | Dossier Orders historiques et registre contenu/URLs | Transactions et routes sont explicables depuis les éléments source. |
| Applications et systèmes externes sont-ils inventoriés ? | Registre de dépendances | Chaque dépendance critique possède un propriétaire durable. |
| Échantillons représentatifs sont-ils sélectionnés ? | Registre d’échantillons | Complexité catalogue, stock, identité, Order, CMS et intégrations est couverte. |
| Les points non résolus sont-ils contrôlés ? | Journal de décision | Chaque point ouvert possède responsable et échéance. |
Le seuil est franchi lorsqu’aucune décision critique concernant Product, stock, Contact, Member, Order, CMS, URL, application ou système externe ne dépend d’une hypothèse non documentée.
Conclusion
La préparation d’une migration Wix doit produire un dossier d’éléments couvrant site et commerce qui sépare Wix Stores, Contacts, Members, CMS, Blog, applications et systèmes externes. Products doivent être reliés à leurs véritables variantes et modifiers, le stock affecté par variante et emplacement, les identités conserver leurs rôles distincts, et les données CMS ou applicatives avoir des propriétaires identifiés.
Lorsque ces décisions sont documentées avant le test de migration représentatif, l’échantillon peut révéler l’architecture Wix prévue sans transformer design du site, accès au compte ou configuration active en hypothèses sur les données migrées.
Questions fréquentes
Que faut-il préparer en premier pour une migration Wix ?
Commencez par la carte de responsabilité Wix. Définissez quels enregistrements appartiennent à Wix Stores, Contacts, Members, CMS, Blog, autres applications Wix et systèmes externes avant de préparer les exports détaillés.
Pourquoi options et modifiers Wix doivent-ils être préparés séparément ?
Les options créent des variantes, tandis que les modifiers collectent des informations supplémentaires sans créer de variante. Les combiner peut créer de faux SKUs ou supprimer des valeurs saisies par l’acheteur dans les lignes Order historiques.
Comment préparer le stock multi-emplacements ?
Préparez une matrice variante-emplacement indiquant quantités source, méthodes de suivi, règles de précommande, IDs d’emplacement et futur système de référence. Ne réduisez pas ces données à une seule quantité Product parent sauf consolidation volontaire.
Contacts et Members Wix sont-ils le même enregistrement ?
Non. Members sont généralement reliés à Contacts, mais Member ID et Contact ID sont distincts et les enregistrements servent des finalités différentes de compte, profil, confidentialité et CRM.
Que faut-il préparer pour les collections Wix CMS ?
Documentez finalité, schéma, champs, références, permissions, index, items représentatifs, pages dynamiques, connexions à des bases externes et propriétaire durable de chaque collection.
Quand la préparation Wix est-elle terminée ?
Elle est terminée lorsque accès, Products, emplacements de stock, Contacts, Members, Orders, contenu, collections CMS, routes, applications, systèmes externes, échantillons et décisions non résolues possèdent tous des responsables identifiés et des éléments récupérables.