Si Bagisto est retenu comme plateforme cible, la préparation doit documenter à la fois les enregistrements e-commerce et les structures de l’application Laravel qui les possèdent. Les Products peuvent dépendre de différents types de produits, familles d’attributs, canaux, langues, devises, sources de stock, groupes de Customers, Categories, médias, prix et clés d’URL. Les extensions et packages personnalisés peuvent ajouter des enregistrements marketplace, B2B, de réservation, d’abonnement, de paiement, d’expédition, d’API ou headless en dehors du modèle de catalogue ordinaire.
Chaque action de préparation doit identifier un responsable, un élément de référence et une condition permettant de considérer l’élément comme prêt. Le dossier de préparation doit distinguer les informations provenant de la source de l’implémentation de la cible : les relations Products, Orders historiques, pages CMS, URL, identifiants externes et enregistrements appartenant aux packages relèvent de la préparation de la migration ; le fonctionnement en production du paiement, de l’expédition, des taxes, des files de traitement, de la recherche, du thème et du checkout relève de l’implémentation de la boutique cible.
Sécuriser les accès à Bagisto, Laravel, la base de données, le stockage et la restauration
Confirmez l’accès à l’administration Bagisto, à l’hébergement ou à l’environnement cloud, aux fichiers de l’application Laravel, à la configuration d’environnement, à la base de données, aux stockages public et privé, aux médias Products, aux fichiers téléchargeables, à la configuration des files et du planificateur, aux journaux, à la gestion des packages et aux services connectés. Ne copiez pas les secrets dans les documents éditoriaux ; indiquez seulement qui les contrôle et où ils sont maintenus.
| Action de préparation | Responsable | Élément de référence | Condition de préparation |
|---|---|---|---|
| Confirmer l’accès à l’administration | Administrateur Bagisto | Compte fonctionnel et synthèse des autorisations | Products, attributs, Customers, Orders, canaux, stocks et données CMS peuvent être inspectés. |
| Confirmer l’accès à l’application et à la base | Responsable technique | Synthèse des accès hébergement, projet Laravel, base, stockage, files, planificateur et déploiement | La source de référence complète peut être identifiée. |
| Créer des sauvegardes restaurables | Responsable infrastructure | Dump de base, archive de l’application, archive stockage/médias/téléchargements et responsable de restauration | La boutique source peut être restaurée indépendamment de l’environnement en production. |
| Relever les versions et packages | Responsable développement | Inventaire Bagisto, Laravel/PHP, base, thème, packages, modules et code personnalisé | Les enregistrements dépendant d’une version et les extensions sont documentés. |
| Cartographier les systèmes externes | Responsables des intégrations | Endpoints ERP/PIM/WMS/CRM/marketplace/recherche/paiement/traitement et correspondances d’identifiants | Les systèmes qui continuent et les responsabilités de synchronisation sont connues. |
Préservez les identifiants internes et externes des Products, enfants Products, attributs, familles d’attributs, Categories, canaux, sources de stock, Customers, Orders, factures, expéditions, remboursements, données CMS, packages et intégrations.
Préparer les types de produits et les relations vendables
Bagisto prend en charge plusieurs types de produits dont les enregistrements et relations commerciales diffèrent. Les Products simples représentent les articles vendables ordinaires. Les Products configurables utilisent des attributs sélectionnables et des Products enfants associés. Les Products groupés et bundle référencent d’autres Products. Les Products téléchargeables et virtuels ont un sens différent pour le traitement, tandis que les Products de réservation peuvent porter rendez-vous, événements, locations, tables, créneaux, capacités et dates.
| Type de Product ou structure | Éléments à préparer | Condition de préparation |
|---|---|---|
| Product simple | ID Product, SKU, prix, Category fiscale, stock, dimensions, Category, canal, langue, médias et Order | Un enregistrement identifie clairement l’article vendu et traité. |
| Product configurable | Parent, Products enfants associés, attributs configurables, valeurs d’options, SKU enfants, prix, stocks et images | Chaque enfant vendable est traçable jusqu’au parent et aux attributs sélectionnés. |
| Product groupé | Parent, Products simples liés, quantités par défaut, ordre et Order représentatif | Le groupe reste distinct de l’identité de chaque Product composant. |
| Product bundle | Options du bundle, types de saisie, Products liés, quantités par défaut, caractère obligatoire, prix et lignes d’Order | La configuration du bundle et les relations avec ses composants sont complètes. |
| Product téléchargeable | Fichiers/liens, titre, prix, échantillon, limites, lien Product et Order terminé | Les éléments permettant l’accès numérique peuvent être récupérés. |
| Product virtuel | Identité du service, prix, disponibilité et contexte d’Order | Aucune expédition ni stock physique n’est inventé. |
| Product de réservation | Type de réservation, dates, créneaux, capacité, lieu, valeurs de billet/location, état d’annulation et enregistrement Order/réservation | Les relations liées au temps et à la capacité sont documentées. |
Ne supposez pas qu’un Product source avec des options doit devenir un Product configurable. Documentez si chaque choix crée un enfant vendable indépendant, un attribut descriptif, une sélection de bundle, un choix de réservation ou une donnée saisie ponctuellement par le Customer.
Préparer les attributs, familles d’attributs, Categories et médias
Les attributs Bagisto peuvent utiliser des types tels que texte, zone de texte, prix, booléen, sélection, sélection multiple et date-heure. Les familles regroupent les attributs disponibles pour créer et modifier les Products. Les Categories organisent les Products, tandis que les médias et clés d’URL restent rattachés à des Products ou Categories précis.
| Structure | Éléments de référence | Responsable | Condition de préparation |
|---|---|---|---|
| Attribut | Code, type, libellés, options, état obligatoire/unique, utilisation pour filtre/comparaison et fonctionnement langue/canal | Responsable catalogue | La fonction métier de chaque attribut est comprise. |
| Famille d’attributs | Code/nom, groupes d’attributs, affectations Products et dépendances de packages personnalisés | Responsable catalogue | Les Products peuvent être affectés sans perdre les champs nécessaires. |
| Attribut configurable | Attribut, valeurs d’options, Product parent, Products enfants et libellés des lignes d’Order | Responsable catalogue | L’identité de la variante est distincte des informations descriptives du Product. |
| Category | ID, hiérarchie, affectations Products, visibilité canal/langue, médias, métadonnées et clé d’URL | Responsables contenu/catalogue | La taxonomie et la propriété des routes publiques sont complètes. |
| Média | Product/Category propriétaire, rôle principal/galerie, chemin ou source distante, ordre et contexte du texte alternatif | Responsable contenu | Chaque ressource prioritaire est disponible et liée au bon enregistrement. |
| Champ personnalisé provenant d’un package | Schéma, entité propriétaire, type, relations et package consommateur | Responsable développement | Les données du package ne sont pas confondues avec les attributs Bagisto natifs. |
Créez un registre de champs distinguant identité vendable, description Product, filtrage, administration, clés d’intégration et état appartenant aux packages. Des libellés similaires ne doivent être fusionnés que si leur fonction métier est également équivalente.
Préparer les canaux, langues, devises et sources de stock
Les canaux Bagisto peuvent définir nom d’hôte, Category racine, langues, devises, thème, sources de stock et autres éléments de contexte de vitrine. Les sources de stock représentent des emplacements pouvant être affectés aux canaux, et les quantités Products peuvent exister par source.
| Zone de contexte | Éléments à préparer | Condition de préparation |
|---|---|---|
| Canal | ID/code, nom d’hôte, Category racine, langues, devises, thème, sources de stock et responsable | Chaque contexte client est listé une seule fois. |
| Langue | Code, champs traduits Products/Categories/contenus, règle de repli et affectations de canaux | Les données localisées restent liées au bon canal. |
| Devise | Code, usage comme devise de base/par défaut, affectation de canal et propriétaire des prix | Les valeurs commerciales ne sont pas séparées de leur contexte monétaire. |
| Source de stock | ID/code, nom, adresse, statut, priorité, affectations de canaux et identifiant d’entrepôt externe | Chaque emplacement possède une identité stable. |
| Quantité Product | ID Product/enfant, ID source, quantité, sens réservé/disponible lorsque pertinent et système de référence | L’unité vendable et le lieu correspondant à chaque quantité sont connus. |
| État Product propre au canal | Product/enfant, canal, statut, visibilité, différences de prix/contenu et Category | Le périmètre du Product est explicite au lieu d’être déduit globalement. |
Si un ERP, WMS, marketplace ou flux fournisseur contrôle les stocks, identifiez le système qui fait autorité et la clé qui le relie au Product Bagisto et à la source de stock.
Préparer les groupes de Customers, Customers, adresses et authentification
La préparation doit inclure l’identité du Customer, son groupe, ses adresses, l’état du compte, les consentements, avis, informations d’entreprise ou fiscales lorsqu’elles existent, identifiants externes et dépendances d’authentification. Des packages peuvent ajouter vendeurs marketplace, comptes d’entreprise, devis, abonnements, fidélité ou autres profils.
| Zone de compte | Éléments de référence | Responsable | Condition de préparation |
|---|---|---|---|
| Identité Customer | ID, email, nom, statut, groupe, contexte langue/canal et identifiant externe | Responsable données Customer | Les doublons et identités invitées sont résolus délibérément. |
| Groupe Customer | ID/code, membres, implications prix/accès et dépendances de packages | Responsable commerce | Le sens du groupe est documenté au-delà de son libellé. |
| Adresse | ID, lien Customer, usage facturation/expédition, pays/région, entreprise et champs fiscaux | Responsable service client | Les adresses enregistrées restent distinctes des instantanés historiques d’Orders. |
| Customer invité | Email et adresses de l’Order, contexte de support | Responsable Orders | L’historique invité ne nécessite pas de créer artificiellement un compte. |
| Authentification | Schéma de mot de passe, connexion sociale/SSO, MFA, procédure de réinitialisation et responsable des communications | Responsable sécurité | L’accès au compte est planifié sans supposer que les identifiants sont transférables. |
| Profil d’extension | ID Customer/utilisateur, entité du package, rôle, statut et données commerciales liées | Responsable du package | Les données de compte spécialisées ont une destination ou un propriétaire conservé. |
Incluez des Customers de différents groupes, des acheteurs invités, plusieurs adresses, des comptes inactifs et des types de comptes définis par extensions lorsqu’ils influencent Orders ou accès.
Préparer les Orders, factures, expéditions, remboursements et transactions
Préparez les Orders comme données historiques attestant ce qui s’est produit commercialement. Incluez en-têtes, Customers ou invités, adresses, lignes Products et enfants, options sélectionnées, quantités, prix, remises, taxes, expédition, libellés de paiement, historique des statuts, factures, expéditions, remboursements, transactions, notes et références externes. Les packages de réservation, marketplace, B2B ou personnalisés peuvent ajouter des enregistrements liés.
| Élément d’Order | Responsable | Condition de préparation |
|---|---|---|
| En-tête et lignes | Responsable données Orders | IDs Product/enfant, libellés instantanés, valeurs choisies, quantités, prix et contexte Customer sont complets. |
| Totaux et ajustements | Responsable finance | Sous-total, remise, taxe, expédition, frais, remboursements et total final se réconcilient. |
| Facture et expédition | Responsables finance/logistique | Numéros de documents, lignes et quantités expédiées, transporteur/suivi, dates et fichiers sont récupérables. |
| Remboursement | Responsables finance/support | Montants, lignes concernées, motifs, statuts et IDs de transactions liés sont documentés. |
| Transaction | Responsable finance | Libellé du moyen de paiement, référence, montant, statut et clé du prestataire externe sont connus. |
| Enregistrement d’Order appartenant à un package | Responsable du package | Réservation, vendeur, devis, abonnement ou données de processus personnalisées restent reliés à l’Order. |
| ID externe d’Order | Responsable intégration | La traçabilité ERP, marketplace, comptabilité ou traitement logistique est conservée. |
Les totaux historiques doivent rester des instantanés. Ils ne doivent pas être recalculés à partir des prix, Categories fiscales, groupes Customer, expédition ou configuration de paiement actuels.
Préparer les pages CMS, URL, recherche et contenus commerciaux
Le contenu Bagisto peut comprendre pages CMS, descriptions Products/Categories, métadonnées, clés d’URL, navigation, blocs de thème, bannières, termes de recherche, règles panier, règles catalogue et contenus d’email/notification. Des extensions peuvent ajouter des constructeurs de pages ou des sources de contenu headless.
| Zone de contenu | Éléments à préparer | Condition de préparation |
|---|---|---|
| Page CMS | ID, titre, clé d’URL, contexte canal/langue, statut, contenu, métadonnées et emplacement de navigation | Le contenu CMS reste distinct de la présentation du thème. |
| Contenu Product/Category | ID entité, langue/canal, description, métadonnées, images et route prioritaire | Le contenu du catalogue reste attaché à la bonne entité. |
| Navigation et bloc de thème | Propriétaire, hiérarchie/emplacement, objet lié, médias et dépendance package/thème | Les parcours clients ne sont pas déduits des seules données CMS ou Categories. |
| URL prioritaire | Propriétaire Product/Category/Page, langue/canal, chemin source, backlinks ou valeur de trafic et intention de destination | Chaque chemin important a une décision : conserver, modifier, fusionner, retirer ou rediriger. |
| Recherche et merchandising | Termes, synonymes, règles, Categories, état featured/new et système responsable | Les entrées de recherche/merchandising sont séparées des données maîtres Products. |
| Promotion historique | Règle/code, dates, conditions, Products/Customers concernés et références d’Orders | L’historique de remise reste distinct de la future configuration cible. |
Collectez les chemins prioritaires depuis les analytics, données de recherche, backlinks, campagnes, communications Customers et navigation interne plutôt que de vous fier uniquement au sitemap.
Inventorier les packages, tables personnalisées, API et dépendances headless
L’architecture Laravel de Bagisto permet aux packages et au code personnalisé d’enregistrer entités, tables, événements, tâches, API, structures marketplace/B2B, logique de réservation, paiement, expédition, recherche, flux et intégrations externes. Créez un registre de propriété avant de décider quels enregistrements entrent dans le périmètre.
| Dépendance | Éléments à préparer | Condition de préparation |
|---|---|---|
| Package/module | Nom, version, fournisseur, statut, fonction, responsable configuration, migrations/tables, modèles et enregistrements concernés | Les données appartenant au package ont une destination ou un propriétaire conservé. |
| Table ou modèle personnalisé | Schéma, clés, relations, événements, tâches et code consommateur | Les enregistrements personnalisés peuvent être interprétés plutôt que copiés aveuglément. |
| API ou client headless | Endpoints, ressources, responsable authentification, IDs, hypothèses de payload, routes et responsable déploiement | Les dépendances frontend/intégration sont documentées sans exposer les secrets. |
| Package marketplace/B2B | Vendeurs/entreprises, rôles, catalogues, devis, commissions, paiements, approbations et Orders liés | Les données commerciales spécialisées restent distinctes des Customers et Orders natifs. |
| Service de recherche/index | Champs indexés, IDs externes, enregistrements sources, responsable reconstruction et synonymes/règles | Les données d’index générées ne sont pas confondues avec du contenu de référence. |
| File/processus planifié | Tâche, déclencheur, payload, destination, responsable reprises/erreurs et entités concernées | L’automatisation opérationnelle reste distincte des données statiques migrées. |
| Données générées | Cache, journaux, sessions, files, index, imports temporaires et tables abandonnées | Les données techniques non autoritatives sont délibérément exclues. |
Les packages inactifs doivent rester dans le registre lorsque leurs données apparaissent encore dans Products, Customers, Orders, réservations, données vendeurs ou rapports.
Sélectionner des échantillons représentatifs pour tester la migration
Choisissez des enregistrements qui exposent les véritables types de Products, canaux, stocks, contextes Customers, Orders, contenus et packages de la Store. Consignez IDs source, SKU, clés d’URL, canal/langue, source de stock, clés externes, données liées et raison du choix de chaque échantillon.
| Échantillon | Éléments à préparer | Objectif |
|---|---|---|
| Product simple | Prix, taxe, stock, Category, canal, langue, médias et Order | Établit la référence d’un Product ordinaire. |
| Famille Product configurable | Parent, enfants, attributs configurables, options, SKU, prix, stock par source, images et Orders | Représente l’identité des variantes. |
| Product bundle/groupé/réservation | Relations de composants ou créneaux, quantités, prix, capacité, données de package et lignes d’Order | Représente une structure commerciale non simple. |
| Cas stock multicanal | Product/enfant, canaux, langues, devises, sources, quantités et IDs externes d’entrepôts | Représente le contexte et la propriété du stock. |
| Groupe Customer ou compte d’extension | Customer, groupe/profil, adresses, implications d’accès/prix et Order pertinent | Représente une identité segmentée ou définie par package. |
| Order complexe | Type de Product, options, remise, taxe, facture, expédition, remboursement, transaction et IDs externes | Représente l’historique commercial. |
| Cas CMS/URL | Page CMS ou contenu catalogue, langue/canal, clé d’URL, métadonnées, liens et intention de destination | Représente la propriété des contenus et routes. |
| Enregistrement de package | Entité native, modèle/table du package, champs personnalisés, tâches/événements et clé d’intégration | Rend visible le périmètre non natif avant exécution. |
Le dossier d’échantillons Bagisto est prêt lorsque chaque enregistrement choisi dispose d’une fiche d’attente source, du contexte canal/stock, des fichiers liés et d’un réviseur nommé.
Effectuer le contrôle final de préparation à Bagisto
| Zone de préparation | Condition de préparation |
|---|---|
| Accès et restauration | Administration, application Laravel, base, stockage, médias/téléchargements, sauvegardes et responsabilité de restauration sont confirmés. |
| Catalogue | Types de Products, enfants/composants, attributs, familles, Categories, médias, prix, stocks et identifiants sont traçables. |
| Canaux et stocks | Canaux, langues, devises, sources de stock, affectations Products, quantités et autorités externes sont documentés. |
| Customers et Orders | Comptes, groupes, adresses, Orders, lignes, totaux, factures, expéditions, remboursements, transactions et IDs externes disposent de références. |
| Contenus et URL | Pages CMS, contenus catalogue, navigation, chemins prioritaires, métadonnées, liens et décisions de redirection sont documentés. |
| Dépendances | Packages, tables/modèles personnalisés, API, clients headless, tâches, recherche et systèmes externes ont des responsables nommés. |
| Échantillons | Les enregistrements représentatifs couvrent chaque type important de Product, canal, Customer, Order, contenu et package. |
Le périmètre Bagisto est prêt lorsque chaque enregistrement important peut être relié à son propriétaire source, ses entités associées, son élément de référence et sa destination prévue ou au système qui continuera à le posséder.
Conclusion
La préparation d’une migration vers Bagisto exige des éléments coordonnés sur les accès Laravel et base de données, types de Products, attributs et familles, Categories, canaux, sources de stock, Customers, Orders, données CMS, URL, packages, API et systèmes externes. La liste de préparation doit rendre ces relations explicites avant l’exécution, plutôt que de traiter Bagisto comme une simple base Products-Customers-Orders.
Un dossier complet conserve des informations sources restaurables, sépare les enregistrements natifs des structures appartenant aux packages, distingue les transactions historiques de la configuration en production et attribue un responsable à chaque intégration ou dépendance personnalisée.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers Bagisto ?
Confirmez les accès à l’administration Bagisto, à l’application Laravel, à la base, au stockage, aux médias, téléchargements, files, planificateur et packages ; créez des sauvegardes restaurables ; puis relevez les versions Bagisto, Laravel, PHP, base de données, thème et packages.
Pourquoi faut-il inventorier séparément les types de Products Bagisto ?
Les Products configurables, groupés, bundle, téléchargeables, virtuels et de réservation utilisent des relations différentes pour les enfants, composants, fichiers, créneaux, capacités et Orders. Les traiter comme de simples Products supprimerait les structures qui les rendent vendables.
Comment préparer les attributs et familles d’attributs ?
Documentez codes, types, libellés, options, utilisation pour filtre ou comparaison, comportement obligatoire/unique, famille, affectation Product et appartenance éventuelle à un package personnalisé.
Pourquoi les canaux et sources de stock font-ils partie de la préparation ?
Les canaux peuvent définir nom d’hôte, langue, devise, Category racine, thème et périmètre des sources de stock. Les quantités Products peuvent appartenir à des sources précises ; un total global ne préserve donc ni le lieu ni le contexte de canal.
Quels Orders Bagisto sélectionner comme échantillons représentatifs ?
Incluez des Products simples et configurables, bundles ou réservations lorsque utilisés, remises, plusieurs taxes, factures, expéditions, remboursements, transactions, Customers invités et segmentés, IDs externes et relations d’Orders appartenant à des packages.
Que doit contenir le registre des packages et données personnalisées Bagisto ?
Consignez chaque package, table/modèle personnalisé, API, client headless, tâche, événement, service de recherche, composant marketplace/B2B et connecteur externe qui crée ou consomme des données métier. Chaque élément doit avoir un responsable, des enregistrements concernés, des éléments de référence et une décision de destination ou de système conservé.