Bagisto does not treat an e-commerce catalog as one flat collection of Products and custom fields. Its Laravel-based architecture separates Product types, Product attributes, attribute families, Categories, channels, locales, currencies, inventory sources, Customer groups, Orders, CMS Pages, marketing records, packages, APIs, and optional commerce layers such as marketplace or B2B functionality. A source field becomes useful in Bagisto only when it reaches the layer that owns its commercial meaning.
That distinction changes migration scope. A size value may be descriptive content, a filterable attribute, or part of a configurable Product relationship. A quantity may belong to one inventory source rather than to the Product globally. A storefront may correspond to a Bagisto channel with its own root Category, locale, currency, theme, and inventory assignment. A company account or seller record may depend on an installed Bagisto package rather than the core Customer model.
The central question is therefore not whether Bagisto has a field with a similar label. It is whether the Target Store represents the same relationship: what the record belongs to, what it controls, and which other records must remain connected for the migrated data to retain its business meaning.
Bagisto Translates Records Through Commerce Layers
Bagisto combines core commerce entities with configuration and extension-owned structures. Two values that appear next to each other in a source export may belong to different destination layers. Product identity belongs to the catalog. The fields available for that Product are governed by its attribute family. Storefront scope belongs to channels. Stock ownership belongs to inventory sources. Customer segmentation belongs to Customer groups or to an installed B2B or marketplace layer. Presentation may belong to CMS Pages, themes, or a headless storefront.
| Source-side meaning | Likely Bagisto owner | Translation consequence |
|---|---|---|
| Sellable item | Product with a defined Product type | Product type determines child records, buying choices, fulfillment, and pricing behavior. |
| Product specification | Attribute assigned through an attribute family | A visible text value is not automatically filterable, comparable, or reusable. |
| Store, market, or domain | Channel with locale, currency, root Category, theme, and inventory relationships | Storefront scope must remain attached to the correct catalog and localization context. |
| Warehouse quantity | Inventory-source assignment and quantity | A global stock number can lose location ownership. |
| Customer segment | Customer group or package-owned account structure | Pricing and access meaning may not fit a single Customer field. |
| Historical sale | Order with lines, totals, addresses, invoices, shipments, refunds, and transactions | Order count alone does not preserve commercial history. |
| Custom commerce behavior | Bagisto package, custom module, API-owned record, or external system | Core-field mapping is insufficient when another component owns the relationship. |
This layered ownership is the reason one-to-one field mapping is unreliable. The same source value can require a different Bagisto destination depending on whether it affects Product selection, catalog management, localization, inventory, account treatment, reporting, or integration continuity.
Product Types Define Sellable Relationships
Bagisto supports several Product types, including simple, configurable, virtual, bundle, grouped, downloadable, and booking-oriented Products. Product type is not merely an admin label. It defines what is sold, whether child or linked Products exist, which fields are meaningful, how price and stock are interpreted, and what the buyer selects.
A source parent Product with color and size children may translate into a configurable Product whose variations carry their own SKUs, prices, quantities, images, or visibility. A kit may fit a bundle only when its components and selection rules match Bagisto’s bundle relationship. A grouped Product represents a collection of linked sellable Products rather than one inventory-bearing SKU. A downloadable Product requires file and access relationships. A booking-oriented Product adds availability and schedule meaning that does not exist in an ordinary Product row.
| Source pattern | Bagisto relationship to distinguish | Scope implication |
|---|---|---|
| Parent Product with child SKUs | Configurable Product and variations | Parent content and child commercial values must not be collapsed. |
| Optional component kit | Bundle Product and bundle selections | Component choice, quantity, and price behavior may require structural translation. |
| Merchandising set of independent items | Grouped Product and linked Products | Each linked Product remains independently sellable and inventory-bearing. |
| Non-physical service | Virtual Product or package-owned service structure | Shipping and fulfillment meaning differ from physical Products. |
| Digital item | Downloadable Product, files, links, and access rules | The file relationship is separate from Product text. |
| Scheduled service or rental | Booking Product or custom package structure | Availability and resource relationships cannot be represented as plain options. |
The Product-type decision also affects historical Orders. An Order line must remain understandable even if the Target Store represents the Product differently from the Source Store. Preserving the source Product name without preserving the chosen variation, bundle selection, download, or booking context would produce a technically present but semantically incomplete Order history.
Attributes and Attribute Families Govern Catalog Meaning
Bagisto attributes define structured Product information. Attribute families group the attributes available to a class of Products. This means a source catalog’s custom fields cannot be copied indiscriminately into one universal Bagisto Product shape.
A field used for filtering needs different treatment from a field used only for internal reference. A value that creates a configurable choice must be distinguished from descriptive specifications. A localized title, a price, a unique SKU, a boolean storefront flag, and a multi-select technical specification do not have the same input type, validation, indexing, or channel and locale behavior.
Attribute-family design therefore converts source catalog conventions into a governed Target Store schema. A merchant selling apparel, machinery, downloadable manuals, and bookable services may need separate families because each Product group requires different attributes and different commercial relationships.
| Source field behavior | Bagisto interpretation | What must remain true |
|---|---|---|
| Buyer chooses the value | Configurable attribute or Product-type-specific choice | The selected value identifies the correct sellable variation or result. |
| Shopper filters by the value | Filterable Product attribute | Values remain normalized enough to support meaningful filtering. |
| Staff compare Products by the value | Comparable or structured attribute | Equivalent facts do not remain buried in descriptions. |
| Field appears only for one Product class | Attribute assigned to a specific family | Unrelated Products are not forced into a bloated universal schema. |
| Value differs by locale or channel | Localizable or channel-scoped data where supported | The correct storefront context receives the correct value. |
| Value is internal integration metadata | Custom attribute, package record, or external identifier | Operational identifiers are not exposed or repurposed as storefront content. |
This separation prevents a common migration distortion: treating every source option, specification, tag, app field, and internal code as the same kind of Product attribute. Bagisto can hold rich Product data, but the value of that flexibility depends on assigning each fact to the correct family and behavior.
Categories, Channels, Locales, and Inventory Sources Form Storefront Scope
Bagisto Categories organize Products, but channel relationships determine which catalog and localization context a storefront uses. A channel can carry a hostname, root Category, locales, currencies, theme, and inventory-source assignments. Consequently, a source store, regional catalog, language site, or business-unit storefront may translate into more than a Category tree.
Categories can represent buyer navigation, merchandising landing pages, internal classification, or inherited legacy structure. Bagisto should receive the relationships that remain useful, not merely every historical Category label. The root Category assigned to a channel is especially important because it defines the top of that storefront’s catalog hierarchy.
Inventory sources add a separate ownership dimension. A Product can have stock distributed across locations. The source quantity must therefore be read together with warehouse, branch, supplier, pickup, or fulfillment context. Summing every location into one number may preserve total units while destroying location-level availability.
| Scope layer | Relationship carried in Bagisto | Typical source ambiguity |
|---|---|---|
| Category | Parent-child hierarchy, Product assignments, localized content, URL meaning | Source Categories may mix navigation, SEO, and internal grouping. |
| Channel | Domain, root Category, locale, currency, theme, and inventory-source context | A source “store” may actually represent a market, language, brand, or business unit. |
| Locale | Translated Product, Category, and content values | Language labels may be duplicated records or fields rather than linked translations. |
| Currency | Storefront display and commercial context | Historical Order currency must remain separate from current channel configuration. |
| Inventory source | Location-owned stock | One Product quantity may conceal several warehouses or stock pools. |
A migrated Product may exist correctly in Bagisto but remain invisible or commercially wrong if it is attached to the wrong Category root, unavailable in the intended channel, missing localized values, or assigned to the wrong inventory source. These are data-relationship failures even when every Product record is present.
Customers, Groups, Marketplace Sellers, and B2B Accounts Are Different Identities
Bagisto core Customer records include identity, contact, address, and group relationships. Customer groups can influence commercial treatment, including group pricing and rule eligibility. However, marketplace sellers, B2B companies, company users, approval roles, requisition lists, quotations, and purchase Orders may belong to optional Bagisto packages rather than to the core Customer record.
A source Customer tag such as wholesale, dealer, distributor, employee, tax-exempt, approved buyer, or marketplace seller must be interpreted by purpose. Some values belong in a core Customer group. Others represent a company account, seller organization, permission role, credit relationship, or external CRM classification. Flattening them into one text field preserves the label but removes the relationship that made it operational.
| Source identity | Bagisto destination question | Relationship to preserve |
|---|---|---|
| Individual shopper | Core Customer and addresses | Identity, contact details, account association, and Order history. |
| Commercial segment | Customer group or pricing relationship | The segment remains distinct from arbitrary tags. |
| Company buyer | B2B company and company-user structure when present | Users remain connected to the correct company, role, and commercial context. |
| Marketplace seller | Seller or vendor record owned by the marketplace package | Seller Products, Orders, commissions, payouts, and users remain linked. |
| External CRM or ERP account | Customer plus external identifier | The Target Store can reconcile the Customer with the authoritative external account. |
The correct destination depends on the actual Bagisto installation. Core Bagisto, Multi Vendor Marketplace, B2B Marketplace, B2B eCommerce, and multi-tenant packages do not expose one universal Customer schema. Their records should be treated as distinct ownership domains rather than assumed to be interchangeable.
Orders Preserve Historical Commercial Context
A Bagisto Order is related to Customer or guest identity, addresses, Order lines, selected Product configurations, prices, discounts, taxes, shipping, payment labels, statuses, invoices, shipments, refunds, and transactions. These related records explain what happened; the Order header alone does not.
Historical Orders also contain snapshots. Product names, prices, taxes, addresses, and option selections may reflect the moment of purchase even when the current Product or Customer later changes. Replacing those snapshots with current catalog values would alter history. Conversely, importing only totals without line-level and status context would make service and reporting work unreliable.
| Order relationship | Historical meaning |
|---|---|
| Order item | Product identity, SKU, quantity, price, selected configuration, and descriptive snapshot. |
| Address | Billing and shipping details at the time of purchase. |
| Invoice | Amount recognized or invoiced, which may differ from the Order’s lifecycle stage. |
| Shipment | Fulfillment record and shipped quantities. |
| Refund | Reversed value and affected lines or amounts. |
| Transaction | Payment-system reference and status evidence where available. |
| Order status | Source lifecycle meaning that may require a deliberate Target Store equivalent. |
The migration scope should preserve the level of Order detail needed for Customer service, account history, reporting, and external-system reconciliation. Current payment, shipping, tax, and notification behavior belongs to Target Store configuration; historical labels and amounts belong to the migrated Order context.
CMS, URLs, Marketing Records, and Search Data Have Separate Owners
Bagisto includes CMS Pages, URL rewrites, sitemaps, search terms, search synonyms, newsletter subscriptions, reviews, cart rules, and catalog rules. These records should not be merged into a generic “content” bucket because they serve different purposes.
CMS Pages carry page content and URL identity. Product and Category metadata belong to their catalog records. URL rewrites preserve route relationships. Search terms and synonyms influence discovery. Reviews belong to Customers and Products. Newsletter subscriptions represent consent and audience records. Cart and catalog rules encode conditions and actions rather than simple discount values.
| Source asset | Bagisto owner | Translation boundary |
|---|---|---|
| Informational page | CMS Page | Content, route, metadata, and navigation relationship are separate concerns. |
| Product or Category metadata | Catalog record | SEO fields should remain attached to the correct entity and locale. |
| Legacy URL or redirect | URL rewrite or redirect structure | The old path and destination relationship must remain explicit. |
| Search synonym | Search synonym record | A keyword pair is not ordinary page content. |
| Product review | Product-Customer review relationship | Rating, author, status, and Product association matter. |
| Promotion rule | Cart rule or catalog rule | Conditions, actions, dates, channels, and Customer groups form one rule structure. |
Marketing records are especially sensitive to semantic compression. A source coupon code without its eligibility conditions, dates, Customer scope, usage history, or discount action is not the same promotion in Bagisto. Where equivalent rule structures do not exist, the record should be represented as historical evidence or redesigned as Target Store configuration rather than forced into a misleading direct mapping.
Packages, APIs, Headless Storefronts, and Custom Tables Extend the Model
Bagisto is designed to be extended through Laravel packages, custom Product types, modules, REST or GraphQL APIs, webhooks or integration code, and headless storefronts. These capabilities create data that may not appear in the core Product, Customer, or Order tables.
A package can introduce its own entities, pivot relationships, configuration, statuses, permissions, and external identifiers. A headless storefront may consume core Bagisto data while keeping presentation content or search indexes elsewhere. An ERP, PIM, WMS, CRM, marketplace connector, or mobile application may treat Bagisto as one participant in a broader data system.
| Data owner | Examples | Migration implication |
|---|---|---|
| Bagisto core | Products, Categories, Customers, Orders, attributes, channels, inventory sources | Map according to native entity and relationship semantics. |
| Installed package | Marketplace sellers, B2B companies, booking resources, subscriptions, custom Product types | Inspect the package schema and preserve its links to core records. |
| Custom Laravel module | Bespoke tables, fields, workflow records, or event history | Define an explicit destination or archive decision for each active relationship. |
| Headless presentation layer | Page composition, search index, frontend-only content, cached identifiers | Do not assume storefront presentation is stored in Bagisto core. |
| External system | ERP item ID, CRM account ID, warehouse code, marketplace listing ID | Preserve identifiers needed to reconnect the Target Store to the authoritative system. |
The decisive question is ownership. A value stored near a Product does not automatically belong to the Product. It may belong to a package, an external system, or a presentation layer. The migration scope is complete only when those relationships are named and a destination is defined for the records that remain operationally necessary.
Bagisto Translation Decisions by Business Meaning
The final data-model decision should connect each source pattern to its Bagisto owner and to the consequence of choosing the wrong owner.
| Source pattern | Correct translation question | Consequence of a wrong assumption |
|---|---|---|
| Options with child SKUs and stock | Is this a configurable Product relationship? | Variant identity, inventory, or price becomes inaccurate. |
| Specifications reused across a Product class | Do they belong to attributes and an attribute family? | Filtering and catalog governance remain inconsistent. |
| Separate regional stores | Are they channels, locales, currencies, or independent installations? | Products and content appear in the wrong storefront context. |
| Warehouse-level quantities | Which inventory source owns each quantity? | Total stock may be right while location availability is wrong. |
| Wholesale or company Customers | Is the meaning a group, B2B company, company user, or external account? | Pricing, access, and account relationships are flattened. |
| Seller-owned Products and Orders | Does an installed marketplace package own the seller relationship? | Vendor ownership, commission, and payout context disappear. |
| Custom fields from a package | Which package entity and core record are linked? | Data is copied without the workflow that consumes it. |
A Bagisto migration becomes coherent when Products, attributes, channels, inventories, Customers, Orders, content, packages, and external identifiers are translated as connected structures. That preserves more than data presence: it preserves the commercial meaning that allows the Target Store to operate with the migrated records.
Conclusion
Bagisto migration requires relationship translation across catalog, storefront, inventory, Customer, Order, content, extension, and integration layers. Product types determine sellable structures. Attribute families govern Product information. Channels connect catalog, localization, and inventory context. Customer groups and optional B2B or marketplace packages define different account relationships. Orders depend on lines, snapshots, invoices, shipments, refunds, and transactions. Packages and external systems can own data that core Bagisto does not.
The strongest scope decisions identify the owner of every commercially important value and preserve the links among records. When source data is mapped only by field name, Bagisto’s flexibility can hide semantic loss. When it is mapped by purpose and relationship, the Target Store receives a catalog and commercial history that remain understandable and usable.
Common Questions
How are Bagisto configurable Products different from ordinary Product options?
A configurable Product connects a parent Product to sellable variations created from chosen attributes. The variations may carry their own SKU, price, quantity, image, or visibility. A text option that does not identify an independently managed variation should not automatically become the same structure.
Why do attribute families matter during Bagisto migration?
Attribute families determine which attributes belong to a Product class. They prevent every Product from receiving one oversized field set and help preserve the difference between apparel specifications, equipment data, downloadable content, booking details, and other Product-specific information.
Can one source store always become one Bagisto channel?
No. A source “store” may represent a domain, language, currency, brand, region, catalog, or independent business unit. The correct Bagisto model may use one channel with several locales, several channels, or separate installations depending on which relationships must remain independent.
How should warehouse stock be represented in Bagisto?
Stock should retain its inventory-source ownership when location matters. Combining all quantities into one Product total can remove warehouse, pickup, supplier, or fulfillment context even though the aggregate number remains correct.
Are marketplace sellers and B2B companies ordinary Bagisto Customers?
Not necessarily. Seller and company relationships may be owned by installed Bagisto marketplace or B2B packages. Those structures can include organization users, roles, catalogs, commissions, payouts, credit, quotations, or purchase Orders that do not fit the core Customer record.
What should happen to Bagisto package or custom-module data?
Identify the package or module, the core records it extends, and the business process that consumes its data. Active relationships need an explicit Target Store destination and preserved identifiers; obsolete records can be archived or excluded without pretending they are native Product or Customer fields.