Bagisto Pre-Migration Preparation Checklist

A Bagisto migration is ready to execute when the team has recoverable evidence from the actual Source Store and a usable destination for the agreed records. A Product export does not supply an attribute family, a channel assignment or the package that will consume a custom relationship.

Use this checklist to connect each preparation task to an owner, evidence and a ready condition. Keep two sides visible: what the Source can provide, and what the intended Bagisto build must interpret. Native Bagisto features do not establish coverage of a particular migration path.

Record the selected build and the features actually used. Booking belongs to the documented native Product model; marketplace, B2B, subscription or other specialized requirements depend on their actual implementation. Include the compatible packages, APIs or headless consumers the project needs, rather than assuming every available capability will be enabled.

Confirm Source Access and Recoverable Evidence

The actual Source may be a hosted platform with no Laravel, database or filesystem access. Confirm its available access and recovery method first. Record Bagisto application dependencies as Source evidence only when Bagisto is also the Source; assign the intended Target's infrastructure owners separately.

Record who controls credentials and where they are maintained; keep secrets out of the preparation files. A hosted export may recover selected evidence without restoring the application. If a required asset or relationship is unrecoverable, resolve the gap, agree an explicit exclusion or hold the affected scope.

Retain internal and external identifiers wherever the Source uses them: Products and children, attributes and families, Categories, channels, stock locations, Customers, Orders, invoices, shipments, refunds, CMS records and package data. These are lineage evidence, not a requirement for another platform to use Bagisto's schema or identifiers.

Define Product Types and Sellable Relationships

Classify what is actually sold before choosing its Bagisto representation. A buyer choice may identify a child SKU, describe a Product, select bundle components, reserve time or collect a one-time input. Those meanings are not interchangeable.

The catalog owner should prepare the following cases with merchandising, stock and fulfillment owners:

Composites depend on their contained Products. Virtual Products can track stock without shipping, while booking uses its own capacity model. Document custom behavior separately when a native type does not express the required result. The inventory is a preparation requirement, not a promise that every type or field is included in the selected transfer.

Prepare Attributes, Families, Categories and Media

Bagisto's attribute family organizes the fields used for a Product. Each Product belongs to one family, so family assignments and required fields need a decision before loading the catalog. Renaming similarly labeled fields does not resolve different meanings, units or option identities.

The catalog owner should prepare a field register with these distinct entries:

• Attributes: stable code, input type, labels/options, required and unique settings, filtering/comparison use, and channel/locale value scope. Distinguish description, administration, discovery and integration keys.
• Families: code/name, grouped fields, Product assignments and package dependencies. Confirm that staff will receive the fields they need.
• Configurable attributes: compatible Select type, configurable-use setting, family membership, shared option identity, parent/children and Order labels. Translated option labels do not create a different variant.
• Categories: ID, hierarchy, Product assignments, intended visibility, localized content, media, metadata and URL key. Identify the owner of each public route.
• Media: owning Product/Category, primary/gallery role, file or remote source, ordering and alt context. Priority assets must be available and correctly linked.
• Package fields: schema, type, parent keys and consuming package, with a development owner. Keep these distinct from core attributes.

Input type matters: text, textarea, price, Boolean, Select, Multiselect and date/time fields are not interchangeable storage choices. Some definition choices, including code, type and locale/channel scope, are fixed after saving in the documented native model. Settle them before mapping values. A value that staff cannot maintain through the intended family is an unresolved requirement.

Map Channels, Languages, Currencies and Stock Sources

A Bagisto channel brings together a domain, root Category, languages, currencies, theme and inventory-source selection. Prepare that context with regional, catalog and inventory owners rather than treating it as a design setting to add later.

Channel availability depends on active assigned sources and ordered but unshipped quantities. Inventory-source priority does not automatically select a fulfillment warehouse. Where an ERP, WMS, supplier or marketplace feed controls stock or routing, retain its actual rules, Product/location keys and update owner.

Prepare Customer Identity, Groups and Account Access

Customer-data and Customer-service owners should prepare identity and address evidence separately from authentication:

• Accounts: IDs, email, name, status, group, consent, relevant locale/channel context and external CRM/ERP keys. Decide how duplicates and inactive accounts will be handled.
• Groups: code/ID, members, group prices, promotion eligibility and package dependencies. Assign access, tax and company authority to their actual implementations; the group label does not supply them.
• Addresses: Customer links, billing/shipping use, country/state references, company and tax fields where present. Saved addresses are distinct from Order-time snapshots.
• Guests: Order-level email, addresses and support context. Do not invent an account merely to preserve guest history.
• Extension profiles: user/core keys, package entity, role, status and related seller, company, quote, subscription or loyalty records where used. Name a package owner and destination or retained system.

The security owner should document the password scheme, social login or SSO, MFA, recovery route and communication responsibility. Usable password-verification continuity depends on the exact Source-to-Target path and identity systems. Other cases need reset, activation, invitation or first-login handling. A complete Customer profile alone does not establish login continuity.

Choose account samples across meaningful groups, guests, multiple addresses, inactive states and package-defined profiles. Keep price/access decisions and authentication decisions independently reviewable.

Preserve Historical Orders Without Replaying Operations

Prepare Orders as evidence of what happened at the time of purchase. The Order-data owner should capture headers, Customer or guest identity, addresses, Product/child snapshots, selected options, quantities, prices and status history.

Historical totals are snapshots, not instructions to recalculate old purchases using current prices, groups or tax rules. Importing a payment, refund, subscription or booking reference does not authorize a new charge, notification, confirmation or fulfillment action. Assign the isolation of test and historical events separately from their data preparation.

Prepare Content, Routes, Search and Promotions

Content and SEO owners should identify the record, audience and intended destination for each useful asset. Separate catalog/CMS content from theme presentation and separately implemented marketing behavior.

• CMS Pages: ID, title, URL key, channel/locale, status, content, metadata and menu placement.
• Product/Category content: owner ID, description, metadata, images, language/channel and priority route.
• Menus and theme blocks: hierarchy or placement, linked object, media and theme/package dependency, including banners and notification/email content where relevant.
• Priority URLs: source path, owning resource, audience, traffic/backlink value and intended keep, change, merge, retire or redirect outcome.
• Search and merchandising: terms, synonyms, filters, rules, Category placement, featured/new status and responsible system. Generated search data is separate from authoritative content.
• Reviews and preferences: Product/Customer links, review context, consent/newsletter state and the intended continuing consumer where included.
• Promotions: code/rule, dates, conditions, actions, affected Products/Customers and historical Order links. Retaining an old discount is distinct from implementing a future live rule.

Use analytics, search data, backlinks, campaigns, Customer communications and internal links alongside the sitemap to find important paths. Record expected destinations before execution so later route validation has something specific to prove.

Inventory Packages, APIs and Continuing Consumers

The development owner should record each package's name, version, provider, status, purpose, configuration owner, models/tables and affected records. Include inactive components when their data still explains an Order, booking, seller or report.

For each business-critical dependency, retain:

• Custom tables/models: schema, keys, core relationships and the code that interprets them.
• APIs or headless clients: selected compatible build/package, resources, identifiers, payload and route assumptions, authentication and deployment owners.
• Marketplace/B2B solutions: seller/company relationships, roles, catalogs, quotes, commissions, payouts or approvals actually used.
• Search services: authoritative inputs, indexed fields, external IDs, synonyms/rules and rebuild owner.
• Queues, events and scheduled work: triggers, payloads, destination, retry/error owner and affected records.
• Generated or abandoned data: cache, logs, sessions, queued work, indexes, temporary imports and old tables, classified by actual authority and retention need.

Do not copy generated artifacts as though they were authoritative commerce records. Equally, do not discard a business record solely because its package is inactive. Assign each dataset to a continuing implementation, an archive or an explicit exclusion.

Table presence does not install a feature. Required packages or replacements need compatibility, registration/configuration and consuming code. Current and older Bagisto API builds use different package/interface arrangements; qualify the intended consumer rather than relying on a generic API label.

Confirm the Intended Bagisto Implementation

The Target technical, catalog, inventory, package and operations owners should confirm four dependencies before execution-ready samples are approved:

1. Application and access: intended Bagisto build, Laravel/application environment, administration, database, storage, deployment and recovery responsibilities, with required dependencies available.
2. Catalog and channel representation: chosen types, attributes/families, Categories, languages, currencies, stock sources and source-to-target relationship decisions.
3. Continuing consumers: compatible registered packages or replacements, custom schemas/core keys, APIs and any headless frontend that will use the records.
4. Live operations: payment, shipping, tax, search, notifications, queues/scheduler, stock and fulfillment writers, with test/historical-event containment assigned.

An assigned owner is necessary but does not make an unavailable implementation ready. Recoverable data without a usable destination consumer remains a gap, just as a configured application without required Source relationships does.

Assemble Representative Samples and Expectations

Select easy and difficult examples of the actual scope. Each sample needs Source IDs/SKUs, URL keys, related records/files, channel/locale, stock-source context, external keys, an expected result, a reason for selection and a named reviewer.

Cover the distinct cases that matter:

• a simple Product baseline with price, tax, stock, content and an Order;
• a configurable family with children, choices, images, source quantities and purchases;
• grouped/bundle components or booking slots/capacity where used;
• a multi-channel case with language, currency and warehouse context;
• a Customer group or package account with addresses and required commercial treatment;
• an exceptional Order with discounts, taxes, invoices, shipments, refunds and external references;
• a CMS/catalog URL with metadata, links and destination intent;
• a package-owned record with core parent, schema, events/jobs and integration key.

Include digital/virtual and custom cases where material; do not let the examples above become a fixed sample quota. The expectation sheet should explain what would count as correct, not merely list available records.

Complete the Readiness Decision

Resolve a critical gap, explicitly exclude its scope or hold that work before execution. Readiness requires evidence and a usable destination on both sides of the decision; it cannot be inferred from a complete export or a list of responsible people.

Conclusion

Bagisto preparation connects actual Source evidence to the types, family fields, channels, stock sources and consumers that will use it. Keep historical commerce separate from live configuration, and identify package/API dependencies before they become execution surprises.

Carry the evidence, intended representation, samples and held scope into Bagisto Validation Priorities. Preparation defines the expected result; validation determines whether the migrated outcome meets it.

Common Questions