Gambio combines a broad commerce catalog with customer-group pricing, content management, multilingual fields, modules, and two operating environments: Gambio Cloud and self-hosted Gambio. 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
Gambio has an active current platform line, but long-lived Stores may contain data created under earlier catalog structures, third-party modules, or custom database changes. The source version and installed components influence whether a choice is stored as an older article attribute or property, a current option, a Product Option, a Product Variant, or a custom module record.
The Cloud and self-hosted environments use the Gambio platform, but they create different ownership boundaries around technical records. Cloud Stores normally rely more heavily on platform-managed hosting and updates. Self-hosted Stores can contain local files, GXModules, themes, database additions, or direct modifications that have no equivalent in a clean target installation. This distinction should 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. |
| Cloud Store record | Native Gambio data with platform-managed environment context | Keep commerce data separate from platform-managed technical configuration. |
| Self-hosted 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. |
| Combination has its own SKU, stock, price, weight, image, or availability | Product Variant | 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, property, or content | Descriptive value remains distinct from the purchased 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. |
A simple size selector may map cleanly. A combination matrix with separate stock and images requires variant-level identity. A personalization field belongs to the purchased Order line, not to a reusable variant. Treating all three as ordinary options can make the catalog look correct while losing fulfillment and historical meaning.
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. Gambio can use it to control Product visibility and Product pricing. A source wholesale tier may therefore require a Customer-group relationship, while a marketing segment may belong elsewhere. Historical Orders must retain the actual price, discount, tax, and quantity evidence recorded at purchase time rather than being reinterpreted from the Customer’s current group.
| 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 value | Keep the commercial rule 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 after migration must not rewrite the address recorded on an older Order.
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 | Content Manager entry | 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 supports modules, GXModules, themes, REST APIs, imports and exports, and integrations with marketplaces, accounting, fulfillment, search, or other systems. These components can create fields, tables, statuses, identifiers, and workflow records that are not part of the native Product, Customer, or Order model.
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. |
Cloud and self-hosted Stores may expose 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 the Cloud or self-hosted environment. 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 choice domains and Product Options connect those choices to a Product. Product Variants represent concrete combinations and can carry combination-specific commercial values. Older Stores may use article attributes or properties instead, so the source version and table relationships matter.
Should every source Product combination become a Gambio Product Variant?
No. A combination fits a variant when it has separate identity or commercial values such as SKU, stock, price, weight, image, or availability. Personalization and descriptive specifications usually belong to different structures.
How do Gambio customer groups affect data migration?
Customer groups can control Product visibility, group-specific prices, graduated prices, tax treatment, or other commercial behavior. Preserving only the group label does not preserve those Product and pricing relationships.
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. Content Manager entries are independent content records. Product tabs belong to Products, while theme blocks and StyleEdit settings belong to presentation. Each needs a separate target owner.
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.