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. |
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 serve a different purpose. They describe a Product and can support discovery when represented as suitable selectable values. Brand, material, fragrance family, compatibility type, season, or technical specification can belong to this layer when they do not create independent sellable units.
| 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 | The descriptor can support Product information or filtering without multiplying variants. |
| 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 are not meaningful without their owner. A simple Product may own one price and one stock quantity. A Product with variants can move SKU, price, cost, weight, images, and inventory to each combination. Customer-specific pricing can introduce a separate relationship between a Customer Category and a price list. Volume pricing can add quantity thresholds rather than changing the base Product identity.
Inventory can also be location-aware. When location-specific stock is present, the destination model must preserve the relationship among Product or variant, inventory location, quantity, and stock status. A single total quantity cannot represent which location can fulfill the item or which integration is authoritative.
| 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 are also distinct from current stock. Orders can change inventory as their statuses change, but an imported Order is historical evidence rather than an instruction to repeat the original stock movement. The destination needs the final intended inventory state and the historical Order context as separate records.
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. |
Password data deserves separate interpretation. A source password hash may use a scheme that cannot be reused by Jumpseller. In that case, the Customer identity can remain meaningful even though authentication credentials require a different account-access flow. The data model should not treat a migrated email address as proof that the original login credential is portable.
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 | The record does not own current gateway configuration. |
| 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. |
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 Posts, URLs, and Theme Content Have Different Owners
Jumpseller storefront content can include CMS Pages, Blog Posts, Product and Category descriptions, navigation entries, banners, theme sections, images, policy content, and SEO fields. A source platform may store all of these in one page builder or content table, but Jumpseller assigns them to different objects.
| 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 | Blog Post | Publication date, authoring context, categories or tags, media, and permalink may differ from a 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 Post 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. 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 create variants or collect buyer input, depending on the option type. Custom fields describe the Product and can support filtering when represented appropriately. A value should be assigned according to whether it creates a sellable combination, captures a one-time buyer choice, or describes the Product.
When should a source attribute become a Jumpseller variant?
It should become part of a variant when the choice identifies a real sellable unit with its own commercial or inventory meaning, such as a distinct SKU, price, stock quantity, weight, cost, or image relationship. Descriptive values and free-form personalization should remain outside the variant grid.
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 Posts, campaign pages, or other destinations.
How should historical Orders relate to current Products?
Historical Orders should retain their Order-line snapshots, selected options, prices, addresses, statuses, and external references. Where a reliable Product or variant relationship exists, it can remain linked, but later catalog changes should not rewrite what the Order recorded at purchase time.
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.