Choose the Next-Cart migration approach for Bagisto from the result the intended target must use. A Product can exist in administration yet lack the right family fields or channel availability. A package can display a value without receiving the relationships its workflow requires. Record volume does not reveal those differences.
Make two decisions in order: establish whether the required data handling is supported, needs supported Add-ons or requires tailored scope; then assign execution. Standard Migration is customer-led. Managed Migration provides expert execution of agreed Migration Actions within supported capability. Custom Migration defines tailored handling and offers Self-Execute or Expert Handle for that agreed scope.
The merchant supplies business meaning and retains final verification in every model. The Bagisto migration page is a path-discovery entry. The service choice must still match the intended Bagisto build.
Separate Capability from Execution Responsibility
Product types, attributes and families, Categories, channel assignment, stock sources, Customer groups and history need usable target destinations. CMS content, URLs and marketing records need defined scope too. Their native existence in Bagisto does not establish coverage of a particular Source-to-Target path.
| Required result | Decision | Boundary |
|---|---|---|
| Records and relationships fit the active supported path | Use Standard Migration when the customer will execute it. | Confirm actual data types, fields and representation; catalog simplicity alone is insufficient. |
| Supported scope needs expert execution | Consider Managed Migration for agreed Migration Actions. | Expert execution does not expand capability or take over every target-build task. |
| Supported records need bounded selection or field handling | Review compatible Add-ons. | Identify conditions, expressions or mapping endpoints instead of assuming custom engineering. |
| Required extraction or representation exceeds supported handling | Scope Custom Migration or revise the requirement. | Separate tailored data work from target package, integration or frontend development. |
| An earlier paid run needs a further pass | Choose the appropriate Migration Action. | Configuration reuse, carried transfer state and target-data clearing are distinct decisions. |
A Bagisto channel's stock context illustrates the distinction. If the source quantity is correct but the wrong inventory source is assigned to the channel, target configuration needs attention. If an unsupported source relationship must be extracted and converted, that is a data-scope question. Buying more execution help does not erase either boundary.
When Standard Migration Fits Bagisto
Standard Migration fits when required records can use the active supported path and the customer can execute and verify the work. Several Product types or many attributes do not automatically make the migration custom; the issue is whether their required representation is supported.
Look for concrete scope evidence:
- Catalog: Product types, child relationships, attribute destinations, family maintenance and Category placement are understood.
- Store context: channel visibility, locale/currency assumptions and stock-source ownership have assigned target owners.
- Customers and history: group pricing/promotion needs and required Order relationships are defined without assuming historical records recreate live payment or fulfillment behavior.
- Content and discovery: CMS Pages, media, URLs, redirects and marketing data are included only where supported; theme, search and rule execution remain target responsibilities.
Cleanup, status mapping or an attribute-family decision may be necessary within an otherwise supported project. Escalate the specific unsupported requirement, rather than treating every custom field, external identifier or headless storefront as automatic evidence for Custom Migration. A headless site may consume ordinary supported records, while its implementation still needs separate ownership.
When Managed Migration Fits Bagisto
Managed Migration uses the same supported migration capability as Standard Migration, with experts executing the agreed Migration Actions. It is useful when the scope is supported but the merchant needs that execution responsibility assigned.
Bagisto projects may need coordination across several areas:
- Product types and attributes need agreed destinations before execution.
- Channels and inventory sources need target preparation and availability checks.
- Historical discounts, taxes, invoices, shipments and refunds need business interpretation.
- CMS content, URLs, search terms and landing pages need defined continuity checks where included.
- A merchant with limited migration resources still needs named requirement and acceptance owners.
Those needs can justify expert execution without making every record custom. The merchant retains manual access and final verification. Managed Migration does not automatically design attribute families, implement promotions, install packages, deploy headless APIs or own the complete launch.
If package or marketplace data exceeds supported capability, define Custom Migration and choose Self-Execute or Expert Handle within that tailored scope. The Migration Services comparison provides the broader service entry; the agreed capability and responsibilities control the actual engagement.
Use Add-ons for Supported, Bounded Data Requirements
Add-ons adjust supported migration behavior. The useful starting point is a precise data requirement, rather than the presence of a Bagisto customization.
| Requirement | Relevant Add-on | Qualification |
|---|---|---|
| Select Products or Customers by defined source-field conditions | Data Filter | Conditions apply separately to each supported data type. |
| Produce target-compatible values from source values | Data Transformation | Define the supported expression and expected output, such as an agreed label or status value. |
| Route a known source field to a compatible target field | Advanced Data Mapping | Both endpoints must be supported and compatible; mapping does not recreate the consumer. |
| Use eligible database-level fields or columns | Advanced Database Mapping | Both sides and the requested data type, table, field, column and Value Type must qualify. Package-table data needs this assessment rather than an automatic exclusion. |
Bagisto is listed as an eligible Target for Advanced Database Mapping. The selected Source setup must also support it, and the exposed schema and Value Type must fit the requirement. Bagisto eligibility alone does not make an arbitrary package table or relationship supported. Use the platform eligibility reference and schema checks for the actual direction.
Selected Standard Add-ons run in this order: Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Mapping routes the source value, or the value already produced by transformation; it does not transform that value during mapping. Combining supported Add-ons does not itself require Custom Migration.
Do not infer mapping eligibility from a label such as Tax. Check the actual field, data type and supported path. Retaining a historical tax amount and implementing live Bagisto tax calculation are different requirements.
A bespoke Product type's cart behavior or a headless frontend cannot be rebuilt by a mapping Add-on. Data storage and application implementation need separate scope. Add-ons and Customization are unavailable in Demo Migration, so their outputs need agreed paid-scope validation. The Add-ons reference owns the detailed capability boundaries.
Scope Custom Migration Around the Unsupported Requirement
Custom Migration is appropriate when required extraction, transformation or relationships exceed supported transfer and Add-on capability. A custom-field name, package label or API dependency alone does not establish that threshold.
Define the unresolved requirement through representative data and its consumer:
- Product behavior: a source custom type may need a native redesign or a separately implemented target behavior, with tailored data handling where required.
- Extension records: checkout, pricing, shipping or fulfillment data may need extraction beyond supported scope; historical evidence and future execution remain separate.
- Marketplace: seller, commission, payout and vendor-catalog relationships need a compatible selected solution and explicit data coverage.
- Company buying: company accounts, roles, quotes, credit and requisitions need the intended B2B representation and permissions.
- Headless delivery: Products, CMS content and search data must satisfy the frontend's actual API contract; ordinary records may remain supported.
- External systems: preserved identifiers need compatible destinations and a continuing synchronization contract, with tailored handling only where supported options fall short.
For a Custom Migration feasibility review, provide source examples, parent keys, expected target records, required relationships and usable acceptance cases. Decide which legacy behavior will be retained, replaced or retired before relying on it for launch.
Custom Migration does not automatically include Bagisto package development, marketplace implementation, frontend rebuilding, integration deployment or a complete store rebuild. Include such work expressly if it is part of the engagement; otherwise assign a target implementation owner.
Selecting CSV, XLS or XML as Source Platform requires Custom Migration. The included file workflow is Products only; Customers, Orders, sellers, commissions or other entities require explicit additional scope. Those Source identities are different from a supported platform's File Upload connection. A Product export cannot establish complete marketplace or headless coverage.
Use Entity Points for Capacity, Then Assess Complexity
Entity Points size eligible new Products, Customers, Orders and Blog Posts. They do not measure every relationship, implementation task or source of complexity.
| Counted record type | What needs a separate assessment |
|---|---|
| Products | Types, variants, bundles, attributes, stock relationships and custom buying behavior. |
| Customers | Group pricing, company roles, restricted access and other B2B relationships. |
| Orders | Payment and tax history, invoices, shipments, refunds, discounts and external references. |
| Blog Posts | Content layout, headless consumption, routes, redirects and theme behavior. |
An eligible record consumes Entity Points when successfully migrated for the first time. Within the same purchased migration and fixed actual Source/Target store path, an already counted record does not consume again merely because another Migration Action occurs. Mapping or validation alone does not create another counted record.
Capacity does not select the service, make unsupported data eligible or buy ownership of a Bagisto build. A modest record count can still need expert execution, an Add-on or tailored handling. Use the Entity Points reference for the counting rules, and confirm eligibility and purchase requirements before changing an actual store or platform.
Let Demo Evidence Refine the Decision
Demo Migration tests limited standard records available on the active path. It does not run Add-ons or Customization, and Reviews and Coupons are unavailable. Its evidence is useful within that boundary; it does not demonstrate an untested package, B2B workflow or headless journey.
Include available representative Product types, family fields, Category/channel context, source quantities, Customer groups, exceptional Orders, CMS Pages and URLs. Separate a migrated value from the target configuration or consumer that must use it.
Interpret findings according to their consequence:
- Supported examples work: retain the approach, while keeping untested requirements and target implementation checks open.
- A defined adjustment is needed: specify the supported condition, expression or mapping and its paid acceptance check. Choose expert execution separately if needed.
- Required meaning is lost or remains unproved: resolve the capability gap or target-build dependency before relying on the result. Review Custom Migration where the data handling is unsupported; revise or complete implementation where that is the cause.
An Add-on absent from Demo is an untested requirement, not a demonstrated defect. Equally, a missing critical relationship should not be treated as a minor watch item just because basic records passed.
Choose Migration Actions Separately from New-Data Scope
The three Migration Actions distinguish configuration reuse and a new run. They are not service upgrades or general synchronization modes.
| Migration Action | Use when | Bagisto example |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid. | The accepted type, attribute, channel and Customer-group decisions still apply. |
| Continue the Migration with a New Configuration | The next pass needs revised supported configuration. | Data selection, filtering or field mappings need adjustment after review. |
| Perform a New Migration | A fresh run is appropriate, whether or not a prior paid activity exists. | A substantially revised target plan needs a newly reviewed configuration instead of assumed reuse. |
The first paid activity and Demo cannot rely on a previous paid configuration. A new run also does not automatically clear target data; clearing and protected target data require their own review.
The Additional Option Continue the previous migration controls a different question. It carries the most recent migration state forward and processes Source records not represented as transferred in that state, with supported relationship context. It is not simply a filter for records created after a date, and it does not synchronize edits to previously transferred records.
The Migration Action determines whether saved configuration is reused or reopened; the Additional Option determines the carried state and new-data delta. It is unavailable in Demo and is distinct from Resume Migration after an interruption. Review Migration Actions and Additional Options before planning later passes, particularly where earlier records must remain related or target clearing is proposed.
Conclusion
Select the Bagisto approach by required representation first and execution responsibility second. Keep capacity, Demo evidence, target implementation and later-pass configuration as separate decisions.
Use supported migration and compatible Add-ons where they meet the requirement. Scope tailored handling where they do not, with an accountable owner for the Bagisto behavior that will consume the data. Final acceptance must establish the intended result rather than merely completed transfer.
Common Questions
When is Standard Migration enough for Bagisto?
When the active path supports the required data and relationships, and the customer can execute and verify the work. Known Product types, attribute destinations, store context and historical requirements support that choice. Custom fields, external identifiers or a headless site do not automatically make the data handling custom.
When should a Bagisto project use Managed Migration?
When supported scope needs expert execution of the agreed Migration Actions. The merchant still supplies requirements, retains manual access and verifies the final result. Target configuration, package development and complete launch ownership are included only where expressly agreed.
How should Add-ons be distinguished from Custom Migration?
Use Add-ons for supported conditions, value expressions and compatible field or database mappings. Review Custom Migration when required extraction or representation exceeds those capabilities. A custom table requires a real eligibility/schema assessment, not an automatic yes or no; target application behavior remains separate.
Can a successful Demo establish the complete approach?
It supports the tested standard examples only. Add-ons, Customization, Reviews and Coupons are unavailable in Demo, and package or frontend behavior needs its own evidence. Keep those requirements open until their paid-scope or target checks establish the intended result.
What evidence helps scope Custom Migration for Bagisto?
Provide representative source records, owned tables or interfaces, parent identifiers, the intended target package or native destination, and examples of a usable outcome. Explain unsupported relationships and whether behavior will be retained, replaced or retired. Separate data handling from development and deployment.
Does expert migration execution include installing Bagisto packages?
Package installation, development and compatibility work are included only if expressly part of the agreed responsibilities. Managed Migration expert execution does not itself expand supported capability. Tailored data handling uses the accepted Custom Migration scope and its selected execution mode.
Does matching stock quantity prove Bagisto is ready?
No. The stock-owning item, active sources assigned to the intended channel, ordered but unshipped quantities and any external stock authority also matter. Confirm source-level availability and continuing updates, rather than relying only on one Product total.