Two source choices can look identical in a storefront while representing different stock and pricing relationships. Gambio adds another translation layer because long-running Stores can use older attribute/property structures alongside newer option and variant models. The destination must retain the behavior and lineage of the choice, rather than assign every similar label to one field.
Gambio combines a broad commerce catalog with Customer-group pricing, content management, multilingual fields, modules, and extensible store data. The visible records may look familiar, but their relationships are platform-specific. An article can be linked to several Categories, use one of several Product types, carry additional fields and tabs, restrict visibility by customer group, and receive customer-group or quantity pricing. Buyer choices can also originate from different generations of Gambio catalog logic, including article attributes, article properties, current options, Product Options, and Product Variants.
These distinctions make a field-by-field transfer unreliable. A source color value might be descriptive information, a legacy attribute, an option value, or part of a separately identifiable variant. A source Customer tier might control visibility, price, tax treatment, minimum quantity, or several of those relationships. A content record might belong to the Content Manager, an article tab, a Category, a theme block, or a module. The migration model must therefore identify the Gambio owner of each value and preserve the related records that give it commercial meaning.
Gambio Record Meaning Depends on Catalog Generation and Environment
A Gambio record must be interpreted through the selected software generation and installed components. Long-running Stores can contain earlier attribute or property structures, newer option and variant records, module-owned data and custom changes. A documented model does not prove that every installation uses the same relationships or that a particular migration path exposes them.
Technical ownership around a Gambio Store can vary substantially. Some Stores rely mostly on native structures, while others contain local files, GXModules, themes, database additions, or direct modifications that have no equivalent in a clean target installation. This does not change the meaning of native Products, Customers, or Orders, but it changes how confidently extension-owned fields can be classified as portable Gambio data.
| Source evidence | Gambio interpretation | Relationship consequence |
|---|---|---|
| Current Product Option and Product Variant records | Current buyer-choice and sellable-combination model | Preserve option definitions, selected values, variant identity, and commercial values together. |
| Legacy article attributes or properties | Earlier catalog-generation structure | Interpret according to the source version instead of forcing it into current terminology. |
| GXModule or third-party table | Module-owned entity or extension to a core record | Identify the module and the Product, Customer, Order, or content record it extends. |
| Native Gambio record | Core commerce data owned by the platform | Keep commerce data separate from hosting, theme, module, and infrastructure configuration. |
| Custom field or table | Local extension, modified schema, or integration record | Assign a destination only after its owner and consuming workflow are known. |
| External identifier | ERP, PIM, WMS, marketplace, accounting, or fulfillment key | Preserve the stable key needed to reconnect the Target Store. |
Version and environment are therefore data-lineage facts. They explain why two Gambio Stores can display the same label while storing or using the value differently.
Products, Article Types, Categories, and Catalog Fields Are Distinct
Gambio commonly uses the term article for a sellable Product. A Product can carry an article number, stock quantity, weight, manufacturer, tax class, delivery status, barcode or EAN, packaging unit, quantity unit, minimum order quantity, quantity increments, images, multilingual descriptions, metadata, and Category links. The Product type can also distinguish a standard article, downloadable article, or service.
Categories are separate records, and one Product can be linked to more than one Category. That relationship matters when a source Store uses duplicate Product records to achieve multiple placement, or when Categories also act as merchandising, SEO, or navigation structures. The correct target interpretation may be one Product with several Category assignments rather than several Products that happen to share content.
Gambio also supports additional Product fields, Product tabs, filters, Google taxonomy assignments, manufacturers, related content, and merchandising flags. These values should not be compressed into the description merely because they are visible on the Product page.
| Source pattern | Gambio owner to consider | Meaning to preserve |
|---|---|---|
| Physical sellable item | Standard Product record | Identity, price, tax, stock, weight, images, and Category assignments. |
| Digital file | Downloadable Product and Order-access relationship | File identity, access conditions, and historical purchase context. |
| Service or non-shipped item | Service Product type | Sellable identity without inventing physical fulfillment data. |
| Product in several browsing branches | One Product linked to several Categories | Shared identity with multiple discovery paths. |
| Technical specification | Additional field, filter value, or structured content | Descriptive meaning remains separate from a buyer choice. |
| Extended Product explanation | Product tab or content relationship | Content remains attached to the correct Product and language. |
| Supplier or brand identity | Manufacturer or external master-data relationship | Brand meaning and external key remain consistent. |
The main translation rule is to preserve Product identity once and then rebuild its relationships. Duplicating a Product to reproduce each source navigation path creates stock, SEO, and Order-history inconsistencies.
Options, Product Options, Variants, Attributes, and Properties Must Not Be Collapsed
Gambio's buyer-choice model has evolved. Current developer resources distinguish options, Product Options, and Product Variants, while older Stores may still use article attributes or article properties. These structures can overlap in how they appear to shoppers, but they are not interchangeable at data level.
An option defines a choice domain such as size or color. A Product Option connects an option to a Product. A Product Variant represents a concrete combination derived from Product Options and can carry combination-specific commercial data. Older attributes or properties may store similar values through different tables and rules. Source data must therefore be classified by behavior and lineage rather than by label.
| Source behavior | Gambio interpretation question | Relationship that must survive |
|---|---|---|
| Choice changes only the displayed selection | Option or Product Option without independent commercial identity | Product-to-option link and selected value. |
| Dependent combination represents a distinct sellable result with its own commercial values | Product Variant where supported by the selected model | Parent Product, selected option values, variant identity, and commercial values. |
| Buyer enters text or personalization | GX-Customizer or module-owned input | Entered value remains connected to the Order line. |
| Value describes the Product | Additional field, filter, or structured content | Descriptive value remains distinct from the purchased combination; an older property may instead define a selectable combination. |
| Legacy Store uses article attributes | Legacy attribute structure | Attribute name, value, price effect, stock behavior, and source lineage. |
| Legacy Store uses article properties | Legacy property or combination structure | Property groups, values, combinations, and Product relationships. |
Independent Gambio options and dependent sellable combinations are different relationships. An optional component can adjust price or weight while remaining an independent selection; that adjustment alone does not make it a separately stocked variant. A size-and-color combination that identifies one physical item needs the combination, stock and parent relationship together. Personalization belongs to the purchased line, while descriptive facts belong to additional fields, filters or content. These distinctions must follow the actual catalog generation.
A Product or variant model number and barcode identify merchandise for business use, while native record keys connect Gambio objects. If a source parent and child Products are consolidated into one Product with variants, preserving the printed codes does not by itself rebuild Order references or external-system links. Retain the relationship between each source sellable item, its destination record and the system that consumes its business key.
Stock, Pricing, Customer Groups, and Quantity Rules Form a Commercial Layer
Gambio Product data can be connected to stock control, minimum order quantities, quantity increments, customer-group visibility, group-specific prices, graduated prices, discounts, tax classes, special offers, and other commercial rules. These relationships determine who can see an article, what price they receive, and how much they can purchase.
A Customer group is not merely a segment label. In the documented Gambio model, a Customer belongs to one commercial group; that group can govern prices and other buying rules, while Product visibility depends on the relevant settings. Several source memberships, such as wholesale, newsletter and loyalty cohorts, therefore cannot all be treated as equivalent commercial group assignments. Preserve the active pricing/access meaning and give other cohorts a separate owner. Historical Orders retain the actual price and tax evidence regardless of later group changes.
| Source meaning | Gambio relationship | Translation boundary |
|---|---|---|
| Product available only to approved buyers | Product-to-customer-group visibility | Preserve the access relationship, not only the group name. |
| Wholesale or dealer price | Customer-group Product price | Keep Product, group, currency, and price connected. |
| Quantity break | Graduated price or quantity-dependent rule | Preserve thresholds and the customer scope that receives them. |
| Minimum purchase quantity | Product minimum-order quantity | Keep the required purchase quantity separate from inventory quantity. |
| Stock by sellable combination | Variant-level stock where represented | Do not attach all quantity to the parent Product. |
| Current promotional price | Active pricing relationship | Keep separate from the historical price stored on old Orders. |
This layer is where apparently small fields become operationally significant. A copied price without its group relationship is not the same price. A copied stock value without its variant identity is not the same inventory record.
Customers, Addresses, Groups, and Orders Carry Different Kinds of Evidence
Gambio Customer data can include account identity, addresses, customer-group membership, merchant or dealer context, memos, communication preferences, reviews, and administrative relationships. These records should be separated by purpose. An address-book entry is not the same as an Order-time address snapshot. A group assignment is not the same as a historical discount. An administrator account is not a Customer account.
Orders contain historical commercial evidence: Customer or guest identity, billing and shipping addresses, Product and variant references, selected choices, quantities, prices, discounts, taxes, shipping, payment labels, Order statuses, comments, invoices, delivery documents, withdrawals, and other related records. A migrated Order should remain understandable even if the Target Store uses different live payment, shipping, tax, or status configuration.
| Historical element | Gambio owner | Meaning to retain |
|---|---|---|
| Registered buyer | Customer account | Identity and relationship to Orders and addresses. |
| Guest checkout buyer | Order-level identity snapshot | Historical buyer context without inventing an account. |
| Saved address | Customer address book | Reusable Customer address relationship. |
| Billing or shipping address on an Order | Order-time snapshot | Evidence of the transaction as placed. |
| Product choice on an Order line | Product/variant label and selected values | Exact item purchased, even if the catalog later changes. |
| Payment and shipping labels | Order history | Historical method evidence, not current method configuration. |
| Refund, withdrawal, or status history | Related Order records | After-sale context remains traceable. |
The strongest model keeps Customer master data and Order snapshots distinct. Updating a Customer address must not rewrite the address recorded on an older Order. A retained refund, withdrawal, payment or fulfillment reference explains historical activity; it does not recreate a provider’s authority to perform a new action. Current account, gateway, carrier and module relationships remain separate from historical labels and states.
Content Manager, Product Content, URLs, and Themes Have Separate Owners
Gambio content can live in the Content Manager, Product descriptions, Product tabs, Category descriptions, banners, teaser sliders, menus, legal pages, error pages, theme blocks, language files, or modules. Each structure has a different owner and route relationship.
CMS Pages should retain their own identity, language, content, visibility, menu placement, and URL relationship. Product tabs remain connected to Products. Category descriptions remain connected to Categories. A theme block or StyleEdit configuration controls presentation and should not be mistaken for a portable CMS Page. Legal and policy content may require current business review, but its record identity and placement can still be preserved as content data.
Gambio Product and Category records can also carry URL keywords, URL rewrites, metadata, search terms, and multilingual values. These relationships influence discoverability, but they do not make navigation, content, and SEO the same object.
| Visible storefront element | Likely Gambio owner | Data-model implication |
|---|---|---|
| Information or policy page | Standalone Content Manager Page | Preserve content, language, route, and placement. |
| Additional Product explanation | Product tab or Product content | Keep attached to the Product rather than creating a generic Page. |
| Category landing text | Category record | Keep with Category identity and route. |
| Homepage banner or teaser | Banner/teaser configuration | Content asset and placement are separate. |
| Menu item | Navigation configuration | A migrated Page or Category does not automatically recreate its menu placement. |
| Theme block or template override | Theme or module presentation | Rebuild presentation without misclassifying code as content. |
| Old Product or Category URL | Entity URL and redirect relationship | Preserve the source-to-target path relationship. |
A clean migration can preserve content while still changing presentation. The critical requirement is that each record reaches the correct Gambio owner and remains connected to its route and language.
Modules, GXModules, APIs, and External Systems Extend the Native Model
Gambio can use modules, GXModules, themes, APIs, imports, exports and external integrations, depending on the installed environment. They can create fields, tables, statuses, identifiers and workflow records beyond the native commerce model. Availability of an API or a database value does not establish that its meaning is a native Gambio field, that it is accessible through the chosen migration setup or that the destination has an equivalent consuming process.
The presence of a value in the database does not make it a core Gambio field. A module may store a marketplace listing ID, supplier code, payment transaction reference, Product feed status, custom Customer property, or Order-processing flag. Its meaning depends on the module or external system that reads it.
| Data owner | Example records | Translation decision |
|---|---|---|
| Gambio core | Products, Categories, Customers, Orders, content, options, variants | Map through native data relationships. |
| Gambio module or GXModule | Module fields, tables, statuses, configuration-linked records | Preserve only with an identified target owner and related core key. |
| Theme or StyleEdit | Layout, blocks, templates, visual settings | Treat as target presentation rather than commerce master data. |
| External ERP/PIM/WMS | Master identifiers, stock, supplier, pricing, or fulfillment records | Retain durable cross-system keys and authority. |
| Marketplace or channel | Listing IDs, offer states, channel categories, synchronization metadata | Keep separate from the canonical Product unless the target workflow still uses them. |
| Custom code | Bespoke tables or modified core fields | Define explicit entity ownership instead of assuming native support. |
Different Gambio Stores can expose very different technical evidence, but the same rule applies: active extension-owned data needs a continuing owner. Obsolete technical artifacts do not become valuable merely because they exist in the source database.
Gambio Translation Decisions by Business Meaning
| Source pattern | Correct Gambio question | Consequence of a wrong assumption |
|---|---|---|
| Parent Product with child combinations | Is the source value an option, a Product Option, a current variant, or a legacy attribute/property combination? | Child SKU, stock, price, image, or selected values are lost or duplicated. |
| Product visible only to wholesalers | Does customer-group visibility own the restriction? | The Product becomes public or inaccessible to the intended buyers. |
| Tier or quantity price | Which Product, group, threshold, and currency define the price? | Buyers receive the wrong price even though the numeric value exists. |
| Content shown on a Product page | Is it a Product tab, additional field, module block, or CMS Page? | Content arrives without the relationship that displays it. |
| Historical Order status | Which Order history, payment, fulfillment, or withdrawal record explains the state? | Staff cannot interpret the past transaction reliably. |
| Module-created field | Which module or external system owns and updates the value? | Orphan data is copied into a field that no process maintains. |
| Legacy URL | Which Product, Category, or content record should receive the redirect? | Search and internal-link continuity break despite successful record transfer. |
Gambio migration preserves meaning when Product lineage, buyer choices, customer-group commerce, historical Order evidence, content ownership, and extension records are treated as connected but separate domains.
Conclusion
Gambio data-model translation is shaped by catalog generation, Product types, Category links, current and legacy option structures, Customer-group pricing and visibility, historical Orders, Content Manager records, modules, APIs, and store-specific extensions. A source field is useful only when the Target Store preserves the entity that owns it and the related records that give it meaning.
The strongest target model distinguishes Products from variants, descriptive fields from buyer choices, Customer master data from Order snapshots, content from presentation, and core Gambio records from module or external-system data. That ownership discipline produces a catalog and commercial history that remain understandable instead of merely populated.
Common Questions
What is the difference between Gambio options and Product Variants?
Options define selectable values, and Product Options connect them to Products. Independent selections can carry price or weight adjustments without becoming variants. Product Variants represent specific combinations with their own commercial relationships. Older attributes and properties use different structures, so retain the selected generation and actual dependencies.
Should every source Product combination become a Gambio Product Variant?
No. A variant is appropriate when the selected values identify a distinct sellable combination. An independent price modifier, personalization input or descriptive specification can require another structure. Price or weight differences alone do not establish variant identity; the Product, combination and stock relationships matter.
How do Gambio customer groups affect data migration?
Customer groups can govern group prices, graduated prices, tax-related settings and other buying rules. Product visibility also depends on the relevant configuration. Preserve the Product, group, threshold and rule relationships rather than only a group label, and retain historical Order amounts instead of recomputing them from current membership.
Can one Gambio Product belong to several Categories?
Yes. Gambio can link a Product to multiple Categories. A source Store that duplicates Products for navigation may be better represented by one Product identity with several Category assignments.
Are Gambio Content Manager entries the same as Product tabs or theme blocks?
No. Standalone Pages in the Content Manager have their own content and route identity. The Content Manager also contains Elements and Product content, whose relationships must follow their purpose. Product tabs remain attached to Products; theme blocks and StyleEdit settings belong to presentation. A shared editing area does not make all these records equivalent.
What should happen to data created by Gambio modules or external integrations?
Identify the module or external system, the core record it extends, and the stable identifier that links them. Active relationships need an explicit Target Store destination; obsolete technical records can be excluded or archived without treating them as native Gambio data.
Can a Gambio Customer keep several commercial group memberships?
The documented model assigns one commercial group to each Customer. If a source uses several overlapping memberships, distinguish the group that governs Gambio commerce from marketing, loyalty or other cohorts. Those additional meanings need their own supported owner; placing all group names in a text field does not preserve their original rules.