Bagisto preparation must document both commerce records and the Laravel application structures that own them. Products can use different Product types, attribute families, channels, locales, currencies, inventory sources, customer groups, Categories, media, pricing, and URL keys. Extensions and custom packages can introduce marketplace, B2B, booking, subscription, payment, shipping, API, or headless records outside the ordinary catalog model.
Every preparation action should identify the owner, evidence artifact, and ready condition. The package should distinguish source evidence from target implementation: Product relationships, historical Orders, CMS Pages, URLs, external identifiers, and package-owned records belong to migration readiness; live payment, shipping, tax, queue, search, theme, and checkout behavior remains target-side implementation.
Secure Bagisto, Laravel, Database, Storage, and Recovery Access
Confirm access to the Bagisto administration area, hosting or cloud environment, Laravel application files, environment configuration, database, public and private storage, Product media, downloadable files, queue and scheduler configuration, logs, package management, and connected services. Do not copy secrets into editorial records; document only who controls them and where they are maintained.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administration access | Bagisto administrator | Working account and permission summary | Products, attributes, Customers, Orders, channels, inventory, and CMS records can be inspected. |
| Confirm application and database access | Technical owner | Hosting, Laravel project, database, storage, queue, scheduler, and deployment-access summary | The complete authoritative source can be identified. |
| Create recoverable backups | Infrastructure owner | Database dump, application archive, storage/media/download archive, and restoration owner | The source Store can be recovered independently of the live environment. |
| Record versions and packages | Development owner | Bagisto, Laravel/PHP, database, theme, package, module, and custom-code inventory | Version-dependent records and extensions are documented. |
| Map external systems | Integration owners | ERP/PIM/WMS/CRM/marketplace/search/payment/fulfillment endpoints and identifier maps | Continuing systems and synchronization authority are known. |
Preserve internal and external identifiers for Products, Product children, attributes, attribute families, Categories, channels, inventory sources, Customers, Orders, invoices, shipments, refunds, CMS records, packages, and integrations.
Prepare Product Types and Sellable Relationships
Bagisto supports several Product types whose records and commercial relationships differ. Simple Products represent ordinary sellable items. Configurable Products use selectable attributes and associated child Products. Grouped and bundle Products reference other Products. Downloadable and virtual Products have different fulfillment meaning, while booking Products can carry appointment, event, rental, table, slot, capacity, and date relationships.
| Product type or pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple Product | Product ID, SKU, price, tax Category, stock, dimensions, Category, channel, locale, media, and Order | One record clearly identifies the item sold and fulfilled. |
| Configurable Product | Parent, associated child Products, configurable attributes, option values, child SKUs, prices, stock, and images | Every sellable child is traceable to the parent and selected attributes. |
| Grouped Product | Parent, linked simple Products, default quantities, sort order, and representative Order | The group is separated from component Product identity. |
| Bundle Product | Bundle options, input types, linked Products, default quantities, required state, pricing, and Order lines | Bundle configuration and component relationships are complete. |
| Downloadable Product | Files/links, title, price, sample, limits, Product link, and completed Order | Digital access evidence is recoverable. |
| Virtual Product | Service identity, price, availability, and Order context | Shipping and physical inventory are not invented. |
| Booking Product | Booking type, dates, slots, capacity, location, ticket or rental values, cancellation state, and Order/booking record | Time- and capacity-based relationships are documented. |
Do not assume that a source Product with options should become a Configurable Product. Record whether each choice creates an independent sellable child, descriptive attribute, bundle selection, booking choice, or one-time Customer input.
Prepare Attributes, Attribute Families, Categories, and Media
Bagisto attributes can use types such as text, textarea, price, Boolean, select, multi-select, and date-time. Attribute Families group attributes for Product creation and editing. Categories organize Products, while media and URL keys remain attached to specific Products or Categories.
| Structure | Evidence | Owner | Ready condition |
|---|---|---|---|
| Attribute | Code, type, labels, options, required/unique state, filter/comparison use, and locale/channel behavior | Catalog owner | Each attribute’s business function is known. |
| Attribute Family | Family code/name, grouped attributes, Product assignments, and custom package dependencies | Catalog owner | Products can be assigned without losing required fields. |
| Configurable attribute | Attribute, option values, parent Product, child Products, and Order-line labels | Catalog owner | Variant identity is separate from descriptive Product data. |
| Category | Category ID, hierarchy, Product assignments, channel/locale visibility, media, metadata, and URL key | Content/catalog owners | Taxonomy and public route ownership are complete. |
| Media | Product/Category owner, primary/gallery role, file path or remote source, sort order, and alt context | Content owner | Every priority asset is available and linked to the correct record. |
| Custom field from a package | Schema, entity owner, type, relationships, and consuming package | Development owner | Package data is not mistaken for core Bagisto attributes. |
Create a field ledger that distinguishes sellable identity, Product description, filtering, administration, integration keys, and package-owned state. Similar labels should not be merged unless their business function is also equivalent.
Prepare Channels, Locales, Currencies, and Inventory Sources
Bagisto channels can define hostname, root Category, locales, currencies, theme, inventory sources, and other storefront context. Inventory sources represent stock locations that can be assigned to channels, and Product quantities can exist by source.
| Context area | Evidence to prepare | Ready condition |
|---|---|---|
| Channel | Channel ID/code, hostname, root Category, locales, currencies, theme, inventory sources, and responsible owner | Every customer-facing context is listed once. |
| Locale | Locale code, translated Product/Category/content fields, fallback behavior, and channel assignments | Localized records remain connected to the intended channel. |
| Currency | Currency code, base/default use, channel assignment, and price ownership | Commercial values are not detached from currency context. |
| Inventory source | Source ID/code, name, address, status, priority, channel assignments, and external warehouse ID | Every stock location has a stable identity. |
| Product quantity | Product/child ID, source ID, quantity, reserved or available meaning where applicable, and authoritative system | The sellable unit and location for each quantity are known. |
| Channel-specific Product state | Product/child, channel, status, visibility, price or content differences, and Category | Product scope is explicit rather than inferred globally. |
If an ERP, WMS, marketplace, or supplier feed controls stock, identify the source-of-truth system and the key that connects it to the Bagisto Product and inventory source.
Prepare Customer Groups, Customers, Addresses, and Authentication
Bagisto Customer preparation should include Customer identity, Customer group, addresses, account status, consent, reviews, company or tax information where present, external IDs, and authentication dependencies. Extension packages can add marketplace sellers, company accounts, quotes, subscriptions, loyalty, or other profiles.
| Account area | Evidence | Owner | Ready condition |
|---|---|---|---|
| Customer identity | Customer ID, email, name, status, group, locale/channel context, and external ID | Customer-data owner | Duplicate and guest identities are resolved deliberately. |
| Customer group | Group ID/code, members, pricing/access implications, and package dependencies | Commerce owner | Group meaning is documented beyond its label. |
| Address | Address ID, Customer link, billing/shipping use, country/state references, company, and tax fields | Customer-service owner | Saved addresses are distinct from historical Order snapshots. |
| Guest Customer | Order-level email, addresses, and support context | Order-data owner | Guest history does not require an invented account. |
| Authentication | Password scheme, social login/SSO, MFA, reset path, and communication owner | Security owner | Account access is planned without assuming credential portability. |
| Extension profile | Customer/user ID, package entity, role, status, and related commercial records | Package owner | Specialized account data has a destination or retained owner. |
Include Customers from different groups, guest buyers, several addresses, inactive accounts, and extension-defined account types where they affect Orders or access.
Prepare Orders, Invoices, Shipments, Refunds, and Transactions
Prepare Orders as historical commercial evidence. Include Order headers, Customers or guests, addresses, Product and child lines, selected options, quantities, prices, discounts, taxes, shipping, payment labels, status history, invoices, shipments, refunds, transactions, notes, and external references. Booking, marketplace, B2B, or custom packages may add related records.
| Order evidence | Owner | Ready condition |
|---|---|---|
| Order header and lines | Order-data owner | Product/child IDs, snapshot labels, selected values, quantities, prices, and Customer context are complete. |
| Totals and adjustments | Finance owner | Subtotal, discount, tax, shipping, fees, refunds, and final total reconcile. |
| Invoice and shipment | Finance/fulfillment owners | Document numbers, shipped lines, quantities, carrier/tracking, dates, and files are recoverable. |
| Refund | Finance/support owners | Amounts, affected lines, reasons, statuses, and related transaction IDs are documented. |
| Transaction | Finance owner | Payment method label, transaction reference, amount, status, and external provider key are known. |
| Package-owned Order record | Package owner | Booking, seller, quote, subscription, or custom workflow records remain linked to the Order. |
| External Order ID | Integration owner | ERP, marketplace, accounting, or fulfillment lineage remains traceable. |
Historical totals should remain snapshots. They should not be recalculated from current prices, tax Categories, Customer groups, shipping, or payment configuration.
Prepare CMS Pages, URLs, Search, and Commercial Content
Bagisto content can include CMS Pages, Product and Category descriptions, metadata, URL keys, navigation, theme blocks, banners, search terms, cart rules, catalog rules, and email or notification content. Extensions can introduce page builders or headless content sources.
| Content area | Evidence to prepare | Ready condition |
|---|---|---|
| CMS Page | Page ID, title, URL key, channel/locale context, status, content, metadata, and navigation placement | CMS content remains distinct from theme presentation. |
| Product/Category content | Entity ID, locale/channel, description, metadata, images, and priority route | Catalog-owned content stays attached to the correct entity. |
| Navigation and theme block | Owner, hierarchy/placement, linked object, media, and package/theme dependency | Customer paths are not inferred from CMS or Category records alone. |
| Priority URL | Product/Category/Page owner, locale/channel, source path, backlinks or traffic value, and destination intent | Every important path has a keep, change, merge, retire, or redirect decision. |
| Search and merchandising | Search terms, synonyms, rules, Categories, featured/new state, and responsible system | Search and merchandising inputs are separated from Product master data. |
| Historical promotion | Rule/code, dates, conditions, affected Products/Customers, and Order references | Historical discount evidence is separate from future target setup. |
Collect priority paths from analytics, search data, backlinks, campaigns, Customer communications, and internal navigation rather than relying only on a sitemap.
Inventory Packages, Custom Tables, APIs, and Headless Dependencies
Bagisto’s Laravel architecture allows packages and custom code to register entities, tables, events, jobs, APIs, marketplace or B2B structures, booking logic, payment and shipping behavior, search, feeds, and external-system integrations. Create an ownership ledger before deciding which records belong in scope.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| Package/module | Name, version, provider, status, purpose, configuration owner, migrations/tables, models, and affected records | Package-owned data has a destination or retained owner. |
| Custom table or model | Schema, keys, relationships, events, jobs, and consuming code | Custom records can be interpreted rather than copied blindly. |
| API or headless client | Endpoints, resources, authentication owner, IDs, payload assumptions, routes, and deployment owner | Frontend and integration dependencies are documented without exposing secrets. |
| Marketplace/B2B package | Sellers/companies, roles, catalogs, quotes, commissions, payouts, approvals, and linked Orders | Specialized commercial records remain distinct from core Customers and Orders. |
| Search/index service | Indexed fields, external IDs, source records, rebuild owner, and synonyms/rules | Generated index data is not mistaken for authoritative content. |
| Queue/scheduled process | Job, trigger, payload, destination, retry/error owner, and affected entities | Operational automation is separated from static migrated data. |
| Generated data | Cache, logs, sessions, queues, indexes, temporary imports, and abandoned tables | Non-authoritative technical data is excluded deliberately. |
Inactive packages should remain in the ledger when their data still appears in Products, Customers, Orders, bookings, seller records, or reports.
Select Representative Migration Test Samples
Choose records that expose the Store’s actual Product types, channels, inventory, Customer contexts, Orders, content, and packages. Record source IDs, SKUs, URL keys, channel/locale, inventory source, external keys, related records, and the reason each sample was selected.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, tax, stock, Category, channel, locale, media, and Order | Establishes the ordinary Product baseline. |
| Configurable Product family | Parent, children, configurable attributes, options, SKUs, prices, stock by source, images, and Orders | Represents variant identity. |
| Bundle/grouped/booking Product | Component or slot relationships, quantities, prices, capacity, package data, and Order lines | Represents non-simple commercial structure. |
| Multi-channel inventory case | Product/child, channels, locales, currencies, inventory sources, quantities, and external warehouse IDs | Represents context and stock ownership. |
| Customer-group or extension account | Customer, group/profile, addresses, access/pricing implications, and relevant Order | Represents segmented or package-defined identity. |
| Complex Order | Product type, options, discount, tax, invoice, shipment, refund, transaction, and external IDs | Represents historical commerce evidence. |
| CMS/URL case | CMS Page or catalog content, locale/channel, URL key, metadata, links, and destination intent | Represents content and route ownership. |
| Package-owned record | Core entity, package model/table, custom fields, jobs/events, and integration key | Exposes non-core scope before execution. |
The Bagisto sample package is ready when each selected record has a source expectation sheet, channel and inventory context, related files, and a named reviewer.
Complete the Final Bagisto Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Administration, Laravel application, database, storage, media/downloads, backups, and restoration ownership are confirmed. |
| Catalog | Product types, children/components, attributes, families, Categories, media, prices, stock, and identifiers are traceable. |
| Channels and inventory | Channels, locales, currencies, inventory sources, Product assignments, quantities, and external authorities are documented. |
| Customers and Orders | Accounts, groups, addresses, Orders, lines, totals, invoices, shipments, refunds, transactions, and external IDs have evidence. |
| Content and URLs | CMS Pages, catalog content, navigation, priority paths, metadata, links, and redirect decisions are documented. |
| Dependencies | Packages, custom tables/models, APIs, headless clients, jobs, search, and external systems have named owners. |
| Samples | Representative records cover every material Product type, channel, Customer, Order, content, and package pattern. |
The Bagisto scope is ready when every material record can be traced to its source owner, related entities, evidence artifact, and intended destination or retained system.
Conclusion
Bagisto preparation requires coordinated evidence across Laravel and database access, Product types, attributes and families, Categories, channels, inventory sources, Customers, Orders, CMS records, URLs, packages, APIs, and external systems. The checklist should make those relationships explicit before execution instead of treating Bagisto as a simple Product–Customer–Order database.
A complete readiness package preserves recoverable source evidence, separates core records from package-owned structures, distinguishes historical transactions from live configuration, and gives every integration or custom dependency a named owner.
Common Questions
What should be prepared first for a Bagisto migration?
Confirm Bagisto Administration, Laravel application, database, storage, media, download, queue, scheduler, and package access; create recoverable backups; and record the Bagisto, Laravel, PHP, database, theme, and package versions.
Why must Bagisto Product types be inventoried separately?
Configurable, grouped, bundle, downloadable, virtual, and booking Products use different child, component, file, slot, capacity, and Order relationships. Treating them as simple Products would remove the structures that make them sellable.
How should attributes and attribute families be prepared?
Document attribute codes, types, labels, options, filter or comparison use, required or unique behavior, family assignment, Product assignment, and whether the field belongs to core Bagisto or a custom package.
Why are channels and inventory sources part of preparation?
Channels can define hostname, locale, currency, root Category, theme, and inventory-source scope. Product quantities can belong to specific inventory sources, so a global stock total does not preserve location or channel meaning.
Which Bagisto Orders should be selected as representative samples?
Include simple and configurable Products, bundles or bookings where used, discounts, multiple taxes, invoices, shipments, refunds, transactions, guest and grouped Customers, external IDs, and package-owned Order relationships.
What belongs in the Bagisto package and custom-data ledger?
Record every package, custom table/model, API, headless client, job, event, search service, marketplace or B2B component, and external connector that creates or consumes business data. Each item needs an owner, affected records, evidence, and a destination or retained-system decision.