A shirt size, an engraving message and a material label may share one source attribute table, but they represent different relationships in Jumpseller. When Jumpseller is the prospective Target Platform, the size can identify a stocked variant, the message belongs to a purchase, and the material describes the catalog item. Their destination follows that meaning rather than their shared source column.
Moving data into Jumpseller requires more than matching source columns to destination fields. Jumpseller separates the parent Product, its buyable variants, customer-entered customization, descriptive custom fields, Category membership, navigation, inventory, Customer identity, historical Orders, storefront content, and integration records into different relationships. A source platform may store several of those meanings inside one attribute system or one extension table.
The central translation question is therefore not whether a source value can be copied. It is which Jumpseller object should own the value and what relationship must remain intact. Size and color may define stock-bearing variants; engraving text may remain an Order-line input; brand may be a custom field used for filtering; a Category may organize Products without reproducing the old menu; and an external identifier may remain essential even though customers never see it.
Products Are Parent Catalog Records, Not Complete Sellable Units
A Jumpseller Product provides the shared catalog identity for a sellable offer. It can carry the name, descriptions, images, Category relationships, status, pricing defaults, stock settings, SEO fields, options, custom fields, and other merchandising information. When options generate variants, however, the parent Product no longer owns every commercial value by itself.
Source platforms often combine master-product and sellable-unit data differently. One source may store every size and color as an independent Product. Another may store one Product with child SKUs. A third may keep a parent Product but place images, cost, stock, and price adjustments in an application-owned matrix. The Jumpseller destination must preserve the parent-child distinction rather than flattening all records into the same level.
| Source catalog pattern | Jumpseller interpretation | Relationship consequence |
|---|---|---|
| One record for every size and color | Parent Product with option-generated variants, where the records represent one merchandising family | Shared descriptions and Categories can remain on the parent while SKU, stock, price, weight, and images can belong to variants. |
| Parent Product with child SKUs | Product plus variant combinations | Existing child identifiers need to remain attached to the corresponding option combination. |
| Simple Product without selectable choices | Product with its own commercial values | No artificial variant layer is needed merely because the source exposes an attribute table. |
| Digital or non-shipped item | Product whose fulfillment and inventory meaning differs from a physical item | Delivery references, files, and shipping expectations must remain separate from ordinary stock data. |
| App-generated Product family | Product records plus application-owned relationships | Descriptive values may fit standard fields, while generated rules or linked records remain owned by the source application or another destination system. |
Native Product and variant IDs identify Jumpseller records and their relationships. A SKU identifies a commercial item, while an ERP or source-system key identifies that item in another namespace. Those keys can help match the corresponding destination record, but copying a SKU does not preserve the original native ID or reconnect an Order line by itself.
Product status also carries meaning. A source state such as active, hidden, draft, archived, discontinued, or back-orderable may not correspond to one Jumpseller status. The destination representation should distinguish public visibility, purchasability, stock availability, and seasonal retention rather than compressing every state into enabled or disabled.
Options, Variants, Customer Inputs, and Custom Fields Are Different Structures
Jumpseller Product Options can generate real variants, but not every option-like source value belongs in a variant grid. Option choices such as size or color can produce combinations with their own SKU, price, stock, weight, cost, and image relationships. Other Product inputs collect text, longer messages, files, or optional selections without creating a separately stocked combination.
Custom Product Fields describe the catalog item without creating independently stocked choices. Suitable selectable values can also support discovery. A Selection custom field can carry details for individual variants, while other descriptive fields apply across the Product. Brand, material, fragrance family, compatibility type or season therefore needs both a field definition and the correct Product or variant assignment; a variant-specific descriptor is still different from the option combination that creates that variant.
| Business meaning | Appropriate Jumpseller structure | What must not be lost |
|---|---|---|
| Size or color with independent stock | Variant-generating Product Option | Combination identity, SKU, inventory, price, weight, and image relationships |
| Engraving, dedication, or short message | Customer-entered text input | The chosen value must remain associated with the purchased Order line, not the parent Product definition. |
| Detailed personalization instructions | Text-area input | Free-form buyer input must not be converted into reusable catalog metadata. |
| Artwork or document supplied by the buyer | File input | The file reference belongs to the purchase context rather than inventory. |
| Optional packaging or paid extra | Non-variant selectable input where represented | Price influence and the chosen Order-line value remain distinct from a stocked variant. |
| Brand, material, aroma, compatibility class, or specification | Custom Product Field with the applicable Product or variant assignment | A suitable selectable descriptor can support information or filtering without creating another stock-bearing variant. |
| Conditional configurator rule | Application or external-system relationship | Dependencies, formulas, and conditional visibility are not equivalent to ordinary option values. |
This distinction prevents variant inflation. A source catalog that stores color, size, monogram text, warranty choice, and technical specifications in one attribute table may need four different Jumpseller representations. Treating all five as variant dimensions creates combinations that are not real inventory units; treating all five as custom fields removes the ability to select and stock genuine variants.
Categories, Navigation, and Filters Form Separate Discovery Relationships
Jumpseller Categories organize Products and can form parent-child hierarchies. They can also carry names, descriptions, images, ordering, SEO information, and Product membership. Category records therefore matter to catalog structure, but they do not by themselves reproduce the entire storefront path.
Navigation can place Categories in the main menu, a Category menu, or the footer, and can nest those entries independently of the Product-to-Category relationship. A source taxonomy may also include internal merchandising groups, campaign collections, brands, search facets, or hidden operational labels. Each grouping needs an explicit destination meaning.
| Source grouping | Possible Jumpseller ownership | Translation decision |
|---|---|---|
| Permanent Product family | Category and Product membership | Preserve hierarchy and membership as catalog structure. |
| Main navigation branch | Navigation entry pointing to a Category or another page | Keep route and menu placement separate from Category existence. |
| Brand or material facet | Custom Product Field and filter relationship | Use a descriptor when the value groups Products without defining a buyable choice. |
| Size or color facet | Product Option and filter relationship | Preserve the option vocabulary consistently so equivalent choices can support filtering. |
| Seasonal campaign | Category, landing content, promotion context, or theme link | Choose the object that owns the campaign rather than creating a permanent taxonomy by default. |
| Internal reporting label | Back-office field or external-system classification | Do not expose an internal code as storefront navigation merely because it came from a Category table. |
Jumpseller filters can draw from variant-generating Product Options and selectable custom fields. That makes naming consistency part of the data model. “Color,” “Colour,” and “Finish” may represent the same business concept in the source but become separate filters if they are translated as unrelated fields. Conversely, values with similar labels may need to remain separate when one defines a variant and another is only descriptive.
Pricing and Inventory Can Belong to the Product, Variant, Customer Context, or Location
Price and stock values need an owner. A simple Product may own one price and quantity; a Product with variants can place SKU, price, cost, weight, images and inventory on each combination. Where the selected plan and configuration provide price lists, a Customer Category connects the buyer to the applicable prices. Quantity tiers add threshold-and-price relationships without changing Product identity. A copied wholesale label or tier price does not establish the rule that applies it.
A location can have different roles as a stock origin, shipping origin or pickup point. Where location stock is enabled, quantity belongs to the Product or variant at that location. The total across locations does not explain which origin can fulfill a purchase, and a pickup address alone does not establish its stock ownership. Unlimited-stock treatment is also an availability rule, not a synonym for a blank or zero quantity; Product visibility and purchasability remain separate.
| Commercial value | Possible owner | Why ownership matters |
|---|---|---|
| Base selling price | Product or variant | A parent price cannot replace distinct prices for real combinations. |
| Compare-at or reference price | Product or variant | The reference value must remain attached to the same sellable unit as the active price. |
| Cost | Product or variant | Margin data becomes misleading when a variant cost is moved to the parent. |
| Quantity tier | Product or pricing relationship | The threshold and unit price belong together. |
| Customer-specific price | Customer Category and price-list relationship | The price is conditional on buyer classification rather than a universal Product field. |
| Stock | Product or variant at a location | Quantity must remain linked to the correct sellable unit and inventory location. |
| Unlimited-stock state | Product or variant availability rule | A blank or zero quantity is not necessarily equivalent to unlimited inventory. |
Historical stock movements remain distinct from current stock. Order and fulfillment workflows may change inventory according to their configuration, but an imported Order records past activity rather than instructing the destination to repeat it. Current quantities, location assignments and historical transaction evidence need their own relationships.
Customers, Customer Categories, Addresses, and Marketing Relationships Need Separate Meaning
A Jumpseller Customer record represents account and contact identity, but a source customer profile may include more than a name and email address. Addresses, tax identifiers, company details, marketing consent, account state, notes, segmentation, external CRM identifiers, and Customer Category membership can each have a different owner.
| Source account element | Jumpseller destination meaning | Relationship boundary |
|---|---|---|
| Name and email | Customer identity and contact information | Identity should not be duplicated merely because the person has several Orders. |
| Billing and shipping addresses | Address context linked to the Customer or historical Order | Current account addresses and Order snapshots can legitimately differ. |
| Company or tax information | Customer field, address field, or external business record | The value belongs to the object that uses it for account or transaction context. |
| Customer group or wholesale tier | Customer Category and related pricing or access context where represented | A commercial segment is not just a label when it changes prices or eligibility. |
| Newsletter consent | Marketing relationship or external marketing platform | Consent meaning and source must remain distinct from basic account existence. |
| Loyalty balance or membership state | Application or external-system record | A Customer record alone does not reproduce the program relationship. |
| CRM or ERP identifier | Stable external identifier | The key must remain attached to the same person or company record used by the external system. |
Account identity and usable login credentials are separate. Some explicitly supported Source-to-Target paths can preserve credential verification; other paths require a password reset or another account-access flow. The exact path determines the outcome. A retained Customer ID, email address or stored password field does not by itself show that Jumpseller can verify the original credential.
Orders Preserve Historical Commercial Context, Not Current Store Configuration
A Jumpseller Order brings together the Customer or guest identity, Order lines, selected variants, customer-entered option values, addresses, prices, discounts, taxes, shipping charges, payment state, fulfillment state, notes, timestamps, and external references. These values form a historical snapshot of what happened at purchase time.
That snapshot must remain separate from current Product and configuration records. An old Order line may retain a Product title, SKU, selected options, and price even after the live Product has been renamed, repriced, disabled, or deleted. A historical shipping charge can show what was paid without defining the current shipping method. A payment reference can support reconciliation without configuring the active gateway.
| Order component | Historical meaning | Destination relationship |
|---|---|---|
| Order-line Product identity | What was purchased at that time | Preserve Product or variant reference where possible while retaining snapshot text. |
| Selected options and custom inputs | Buyer choices for that line | Keep them with the Order line even when the current Product definition changes. |
| Price, discount, and tax | Commercial snapshot | Do not recalculate history from current Product or tax settings. |
| Billing and shipping address | Transaction-time address | Keep separate from later edits to the Customer profile. |
| Payment status and reference | Historical payment context | A retained reference does not configure the live gateway or confer authority to charge or refund. |
| Fulfillment state and tracking | Historical delivery context | The record does not define current carrier or warehouse rules. |
| Source channel or external ID | Reconciliation and integration key | Preserve the key when another system uses it to identify the Order. |
Digital delivery has the same boundary: an Order can retain a file or delivery reference without establishing the current permission, expiry or application relationship that grants download access. Historical refunds, tracking and fulfillment labels likewise describe past activity rather than activate new actions.
Guest Orders, canceled Orders, partially fulfilled Orders, refunded Orders, and Orders containing custom inputs all expose relationships that a simple paid Order does not. The destination model should account for those states without turning historical records into active workflow configuration.
CMS Pages, Blog Content, URLs, and Theme Content Have Different Owners
Jumpseller storefront content can include CMS Pages and blog content, plus Product and Category descriptions, navigation entries, banners, theme sections, images, policy content, and SEO fields. In the current Jumpseller model, a blog article is represented as a Page assigned to the relevant blog Page Category and rendered with the Post template rather than as a separate native Blog Post resource. A source Blog Post can therefore remain a migration concept while its Jumpseller destination is a Page with blog-specific category and template relationships.
| Source content | Jumpseller interpretation | Ownership distinction |
|---|---|---|
| About, contact, policy, or guide content | CMS Page | Stable page content and its route remain separate from menu placement and theme layout. |
| Editorial article or announcement | Page assigned to the relevant blog Page Category and Post template | Publication date, content, media, permalink, and blog-listing relationship remain distinct from an ordinary CMS Page. |
| Product or Category copy | Catalog-owned description | The content belongs to the catalog object, not a separate generic page. |
| Header, footer, banner, or homepage section | Theme or navigation content | Presentation placement is not the same as the underlying business record. |
| Meta title, meta description, or permalink | SEO and route relationship on the owning object | Metadata must stay connected to the Product, Category, CMS Page, or blog Page it describes. |
| Redirect or old path | Routing relationship | The old URL remains useful even when the destination object receives a different permalink. |
Theme code can read Product fields, custom fields, Categories, menus, and application output, but it does not own those records. Reproducing old markup is not a substitute for translating the underlying data. Similarly, copying the content body without its links, media, route, and owner can create a page that exists but no longer functions as part of the storefront.
Apps, APIs, Webhooks, and External Identifiers Form a Surrounding Data Layer
Jumpseller can exchange data with external systems through applications, APIs, and webhooks. A source Store may rely on an ERP for inventory, a CRM for Customer classification, a fulfillment service for shipment states, a marketplace for listings, or an application for subscriptions, bookings, reviews, loyalty, bundles, or Product configuration.
Those records should be classified by ownership rather than by visibility. A value displayed on a Product page may be authoritative in an external PIM. A stock quantity visible in Jumpseller may be synchronized from an ERP. A Customer tag may be derived from a CRM. A marketplace listing ID may identify a channel offer rather than the core Product.
| Integration record | Likely owner | Translation requirement |
|---|---|---|
| ERP Product or variant ID | ERP and catalog relationship | Preserve the key on the corresponding Product or variant used for synchronization. |
| Warehouse or location ID | Inventory or fulfillment system | Keep location identity distinct from a plain stock quantity. |
| CRM Customer ID | CRM and Customer relationship | Avoid creating a new unrelated key for the same person or company. |
| Marketplace listing ID | Sales-channel listing | Do not confuse a listing with the canonical Product or variant. |
| App-created subscription, booking, or loyalty record | Application domain | Keep parent Product, Customer, and Order references explicit. |
| Webhook synchronization state | Integration process | Treat timestamps, event IDs, and cursors as operational integration data rather than storefront content. |
A coherent destination does not need to reproduce every source table. It does need a defined owner for every identifier and relationship that supports catalog management, Customer continuity, historical reconciliation, or external synchronization.
A Jumpseller Translation Map Should Resolve Meaning Before Storage
The strongest Jumpseller data model can be summarized as a set of ownership decisions. Parent Products own shared merchandising. Variants own sellable combinations. Customer inputs belong to a Product interaction and later to an Order line. Custom fields describe Products or their assigned variants without generating stocked combinations. Categories organize catalog membership. Navigation owns menu placement. Customers own identity and account context. Orders own historical transaction snapshots. Apps and external systems own their specialized records and identifiers.
| Source question | Translation decision |
|---|---|
| Does the value create an independently priced or stocked item? | Represent it at variant level rather than as a descriptive custom field. |
| Is the value entered by the buyer for one purchase? | Keep it as customer input and preserve it with the Order line. |
| Does the value describe many Products without creating variants? | Use an appropriate custom field or classification relationship. |
| Does the grouping organize Products or control navigation? | Separate Category membership from menu placement. |
| Is the value current configuration or historical evidence? | Keep live catalog and operational settings separate from Order snapshots. |
| Does another system use the identifier as a key? | Preserve it on the destination entity that represents the same business object. |
| Is the record owned by an application rather than Jumpseller core? | Retain the application relationship instead of forcing the data into an unrelated standard field. |
Resolving those questions produces a Store that can manage the migrated data coherently. The destination reflects what each record means, which object owns it, and how it relates to the rest of the Jumpseller environment.
Conclusion
Jumpseller changes data meaning by separating parent Products, variants, customer inputs, custom fields, Categories, filters, navigation, inventory, Customers, Orders, content, and integrations into distinct relationships. A source attribute table, Customer table, or page-builder record can therefore require several destination objects rather than one direct field match.
A coherent migration preserves the ownership behind each value. Products remain connected to real sellable variants, descriptive fields remain distinct from buyer choices, Categories remain separate from navigation, Customer identity remains separate from application programs, Orders remain historical snapshots, and external identifiers remain attached to the systems and entities that depend on them.
Common Questions
Are Jumpseller Product Options and custom fields the same thing?
No. Product Options can generate variants or collect buyer input, depending on type. Custom fields describe the Product or an assigned variant; suitable selectable fields can also support filtering. A descriptor assigned per variant does not create another variant. The distinction is whether the value defines a sellable combination, records one purchase choice or describes an existing item.
When should a source attribute become a Jumpseller variant?
A source choice belongs in a variant when it identifies a real sellable combination with its own commercial or inventory meaning, such as SKU, price, stock, weight, cost or image relationships. A descriptive field can vary between existing variants without defining another combination. Free-form personalization stays with the purchase input and Order line.
Do migrated Categories automatically reproduce the old menu?
No. Categories own Product grouping and hierarchy, while navigation owns menu placement and route presentation. A Category can exist without appearing in the main menu, and a menu can include links to CMS Pages, blog Pages, campaign pages, or other destinations.
How should historical Orders relate to current Products?
Historical Orders retain line snapshots, selected options, prices, addresses, states and external references. A reliable match can link the line to its destination Product or variant, while later catalog changes leave the recorded purchase intact. Payment, refund, tracking and digital-delivery references describe history; they do not establish live payment authority, repeat stock movements or grant current download access.
What happens to source application data that has no native Jumpseller field?
The record should remain classified under its actual application or external-system owner. Important parent references and stable identifiers can be preserved in an appropriate destination structure, while specialized behavior remains distinct from ordinary Product, Customer, or Order fields.
Can one source field have different Jumpseller destinations across Products?
Yes. A source field named “Size,” “Type,” or “Status” may carry different business meaning in different Product families. The destination depends on whether the value creates a variant, describes the Product, controls availability, captures customer input, supports filtering, or belongs to an external workflow.
Can a source SKU replace Jumpseller Product or variant identity?
No. A SKU is a business key; native Product and variant IDs identify destination records. Source and external IDs can help match the same commercial item across systems, but each Order line or integration must refer to the appropriate destination entity. A matching label or SKU does not automatically preserve the original numeric ID or relationship.