Bagisto is an open-source ecommerce application built on Laravel. Its catalog, storefront channels and inventory sources give a merchant a defined operating structure, while packages and themes provide ways to extend it. Moving records into that structure is only part of making the destination usable.
For migration planning, distinguish three things:
- Source meaning: what a Product choice, customer classification, transaction or custom value represents today.
- Bagisto representation: the product type, attributes, relationships and channel context that will carry that meaning.
- Working implementation: the configuration, storefront and continuing systems that must use those records after launch.
Ordinary store administration does not require coding. Hosting, deployment, upgrades and custom code still need accountable technical ownership, whether internal or supplied by a partner. Choosing Bagisto does not require a headless storefront or extensive customization.
Use the Bagisto migration page to explore transfer directions. This overview explains the destination model behind that path decision; native features do not establish the data supported by a particular migration.
A Commerce Application with Separate Operating Responsibilities
Bagisto combines administrative commerce tools with an application that can be extended. The merchant may use its standard storefront and configuration, develop additional behavior, or connect a separate frontend. These choices create different implementation responsibilities around the same business records.
The distinction matters when a source store depends on an app, a manual workaround or a bespoke integration. A new Product record can preserve the description and price without recreating the process that previously controlled availability, account pricing or fulfillment.
| Area | What Bagisto organizes | Planning implication |
|---|---|---|
| Catalog | Product types, attributes and families, Categories, media, prices and stock relationships. | Select a representation for the actual offer, rather than treating every source row as the same kind of Product. |
| Storefront | Channels, themes, content, routes and discovery configuration. | Retain the intended audience and browsing context; receiving records does not deploy the storefront. |
| Operations | Customers and groups, Orders, invoices, shipments, refunds, transactions, taxes and inventory sources. | Keep usable history separate from live payment, shipping, tax and stock configuration. |
| Extension layer | Packages, APIs, custom product behavior and payment, shipping or theme development. | Name the owner of each additional requirement and establish whether the chosen build can represent it. |
This gives Bagisto a specific role in a replatforming project: it can be the application the business operates and develops, rather than merely a storage location for transferred data. The scope must say which capabilities will actually be used at launch and who maintains them.
For the separate suitability decision, see Bagisto fit profiles.
How the Catalog Defines an Offer
Product type and attribute family
A Bagisto Product has a type that governs its buying behavior and an attribute family that organizes its fields. The documented types include simple, configurable, virtual, downloadable, grouped, bundle and booking Products. An attribute family is a set of attributes arranged into groups; it is not another name for a Category.
A source size/color choice, grouped purchase or digital file therefore needs a meaningful target representation. A simple catalog may already map cleanly. Review complex cases before deciding that they require remodeling, and do not assume every custom source field needs custom code.
Useful distinctions include:
- Offer structure: independent items, variants, grouped quantities, bundle choices, downloads or booking behavior.
- Descriptive structure: technical specifications, merchandising fields and attributes used in filtering.
- Organization: Category hierarchy, placement, channel relevance and useful legacy routes.
The same words can describe different relationships in two platforms. Mapping a label without its purpose can preserve text while changing what buyers select or staff maintain.
Channels and inventory sources
A channel is a storefront context managed from the common admin panel. It has its own web address, theme, root Category, languages and currencies, and selects the inventory sources it sells from.
Inventory sources represent stock locations, such as a warehouse or shop. Bagisto tracks Product quantities by source. Storefront identity and stock location are therefore related decisions, rather than interchangeable labels.
For a business with several brands or warehouses, the intended channel and stock structure should explain where an offer is available and which location supplies it. A one-channel, one-location store can keep that model simple; additional structures should serve an actual requirement.
Customers, Commercial History and Continuing Rules
Customer groups provide a basis for group prices and catalog/cart promotion eligibility. They do not, by their names alone, establish company hierarchies, credit, approvals or private catalogs. Requirements of that kind belong to the selected B2B solution or other explicitly implemented behavior.
Keep the commercial areas connected without conflating their purposes:
- Customers: accounts, groups, addresses, communication preferences and required external references.
- History: Orders and the line, amount, status, invoice, shipment, refund, transaction, tax, discount and comment context staff need to interpret them.
- Future trading: current prices, promotions, payment methods, shipping, taxes, checkout and fulfillment configuration.
A retained invoice reference can support historical lookup without activating a payment process. Conversely, a configured payment method does not prove that old Orders retain their original meaning. The agreed migration path and record representation determine what can be transferred and how it remains useful.
Reviews, Coupons, CMS Pages, Blog Posts where used and other source records may also need a scope decision. Native Bagisto screens or source data types are not a promise that every corresponding field, relationship or behavior is included in the selected transfer.
Content, Discovery and Marketing Have Their Own Configuration
Bagisto provides CMS Pages, URL rewrites, search terms and synonyms, sitemaps, catalog/cart rules and marketing tools. Their presence does not automatically reproduce a source theme, ranking position, campaign or app-driven promotion.
Separate the intended outcomes:
- Content continuity: useful pages, media, internal links, metadata and audience context.
- Discovery: Category paths, search behavior, relevant filters and legacy URL destinations.
- Promotion: eligible buyers and Products, calculation rules, dates, coupons and the expected basket result.
- Communication: email templates, newsletter preferences and campaigns, with their required target settings.
Source content can supply material for the destination. Theme rendering, rich snippets, sitemap generation, search configuration and live rule execution require their own target decisions. Preserve a still-valid purpose without carrying every obsolete Category or campaign workaround into the new store.
Native Configuration, Packages and Headless Builds
Bagisto's package architecture supports extensions to products, payments, shipping, themes and integrations. The selected release and package combination define the available interfaces and behavior.
Current Bagisto developer documentation provides REST and GraphQL through a separate API package. Older releases use different packages and interfaces, so API capability should be confirmed against the intended build. It should not be assumed from a core installation or from instructions for another release.
| Requirement | What must be distinguished | Responsible decision |
|---|---|---|
| A source field fits a native attribute | Supported data translation versus target attribute/family setup. | Define its meaning and destination before treating it as a bespoke development need. |
| A source offer needs different behavior | Transferred values versus the implementation that sells or fulfills the offer. | Use an appropriate native model or agree a supported redesign and its owner. |
| A custom package owns records | Migration access and representation versus package schema/API readiness. | Have the package owner establish compatible inputs, consumers and a usable build. |
| A headless storefront is planned | API coverage versus frontend content, URLs, search, identity and checkout. | Own both the API integration and the complete buyer journey; record presence proves neither. |
| B2B or marketplace operation is required | Core commerce versus the selected company-buying or seller-management solution. | Qualify the actual account, vendor, pricing, approval and commission relationships; do not infer them from the platform name. |
Company buying, multi-vendor selling and a headless frontend are separate architectural choices. None should be inserted merely to make a Bagisto project appear more advanced.
For a non-standard source relationship that remains unresolved after supported-path review, prepare examples for a Custom Migration feasibility review. A tailored data review does not automatically include target package development or storefront implementation.
Define the Boundary of the Move
The practical migration scope separates several kinds of work. Their owners may coordinate, but one completed layer does not establish the others.
| Work area | Examples | Boundary |
|---|---|---|
| Supported record transfer | Agreed Products, Categories, Customers, Orders and other selected data types. | Availability and exact fields depend on the migration path and setup; a native feature list is insufficient. |
| Configuration alignment | Channels, locales, currencies, inventory sources, taxes, payment/shipping and checkout. | The target owner configures and assesses the intended operating environment. |
| Data interpretation | Product type and attributes, groups, statuses, URLs and legacy custom values. | Use compatible mappings or supported transformations; review unsupported relationships separately. |
| Implementation | Custom behavior, package-owned consumers, headless frontend and integrations. | Development and deployment need explicit scope, owners and working consumers. |
The platform data-model and migration boundaries explain why data translation and environment cloning are different expectations.
An early decision should identify whether the move primarily uses Bagisto's existing structures, changes the operating model, or also introduces a new application architecture. Each can be legitimate. The scope becomes misleading when it promises the third while defining only basic record transfer.
What Continuity Means for the New Store
Continuity means retaining the commercial purpose of the selected data and making the intended destination usable. It does not require preserving every legacy implementation detail.
Keep four outcomes visible:
- Commercial: Products, buyer prices, discounts and history remain understandable.
- Storefront: content, media, Categories, routes, search and theme behavior support the intended journey.
- Operational: stock sources, Orders, checkout and reporting have working ownership.
- Technical: packages, APIs, integrations, deployment and maintenance have accountable owners.
A Product count can confirm presence while missing its buying behavior or channel availability. Representative examples help expose that difference; detailed preparation and post-migration proof belong to their respective guides. No architecture choice by itself guarantees simpler operation or improved search performance.
Conclusion
Bagisto combines a structured commerce admin with an extensible Laravel application. The migration decision should explain the Product model, storefront and stock context, usable history and the implementation that will consume the data.
Preserve required commercial meaning, simplify obsolete structures deliberately and keep target configuration separate from transferred records. Use Selecting the Right Migration Approach for Bagisto when the next question is supported scope or execution responsibility.
Common Questions
Is Bagisto only suitable for highly technical merchants?
Merchants can perform ordinary administration without coding. The application still needs responsible hosting, upgrades and any custom development, which an internal team or partner can own. Suitability depends on that operating arrangement and the actual business requirements.
Does Bagisto require product data to be remodeled before migration?
A simple catalog may map directly. Review variants, bundles, grouped, virtual, downloadable, booking and custom patterns to choose a meaningful product type and attribute structure. Remodel only when the source representation does not fit the agreed target model.
Can Bagisto preserve customer and order history?
History can be included where the selected migration path supports its required records and relationships. Define the Customer, group, address, status, amount and invoice/shipment/refund references staff need. Native Sales features do not establish coverage of every source history field.
Are Bagisto extensions migrated automatically?
Package behavior is not established by transferring ordinary records. Identify extension-owned data, compatible schemas or interfaces and the continuing consumer. Additional data handling and target development need their own agreed scope.
What makes Bagisto migration different from a simple platform switch?
The intended product types, attribute families, channels, stock sources and packages determine how records become usable. A move can use standard configuration or introduce broader architecture work; the scope should distinguish those choices instead of assuming an application is copied with its data.