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.
Confirm the intended hosting arrangement and the owners of maintenance, modules, custom code and integrations. The supported Gambio setup uses KitConnect; the actual Store must permit that connection, including any required file access. Check Cloud restrictions for that Store before relying on the setup. The connection method does not choose the service.
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.
Keep supported record transfer, Gambio configuration, representative test evidence and tailored requirements distinct. Demo is optional and tests only its available standard sample; enhanced or custom output needs the agreed paid-result proof.
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
Assess the required data handling and execution responsibility as separate decisions. The Store's data structure, operating responsibility, customization depth and validation capacity determine what must be agreed; supported scope can use either customer-led Standard Migration or expert-led Managed Migration.
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. |
Use these signals to define the required scope and owners before execution. An optional Demo can then test its available standard sample; it cannot establish support for untested enhancements or custom handling.
Choose Execution Responsibility Within the Agreed Scope
When Standard Migration fits
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.
Within the selected supported path, 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.
- 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.
Decide Whether the Data Needs Adjustment
When supported Add-ons help
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 intended value change, input values, expected results and exceptional cases. Only Data Filter provides direct Expression editing; other Add-ons use their supported structured controls.
Gambio is listed as an eligible Target for Advanced Database Mapping in the directional eligibility reference. 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. Use the Add-on reference for current capability and configuration boundaries.
Confirm support for the required tax-related record, field and destination in the actual Source-to-Gambio path. Neither a blanket Tax exclusion nor universal tax-field support establishes that scope.
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 or custom-template 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 when new records enter the agreed scope or later migration activity. Review their capacity separately from option, stock, download, custom-field and external-identifier handling; those structural requirements still need an accepted treatment.
| 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. A Product includes its variations for counting purposes; capacity does not select which records move. The Entity Points reference explains the current counting rules.
Establish Evidence Before the Full Result
What an optional Demo can prove
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 later actions
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 one-way Source Platform-to-Target Platform path fixed. A different Source Platform, Target Platform or reverse direction requires a separate purchased Migration. See the Migration Actions reference for the action and source-data boundaries.
Choose the source-data window separately from the action. Continue the previous migration carries the most recent migration state into a later pass, so selected supported records not transferred in that previous state form the delta and supported relationships can use the carried context. New Source records are a common reason for that pass; this is not a general synchronization mechanism for edits to previously transferred records. The carried-state option is not 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.
Choose the Gambio Approach From the Evidence
Before execution, identify escalation triggers: 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.
| 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. |
Use the Gambio migration page to check the actual direction and available data scope, and the preparation checklist to assemble representative evidence. The validation priorities define the result reviewers must accept. If data scope, target configuration, tailored work or proof remains undefined, settle that boundary before execution.
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.