A Bagisto destination needs more than a catalog import: the attributes, channels, stock locations and application packages must agree about what each record means. Preparation should capture that meaning from the actual Source Store and identify who will implement the corresponding Bagisto behavior.
Document the intended Bagisto build and the Laravel application structures that will own the migrated records. Products can depend on Product types, attribute families, channels, locales, currencies, inventory sources, Customer groups, Categories, media and URL keys. Booking is part of the documented core Product model; installed or custom packages may extend it or introduce marketplace, B2B, subscription, payment, shipping, API or headless relationships. Record what is actually enabled rather than treating every package capability as available.
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.
Source access, evidence and recovery
Confirm the access needed to collect evidence from the actual Source, which may be a hosted Platform rather than Bagisto. Separately assign owners for destination administration, hosting, Laravel files, database, storage, package management, queues, scheduler and connected services. When Bagisto is also the Source, capture those source application and recovery dependencies explicitly. Record who controls credentials and where they are maintained without copying secrets into the preparation package.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administration access | Actual Source administrator; Bagisto administrator when Bagisto is the Source | Working account and permission summary | For a Bagisto Source, Products, attributes, Customers, Orders, channels, inventory, and CMS records can be inspected. Another Source provides access to its own selected records. | Actual Source access only. Intended Bagisto Target administration is confirmed in the separate Target prerequisites. |
| Confirm application and database access | Source technical owner and separate Target technical owner | Available actual Source application/data access; separately, intended Target hosting, Laravel, database, storage, queue, scheduler and deployment owners | Source evidence can be collected and destination implementation responsibilities are assigned. | Source infrastructure access is conditional on what the actual environment permits; another hosted Source need not expose Laravel, a database or a filesystem. Target implementation owners are assigned independently. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Available Source database/application backups or exports, media/download archive, coverage and recovery owner | Evidence is recoverable and any Store-restoration limits are explicit. | Actual Source recovery method, coverage and limits. Bagisto application/database backups and media/download files apply when available in that Source; an export does not prove full Store restoration. |
| Record versions and packages | Source development owner; Target build owner separately | Actual Source software and component inventory; for a Bagisto Source, Bagisto, Laravel/PHP, database, theme, package, module, and custom-code inventory | Version-dependent records and extensions are documented. | Native Bagisto versions apply only to a Bagisto Source. The intended Bagisto Target build and compatible packages are recorded independently. |
| Map external systems | Source and continuing integration owners | ERP/PIM/WMS/CRM/marketplace/search/payment/fulfillment endpoints and identifier maps | Continuing systems and synchronization authority are known. | Actual Source and continuing external systems. Future Target endpoints, keys and write responsibilities require a separate implementation decision. |
Use the actual Source recovery method to protect the evidence package. Record its date, included records and files, excluded areas, available recovery route and responsible owner. A hosted export may recover selected evidence without restoring the complete Store. When a required record or asset cannot be recovered, resolve the gap, agree an explicit exclusion or hold that scope before execution. Preserve native Bagisto application, database, media and download backups when the Source and available access support them.
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 where present in the actual Source. Native Bagisto identifiers apply when that Source uses Bagisto; proposed destination relationships are recorded separately.
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, Manage Stock setting, quantity where enabled and Order context | Stock ownership follows the actual setting without adding physical shipment behavior. |
| 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. |
Classify Source choices by their meaning before assigning a Bagisto Product type: an independent sellable child, descriptive attribute, bundle selection, booking choice or one-time buyer input. Quantity ownership follows the intended Product type and Manage Stock setting. Composites depend on their contained Products; a virtual Product may track stock when enabled without requiring a physical shipment.
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 | Select attribute enabled for configurable use, family membership, shared option values, parent/children and Order labels | Catalog owner | Eligible attributes identify the same sellable children across channel and locale contexts. |
| 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. |
A Product belongs to one attribute family, so prepare family membership and the required fields before assigning Products. Configurable variation attributes need the compatible Select type, configurable-use setting and inclusion in that family. Their option identity must remain consistent across channels and locales; translated labels do not create a new variant. Use the field ledger to distinguish sellable identity, description, filtering, administration, integration keys and package-owned state. Similar labels alone do not justify merging fields.
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. |
Confirm which inventory sources are active and assigned to each intended channel, together with Product channel assignment and the authoritative quantity owner. Inventory-source priority records a ranking; it does not automatically select the fulfillment warehouse. Where an ERP, WMS, marketplace or supplier feed controls routing or stock, prepare the actual rule, source identifiers, Product keys and responsible owner.
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. |
Select Customers from different groups, guest buyers, several addresses, inactive accounts and extension-defined profiles. Prepare group membership and rules separately from authentication. The exact Source-to-Target path and identity systems determine usable password-verification continuity or the required reset, activation or first-login handling; assign the decision and customer communication to an owner.
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 remain snapshots rather than being recalculated from current prices, tax Categories, Customer groups, shipping or payment configuration. Importing a transaction reference or subscription record does not authorize a new charge, refund, booking confirmation or fulfillment action. Prepare the ownership and isolation of live events separately from the historical record package.
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. |
For every continuing package, confirm compatibility with the intended build, registration/configuration and the code that consumes its records. Copying a table does not supply the package behavior. Keep inactive packages in the ledger when their records still explain Products, Customers, Orders, bookings, sellers or reports, and assign each dataset to a continuing implementation, archive or explicit exclusion.
Confirm Bagisto Target implementation prerequisites
The intended Bagisto application must be able to interpret the agreed records. A Source export can describe a configurable child, inventory location or package-owned booking without supplying the destination attribute family, channel assignment or consuming code. The Target technical, catalog and package owners should settle those dependencies before selecting execution-ready samples. Record the intended representation, not an assumption that the Source already has Bagisto structures.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended application and access | Target technical owner | Bagisto build, Laravel/application environment, administration, database, storage, deployment and recovery responsibilities | The intended environment and access owners are identified, and the required application dependencies are available. |
| Prepare the catalog and channel model | Target catalog and inventory owners | Chosen Product types, attributes/families, Categories, channels, locales, currencies, inventory sources and source-to-target relationship decisions | The agreed catalog, language and stock relationships have a usable Target representation. |
| Confirm packages and continuing consumers | Target development and package owners | Compatible registered packages or replacements, configuration, custom models/tables, core keys, APIs and headless consumers | Required package-owned data has consuming code and an owner; copied tables alone do not establish readiness. |
| Assign live operating responsibilities | Target operations and integration owners | Payment, shipping, tax, queues, scheduler, search, notifications, stock and fulfillment writers, with historical/test containment decisions | Future operations have named implementations and owners; historical/test records cannot be mistaken for instructions to charge, notify or fulfill. |
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 | Actual Source access, available recovery method, coverage, limits and recovery owner are confirmed; destination administration, Laravel, database, storage and deployment owners are assigned. Required Source evidence must be recoverable under the declared method. |
| 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. |
| Target prerequisites | The intended Bagisto application, catalog/channel model, compatible packages and consumers, access, and live-operation containment owners are confirmed for the agreed scope. |
The Bagisto scope is ready when each material record has a source owner, related entities, recoverable evidence and an intended destination or retained system, with the required destination attributes, channels and packages confirmed. Resolve a critical gap, explicitly exclude it or hold the affected work before execution. An assigned owner does not make an unsupported implementation ready.
Assess the Source evidence and intended Target implementation together. Recoverable data without a usable destination consumer remains a gap; a configured application without required Source relationships also remains a gap. Resolve the missing requirement, agree its explicit exclusion or hold the affected scope. The preparation package is ready only when both sides can support the agreed outcome.
Conclusion
Bagisto preparation connects actual Source evidence with destination Product types, attributes and families, Categories, channels, stock sources, Customers, Orders, CMS content, URLs and application packages. When the Source is Bagisto, its Laravel and database dependencies also form part of the recovery package. Make these relationships explicit before execution rather than treating the destination 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.
Carry the evidence package, intended Target decisions and any held scope into Bagisto Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first for a Bagisto migration?
Confirm access and recoverable evidence for the actual Source Store, then record the intended Bagisto build and application owners. If Bagisto is also the Source, include administration, Laravel, database, storage, media/downloads, queues, scheduler and package access, with available backups and version evidence. A different hosted Source needs its own access and recovery plan.
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 codes, types, labels, options, required/unique behavior, filter use, family and Product assignments, and the core or package owner. For configurable families, confirm Select attributes are enabled for configurable use and available in the Product’s family; maintain shared option identity across channels and locales.
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.
Does an inventory-source priority determine fulfillment automatically?
No. Prepare the ranking field alongside active source and channel assignments, quantity ownership and the actual fulfillment rule. Identify the application, integration or operating team that selects the warehouse. A priority value alone does not establish that routing behavior.
Is copying a package table enough to make its Bagisto feature ready?
No. The destination needs the compatible registered package or replacement implementation, its configuration and the consuming code, as well as the related data and keys. Assign those dependencies before execution. If the feature will be retired, document the archive or exclusion instead of leaving copied records without an owner.