For a move into Gambio, first determine whether a purchase choice is an additional option or a variant combination with its own stock and identifier. Then confirm which stock policy controls availability. These distinctions determine the required Next-Cart scope; hosting and technical ownership affect execution without creating separate platform identities.
Selecting the right migration approach for Gambio begins with the actual catalog, technical dependencies, and ownership model of the target Store. Gambio is one platform identity; hosting, maintenance, modules, custom code, and integration responsibility affect the evidence and validation burden without creating separate platform variants. For the supported Next-Cart Gambio path, the connection method is KitConnect, while service selection still depends on scope and execution responsibility rather than the connection method alone.
Gambio’s installed version may use current options and variants or older attribute and property structures. Additional options and variant combinations have different selling roles. A stored quantity also needs its stock-check policy: an older combination model can check main Product stock, combination stock, global settings or no stock. Review the actual representation and availability rule before accepting a mapping or escalating to Custom Migration.
A Gambio migration should not be scoped only by counting products, customers, and orders. The more important question is whether the source store's catalog, options, stock behavior, content pages, historical orders, legal/trust content, integrations, and custom logic fit the planned target environment. Standard Migration may be sufficient for a clean store with ordinary supported records. Managed Migration, Add-ons, or Custom Migration become more relevant when the project needs operational judgment, bounded transformation, or unsupported custom handling.
The best service path is the one that keeps four boundaries visible: what can move as supported data, what must be configured in Gambio, what must be validated after Demo Migration, and what requires custom handling outside ordinary migration behavior.
For Gambio, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
How Gambio Service Selection Should Be Read
Gambio service selection should be read as a scope decision, not as a preference for more or less assistance. The right path depends on the store's data structure, operating responsibility, customization depth, and validation capacity.
A simple store can often proceed with a lighter migration path because the data meaning is visible. A store with many product options, downloads, custom fields, marketplace records, legal/content dependencies, or external identifiers may need a more controlled approach even if the record count is not large. Complexity is not always volume. Sometimes a small catalog with custom product logic is harder to migrate than a larger catalog with consistent records.
| Decision factor | Lower-scope signal | Higher-scope signal |
|---|---|---|
| Technical ownership | Hosting, maintenance, modules, custom code, and integration responsibility are already clear. | Critical technical dependencies have no post-launch owner. |
| Catalog structure | Products, categories, images, and stock behavior are standard and consistent. | Options, downloads, stock rules, custom fields, or external inventory references are important. |
| Content structure | CMS Pages are limited and easy to place. | Legal, trust, SEO, or campaign pages require classification and placement decisions. |
| Historical orders | Orders use common statuses, payment labels, shipping methods, and product lines. | Orders include custom statuses, marketplace data, downloads, refunds, tax variation, or external references. |
| Integrations | Payment, shipping, and marketplace setup can be recreated separately. | External systems own business meaning that must remain connected to migrated records. |
This table should guide service selection before Demo Migration. Demo Migration then tests whether the selected path is realistic.
When Standard Migration Is a Good Fit
Standard Migration is most suitable when the Gambio migration involves supported records with predictable structure. The store should have clean products, categories, customers, orders, images, and related data that can be moved without extensive interpretation or custom transformation.
For Gambio, Standard Migration is a stronger fit when the catalog uses ordinary Products and Categories, Product options are simple, stock behavior is not highly customized, content pages are limited or well organized, historical Orders do not depend on unusual status or external-system logic, and the technical environment has clear owners.
Standard Migration can be appropriate when the merchant can review Demo Migration results internally. The merchant should be able to check product completeness, category placement, customer identity, order readability, CMS Pages, and basic storefront behavior without needing the migration team to interpret every decision.
Standard Migration is weaker when the source store's meaning is hidden in modules, custom tables, external integrations, theme logic, marketplace connectors, or special product rules. In those cases, the issue is not whether the store can be exported. The issue is whether the exported records explain enough to create a reliable Gambio target.
When Managed Migration Adds Value
Managed Migration is appropriate when Gambio scope fits supported capability but the merchant needs experts to perform the agreed Migration Actions. It reduces execution workload without expanding record support. The customer still defines variant, content and Order expectations, coordinates separate technical owners and verifies the final result.
For Gambio, many catalog combinations, content owners or Order-history reviewers can increase the execution burden. Name the customer’s approval owners and agree the Migration Actions experts will perform. Wider project coordination, legal/content approval and launch management require explicit agreement rather than being included by the service name.
Managed Migration uses the same supported capability as Standard Migration. Unsupported records, bespoke option or stock interpretation and external-system data still require Custom Migration review. Custom Migration can then use Self-Execute or Expert Handle, with the customer retaining manual access and final verification.
| Managed Migration is useful when... | It should not be used to assume... |
|---|---|
| The merchant needs experts to perform agreed actions with explicit customer acceptance checkpoints. | Unsupported custom data will automatically become standard scope. |
| Demo Migration requires structured feedback across product, order, and content samples. | Target design, legal review, or integration rebuilds are included by default. |
| Several customer owners agree requirements and need expert execution before Full Migration. | All external-system behavior is recreated through data migration. |
| The project needs less merchant-side operational burden. | Custom source logic can be ignored. |
Choose Managed Migration for expert execution of the agreed supported migration. Keep legal/content decisions, target setup, integration deployment and launch approval separately owned; use Custom Migration for tailored data requirements.
When Add-ons Are Needed
Add-ons are appropriate when the required change is bounded and fits supported migration behavior. In Gambio projects, they may be relevant for filtering records through field-based conditions for each data type, transforming field values through expressions, or remapping source fields to compatible target fields.
Data Filter may be useful when the merchant does not want all eligible records moved. For example, Product, Customer, Order, or content field conditions may exclude obsolete, inactive, test, or out-of-range records. Filtering is a scope-control decision; it should not be used to hide uncertainty about which records matter.
Advanced Data Mapping can route eligible supported source fields to compatible Gambio target fields. It keeps the source value, or a value already transformed by Data Transformation, unchanged during mapping. The source meaning, destination meaning and downstream use must remain clear.
Data Transformation can help when supported field values need controlled change during migration. The merchant should define the expression, input values, expected results, and exceptional cases before selecting it.
Gambio supports Advanced Database Mapping as a Target. Database-level routing can therefore be considered when the selected Source setup also supports Advanced Database Mapping and the requested Gambio data type, table, field, column, and Value Type are supported and compatible. This does not recreate module logic or other target-side behavior merely because a value can be stored.
If a required Add-on function needs project-specific modification, or bespoke Add-on functionality is needed, the requirement moves beyond Standard Add-on scope. Tailored and Custom Add-ons are reviewed and quoted through Custom Migration.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
When Custom Migration Is Required
Custom Migration is required when the migration needs unsupported custom handling. For Gambio, this is most likely when the source store stores business meaning in custom fields whose required handling exceeds supported mapping scope, custom product structures, module-owned data, modified database tables, external-system identifiers, custom checkout rules, marketplace connector data, ERP links, or bespoke transformation rules.
Gambio stores with substantial custom server-side dependencies can increase Custom Migration discussion because merchants may expect deep continuity from a heavily customized source store. Technical flexibility in the target implementation does not mean custom source behavior migrates automatically. The project still needs to identify what is native data, what is configuration, what is extension-owned, what is external-system-owned, and what is custom logic.
Custom Migration may be needed when:
- product logic depends on custom fields or modified source database structures;
- option or stock behavior does not fit supported product handling;
- downloadable products depend on custom access rules;
- marketplace or ERP identifiers must be preserved in a specific way;
- customer groups, tax behavior, or order status logic need bespoke interpretation;
- CMS Pages include generated or theme-embedded content requiring special extraction;
- the Source Platform or Target Platform requires custom migration logic adjustment.
Custom Migration should be scoped explicitly. It should not be buried inside a general migration promise. Clear separation protects the merchant from discovering after Full Migration that critical business meaning was never part of ordinary data movement.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Gambio scope.
Entity Points and Gambio Scope Control
Entity Points help control scope when eligible new Products, Customers, Orders, and Blog Posts are migrated. The key rule is that eligible new records consume Entity Points after their first successful migration. For later Gambio activity, previously counted eligible records remain counted once within the same purchased migration and fixed Source-to-Target path; option, stock, download, and Customer-group complexity is assessed separately.
In Gambio projects, Entity Points matter most when the merchant wants to add new records, expand scope, or handle follow-up migration after the initial path has been defined. They should not be used as a substitute for structural review. A store with fewer Products can still be complex if those Products depend on options, stock rules, downloads, custom fields, or external identifiers.
| Scope situation | Entity Points relevance | Separate planning question |
|---|---|---|
| New Products are added after initial scope | Eligible new Products may consume Entity Points after their first successful migration. | Do those Products follow the same Gambio structure already validated? |
| New Customers or Orders appear before launch | Eligible new Customers or Orders may consume Entity Points after their first successful migration. | Are statuses, addresses, payments, shipping, and product lines still readable? |
| Blog Posts are added where applicable | Eligible new Blog Posts may consume Entity Points after their first successful migration. | Should content be migrated, recreated, redirected, or retired? |
| Existing counted records are reprocessed on the same path | They do not consume again merely because another action occurs. | Does supported configuration need adjustment on the fixed purchased path, or has the actual platform path changed? |
Entity Points answer a consumption question. They do not answer whether the target data is structurally ready for launch.
Demo Migration as the Service-Path Test
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Gambio approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
Use these Gambio contexts to define evidence needs. Include only supported records available in Demo; assign unsupported data and target behavior to separate agreed proof:
- products with options;
- products with stock behavior;
- downloadable products;
- products with multiple images;
- products in important categories;
- customers with addresses;
- orders with discounts, tax, shipping, payment, and status variation;
- CMS Pages with legal, trust, service, or SEO value;
- records touched by integrations or custom fields where relevant.
Classify findings as accepted standard sample behavior, a configuration task, an eligible Add-on need or tailored scope. Add-ons and Customization cannot be run in Demo, so these classifications identify future work rather than certify its output. Keep legal-content approval and live integrations with their responsible owners.
| Demo finding | Likely response |
|---|---|
| Supported data appears correct and readable. | Retain the supported approach and document untested requirements before Full Migration. |
| Supported data needs a bounded data type condition, value expression, or field destination. | Review Data Filter, Data Transformation, or Advanced Data Mapping. |
| Business meaning depends on unsupported custom records or logic. | Scope Custom Migration. |
| Target-side setup is missing. | Assign configuration, design, legal/content, or integration tasks outside ordinary migration. |
Demo should inform a service decision and record what remains untested. Before Full Migration, accept the needed Add-on or Custom Migration scope and the separate target responsibilities. Use agreed paid-result evidence for variant rules or custom references that Demo could not test.
Full Migration and Follow-Up Options
Full Migration should proceed when the service path, scope, and validation responsibilities are clear. For Gambio, that means the target environment is confirmed, catalog samples passed, content pages are classified, order readability is acceptable, Add-ons are selected where needed, and Custom Migration items are either scoped or separated from the launch plan.
Continuation actions become available after an earlier paid migration. Demo findings should inform the first paid configuration rather than trigger a continuation action. For later paid activity, the correct option depends on what changed:
| Follow-up need | Better option | Reason |
|---|---|---|
| An earlier paid setup remains valid; choose the source-data window independently | Continue the Migration with Last Saved Configuration | The target handling rules are already validated. |
| Mapping, filtering, or configuration has changed | Continue the Migration with a New Configuration | Supported filtering, mapping, or configuration has changed while the purchased migration path remains fixed. |
| The project needs a distinct migrated result while the purchased Source Platform-to-Target Platform path remains unchanged | Perform a New Migration | Agree the intended effect and check the combined result; protected target data is not automatically erased. A different platform path requires a separate purchase. |
These options are especially useful when a merchant continues selling while launch preparation continues. They should be planned with validation in mind, not treated as administrative buttons.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Choosing the Right Gambio Path
The right Gambio path is selected by combining record scope with operating-model complexity. A merchant with a clean catalog, ordinary Customer records, readable Order history, stable Categories, and limited external dependencies may fit a simpler path. A merchant with option-heavy Products, downloadable items, legal or trust content, marketplace assumptions, custom fields, custom templates, or integration dependencies usually requires more guided review.
Record count does not determine scope. A small catalog can require tailored handling for unsupported option or stock logic; a large consistent catalog can remain supported. Choose Managed Migration separately when experts should perform the agreed actions.
Identify escalation triggers before Demo: option meaning, the active stock policy, historical Order context, content ownership and custom integration references. Demo can reveal a gap in available standard records; enhanced or custom output needs paid proof. Decide whether the gap calls for an eligible Add-on, tailored scope or separate Gambio implementation. Consider continuation only after an earlier paid result, with source-data options selected independently.
The practical choice is usually clear when the merchant separates record movement from operating behavior. Standard Migration fits clean supported data. Managed Migration fits merchants who need more execution support. Add-ons fit bounded record filtering, field-value transformation, and field remapping needs. Custom Migration fits unsupported, custom, external, or bespoke migration requirements.
| Migration path | Best fit | Watch condition |
|---|---|---|
| Standard Migration | Clean supported records with manageable internal review. | Hidden custom logic or integration-owned meaning. |
| Managed Migration | Merchant needs expert execution of agreed supported Migration Actions. | Assuming guidance replaces custom migration work. |
| Add-ons | Bounded record filtering, field-value transformation, or field remapping needs. | Using Add-ons to avoid Custom Migration when unsupported data is involved. |
| Custom Migration | Unsupported records, custom fields whose required handling exceeds supported mapping scope, external identifiers, or bespoke logic. | Scope must be explicit before Full Migration. |
| Migration Actions | Follow-up records or changed configuration after an earlier paid migration result. | Must match whether the configuration is unchanged, revised, or substantially different. |
The right path should make the migration easier to validate. If the selected path does not clarify what will be moved, configured, customized, or validated, the path is not ready.
Conclusion
Gambio service choice should preserve the meaning of additional options, variant combinations and the stock policy that makes them available. Standard Migration fits supported customer-led execution. Managed Migration supplies expert execution of agreed actions within that capability. Supported Add-ons provide bounded data controls; Custom Migration handles tailored requirements with Self-Execute or Expert Handle.
Keep target configuration, legal/content approval, technical maintenance and integrations explicitly owned. Use Demo for its limited standard sample, agreed paid proof for enhancements or customization, and separate action and source-window decisions for later runs.
Common Questions
When is Standard Migration enough for a Gambio migration?
Standard Migration is usually enough when the store has clean supported records, simple products and categories, readable customers and orders, limited content complexity, and no unsupported custom logic.
When should Managed Migration be selected for a Gambio migration?
Select Managed Migration when Gambio scope is supported and experts should perform the agreed Migration Actions. The customer supplies option, stock and content expectations, coordinates business approvals and verifies the result. Wider launch coordination and target implementation must be expressly included if required.
Can Add-ons handle custom Gambio migration needs?
Add-ons can handle bounded record filtering, field-value transformation, and field remapping needs. Unsupported records, custom fields whose required handling exceeds supported mapping scope, external identifiers, bespoke transformation, or custom migration logic adjustment require Custom Migration review.
When should Migration Actions be considered for Gambio?
They are relevant after a paid migration has produced an earlier result, when new records need to be added, supported configuration must change, or the project needs a fresh result on the same purchased path. A Demo result alone does not create a paid configuration to reuse.
What evidence should be prepared for Custom Migration review in a Gambio migration?
Prepare Gambio examples that expose option and stock rules, downloadable Product behavior, Customer-group meaning, and any custom or external identifier that ordinary records do not explain. Define the intended target representation and a business-level pass condition for every Custom Migration requirement.
Does matching Gambio stock prove the right variant is available?
No. First identify the additional option or variant combination, its identifier and the stock-check policy in the installed version. A matching main Product quantity can coexist with a different combination-level availability result. Classify the required data and target policy separately before selecting mapping or tailored handling.
Does Managed Migration include approving Gambio legal pages and rebuilding integrations?
Managed Migration covers expert execution of agreed supported Migration Actions. Legal-content approval, hosting, modules and integration deployment have their own owners unless expressly included. Required external identifiers may need supported mapping or Custom Migration, but moving them does not redeploy the live integration.