A size-and-color variant, an embroidered message and a descriptive specification need different destinations in Jumpseller. Resolve that selling meaning before choosing a migration service. The next decision is who will execute the agreed actions: the customer or Next-Cart experts.
Store size gives only part of the picture. A small catalog may hide inventory-bearing choices or app rules; a larger catalog may follow predictable product, category, customer, order, page and URL structures. Supported records can fit Standard or Managed Migration when the selected path and target representation are clear. Eligible Add-ons address bounded filtering, value changes or field routing. Unsupported records and bespoke interpretation require tailored scope.
Use the available standard Demo sample to examine those assumptions, with paid proof for enhancements or customization. The customer supplies business meaning, retains manual access and verifies the final result, including when experts execute the migration. The preparation checklist identifies the source evidence needed for that decision.
Start With the Migration Responsibility Model
Establish the required data outcome first, then assign execution. Standard Migration is customer-led migration within supported capability. Managed Migration supplies expert execution of agreed Migration Actions within that same capability. The customer retains manual access, explains business meaning and verifies the final result; broader review, implementation or launch management must be agreed explicitly.
| Approach | Best fit | Caution |
|---|---|---|
| Standard Migration | Supported source data, prepared Jumpseller setup, clean product/category/customer/order structure, and a team ready to self-perform the migration process | Not ideal when complex business logic needs tailored interpretation or the team requires included expert-led execution |
| Managed Migration | Standard migration capability, but the customer needs included expert-led execution and less hands-on migration operation | Still depends on standard migration capability unless additional custom work is agreed |
| Add-ons | data-type-specific record conditions, expression-based field-value changes, or source fields that need different destinations | Data Filter, Data Transformation, and Advanced Data Mapping do not replace Custom Migration for unsupported app data or bespoke interpretation |
| Custom Migration | Custom Platform handling, unsupported data or app-owned records outside supported extraction, custom fields or external identifiers whose required handling exceeds supported controls, or custom migration logic adjustment | Scope should be defined from evidence, not assumed from a vague request for customization |
A Jumpseller migration can also combine approaches. A project may use Managed Migration for execution, Advanced Data Mapping for a defined source-field destination, and Custom Migration for a specific unsupported data area. The key is to name the reason for each component instead of treating the migration as one undifferentiated service choice.
Match Scope to the Required Jumpseller Result
Product and catalog complexity
Product structure is often the strongest signal for the right Jumpseller migration approach. A clean product catalog with ordinary SKUs, categories, images, prices, stock, and SEO fields can often fit a standard path. A catalog with dense variants, custom fields, app-based product builders, bundles, digital fulfillment, or source-specific option behavior needs closer review.
If multi-location inventory is active, identify which location owns each quantity and which system will maintain it after migration. A total stock value and a location assignment answer different questions. A migrated snapshot does not deploy an ERP connection or reproduce ongoing inventory automation.
Jumpseller Colors and Options can create variants with separate selling values and stock. Text Input, Text Area and file inputs instead collect personalization; checklist extras do not create stock-bearing variants. Descriptive custom fields serve another purpose. Choose the target representation from the actual source meaning, then confirm supported handling rather than treating every option label as a variant.
| Product profile | Likely service path | Why |
|---|---|---|
| Simple products with ordinary categories, images, prices, stock, and SEO fields | Standard Migration or Managed Migration | The data meaning is likely predictable if the source platform is supported and the target store is prepared |
| Products with sellable variants that affect SKU, price, image, or stock | Standard Migration or Managed Migration after Demo Migration proof | Check available standard variant output and separately owned storefront behavior; enhanced or tailored handling needs paid proof |
| Products with large or unusual option matrices | Data Transformation or Advanced Data Mapping only for a defined supported value or field-destination need; otherwise Custom Migration review | Dense structures can expose destination limits or bespoke interpretation needs |
| Products with descriptive custom fields used as specifications | Advanced Data Mapping may help when supported source fields need different Jumpseller destinations | Custom Migration may be needed when required behavior exceeds supported handling; compatible descriptive mapping remains a separate possibility |
| Bundles, kits, subscriptions, product builders, personalization, or app-owned product logic | Review the required records and behavior before assigning Custom Migration | Native target availability does not prove migration coverage; supported inputs may fit standard handling, while unsupported records or bespoke logic need tailored scope |
When the available standard Demo exposes a missing product relationship, classify the gap before changing the service. A supported correction may remain within Standard or Managed Migration; a bounded enhancement may use an eligible Add-on. Critical meaning outside supported fields or relationships needs Custom Migration assessment and agreed paid proof.
Customers, orders and historical meaning
Customer and order data should be assessed for meaning, not only volume. A standard migration may be enough when customer records contain ordinary profile and address information and orders contain understandable line items, totals, payment status, fulfillment status, taxes, discounts, and shipping data. More careful handling is needed when the source store uses custom statuses, group-based logic, payment references, tax identifiers, subscriptions, customer segmentation, staff notes, or external order IDs.
Historical order migration is different from future checkout configuration. A migrated order can preserve the history of what happened, but future payments, shipping, taxes, and checkout behavior must be configured inside Jumpseller. The service path should not assume that order history and operating checkout are the same problem.
| Data area | Standard-path signal | Upgrade signal |
|---|---|---|
| Customer records | Name, email, phone, address, account status, and ordinary profile fields | Customer groups control pricing, access, tax, payment, shipping, or external CRM behavior |
| Customer accounts | Customer identity can remain readable and customer communication is planned | Password expectations, account activation, or customer access rules are unclear |
| Orders | Order history contains ordinary line items, totals, payment status, fulfillment status, discounts, and taxes | Custom statuses, app-owned data, external IDs, partial fulfillment rules, or complex refunds require interpretation |
| Historical payments | Payment method and status need to remain readable | Transaction references must feed accounting, ERP, or external reconciliation workflows |
| Fulfillment | Shipping method and fulfillment status are enough for history | Warehouse, supplier, marketplace, dropshipping, pickup, or multi-location behavior affects operations |
A service path that works for catalog data may not be enough for customer and order continuity. If staff need historical order data for service, tax, warranty, returns, or reconciliation, order samples should be reviewed before the approach is confirmed.
Content, SEO, languages and redirects
Jumpseller migration can involve CMS Pages, Blog Posts, product pages, category pages, metadata, image content, internal links, language versions, and URL redirects. The right approach depends on whether the content can be represented cleanly in Jumpseller or whether the source store uses custom page builders, embedded app content, unusual URL patterns, or multilingual structures that need interpretation.
Do not treat content as secondary if the old store relies on content for search visibility, product education, buying guides, policy trust, or campaign landing pages. A migration that preserves products but breaks key content pathways can create customer friction and SEO loss.
| Content profile | Likely approach | Review focus |
|---|---|---|
| Ordinary pages, posts, metadata, and image content | Standard Migration or Managed Migration where the selected path supports the required content records | Confirm readability, formatting, internal links, and destination quality |
| High-value product/category URLs | Standard or Managed Migration where the required URL values are supported, with a separately owned redirect plan | Confirm source URL inventory and target destination quality |
| Multilingual content across products, categories, pages, and SEO fields | Limited standard Demo evidence plus separately owned language and route checks | Confirm language setup and translation placement before launch |
| Page-builder or app-owned content | Custom Migration review may be needed | Determine whether content can move as usable content or requires rebuilding |
| Complex internal linking or campaign landing pages | Content and redirect review, with Custom Migration only when bespoke migrated data handling is required | Broken internal links and weak redirects can damage usability and search continuity |
The service path should preserve valuable content where it matters and avoid migrating obsolete content only because it exists. Content scope should be an editorial and operational decision, not only a database decision.
The supported-platform directory lists Jumpseller as an API-connected Target. That establishes the supported connection identity, not blanket coverage for every native Jumpseller feature or source record.
Use Add-ons for Bounded Data Controls
Add-ons should be used when the migration requirement fits a supported, bounded need. For Jumpseller, that means filtering records through field-based conditions for each data type, transforming field values through expressions, or remapping source fields to compatible target fields.
Supported Add-ons follow the processing order Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping where eligible. Jumpseller cannot use Advanced Database Mapping as Target. Filtering selects records, transformation changes values, and mapping routes the source or already transformed value unchanged. Combining supported Add-ons does not itself require Custom Migration. The standalone Tax data type is outside both mapping Add-ons’ standard scope. Supported tax-related fields on Orders remain a separate field-compatibility question.
Identify the actual supported operation rather than using Add-ons as a general answer for app-owned behavior. A required field may fit compatible mapping; unsupported extraction, bespoke interpretation or business logic needs Custom Migration review. External identifiers also need a clear destination and acceptance rule.
| Add-on use case | Appropriate when | Not appropriate when |
|---|---|---|
| Data Filter | Supported Products, Customers, Orders, or content must satisfy defined source-field conditions to migrate | The filter depends on unsupported app logic or unclear source meaning |
| Data Transformation | Supported field values need to be transformed through defined expressions during migration | The required logic depends on external systems or bespoke business rules |
| Advanced Data Mapping | Supported source fields need compatible Jumpseller target fields | The destination requires unsupported target behavior or structure |
A useful test is whether the requirement can be described through a record-field condition, a target-value transformation expression, or a source-to-destination field map. Custom interpretation belongs in Custom Migration review.
Advanced Database Mapping is not available with Jumpseller as Target. An eligible Source setup does not override that destination limit. A requirement outside supported field mapping needs a compatible supported destination, a separately owned target solution or Custom Migration review.
For a bounded requirement, compare the operations in Add-ons. Use Custom Migration assessment when the required extraction, relationship or behavior exceeds supported handling.
Use Custom Migration for Unsupported or Bespoke Requirements
Custom Migration is appropriate for agreed tailored migration requirements, including unsupported app records, bespoke transformations, Custom Platform handling or changes to standard migration logic. Specify the data, business purpose and target representation. Separate migration of required records from app deployment, checkout logic and storefront implementation.
For Jumpseller, Custom Migration should be reviewed when product behavior, customer behavior, order meaning, stock workflows, content structures, or integration requirements cannot be represented through standard migration behavior or supported Add-ons.
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 Jumpseller scope.
| Custom Migration trigger | Example | Why it matters |
|---|---|---|
| Custom Platform source | The source store uses a custom-built catalog or checkout structure | Data needs interpretation before it can become usable Jumpseller records |
| Unsupported app data | Reviews, subscriptions, bundles, loyalty, product feeds, or custom checkout data live in app tables | App-owned data may not be available through standard migration paths |
| External identifiers | ERP, warehouse, accounting, marketplace, or fulfillment IDs must remain usable | First check supported preservation, value transformation and compatible field mapping. Custom scope applies when these cannot deliver the required identifier relationship. |
| Custom fields with behavior | A field controls pricing, eligibility, stock, product display, or fulfillment | Confirm whether supported transfer and compatible target configuration can preserve the required pricing, eligibility, stock, display or fulfillment meaning. Custom migration scope applies when the data relationship exceeds those controls; the live feature retains its own implementation owner. |
| Custom migration logic adjustment | The project needs bespoke transformation rules | Standard settings and Add-ons are not enough to express the required handling |
Custom Migration should be scoped with examples after confirming that supported settings and Add-ons cannot deliver the required handling. The strongest request is not "customize the migration." It is a clear statement such as: preserve ERP product IDs as usable references, transform source product builder options into Jumpseller-readable product fields, or retain custom order metadata for staff review.
Capacity and Evidence Before Full Migration
How Entity Points affect scope planning
Entity Points size counted migration capacity rather than Jumpseller structural complexity. Eligible Products, Customers, Orders and Blog Posts consume Entity Points on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Categories, Reviews, Coupons, CMS Pages and related structures can still matter without being independently counted record types.
| Counted area | Jumpseller planning question | Why volume alone is insufficient |
|---|---|---|
| Products | Which Products, variants, option structures, digital items, bundles, or app-influenced records should enter the target catalog? | One Product can carry several purchasable combinations and dependencies. |
| Customers | Which registered accounts, guest-related records, addresses, consent fields, and duplicate profiles remain useful? | Account usability and marketing consent are not proved by Customer count. |
| Orders | How much history is needed for support, finance, fulfillment, returns, and external-system reference? | Historical meaning depends on line items, statuses, totals, taxes, refunds, and external IDs. |
| Blog Posts | Which content should remain part of the Jumpseller site and URL plan? | Content value depends on links, metadata, theme presentation, and redirect decisions. |
Records already counted within the purchased migration and fixed path do not consume Entity Points again simply because another migration action occurs. New eligible records can consume Entity Points when migrated for the first time. This matters when the source store remains active and new Orders or Customers appear after the first accepted run.
Entity Points should be reviewed together with filtering and data quality. Test records, obsolete Products, duplicate Customers, and unnecessary history should be excluded only through deliberate scope rules. Capacity planning must not be used as a substitute for Product-structure, app-data, SEO, or integration analysis.
What Demo Migration can establish
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Jumpseller 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.
| Demo Migration sample | What it should test | Decision outcome |
|---|---|---|
| Simple product | Product identity, price, image, stock, category, and SEO fields | Confirms baseline catalog handling |
| Variant product | Option names, option values, SKU, price, image, weight, stock, and availability | Checks available standard variant meaning; target purchase behavior needs separate acceptance |
| Complex product | Custom fields, digital behavior, made-to-order data, bundles, or app-owned logic | Reveals Add-on or Custom Migration needs |
| Customer sample | Addresses, language, marketing consent, group labels, and account expectations | Confirms customer records are usable without overstating account continuity |
| Order sample | Payment status, fulfillment status, refunds, taxes, discounts, custom statuses, and external IDs | Confirms historical order meaning remains readable |
| Content and URL sample | CMS Pages, Blog Posts, metadata, internal links, and redirects | Checks available standard content and URL values; redirects and public routes need separate acceptance |
| Integration sample | Records connected to ERP, fulfillment, warehouse, marketplace, or reporting workflows | Identifies dependencies; custom output and live integrations need paid or target-side proof |
Use the limited standard result to confirm a supported path or identify a particular gap. Add-on output and customization must be proved through the agreed paid scope; app operation, storefront purchase behavior and redirect readiness remain separately owned. A clean Demo does not establish the complete Jumpseller launch outcome.
The Jumpseller validation priorities connect these data decisions with storefront, stock and historical evidence.
How Migration Actions Affect Jumpseller Launch Planning
After a paid migration has produced an earlier result, continued Source Store activity or revised migration requirements may call for further work into Jumpseller. The selected option should reflect whether the recorded configuration and accepted Product, Customer, Order, content, URL, and integration assumptions remain valid.
| Current option | Jumpseller-specific use | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Use when an earlier paid configuration remains valid; choose the source-data window separately. | Review new variants, Customer records, exceptional Orders, content, and any affected integration-linked identifiers. |
| Continue the Migration with a New Configuration | Use when filters, mappings, Product-field interpretation, Customer handling, content scope, languages, redirects, or external-ID rules need to change. | Revalidate the revised rules and compare representative records previously accepted under the older configuration. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; agree the intended target effect. | Repeat the complete acceptance set for catalog, Customers, Orders, content, URLs, apps, and integrations. |
These actions do not recreate Jumpseller themes, checkout scripts, apps, payment or shipping configuration, sales-channel setup, or external-system workflows. Changes in those areas require separate target implementation and revalidation.
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 Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose later-run data handling separately from the Migration Action. The Additional Option Continue the previous migration carries the most recent migration state into the next pass. For selected supported data types, records not transferred in that state form the new-data delta, and supported relationships can use the carried context. This can include a separately migrated data type; the delta is not defined solely by when a source record was created.
An action name alone does not establish the active Additional Options. Edited source records need explicitly supported update handling rather than an assumption of general synchronization. When configuration changes, review the combined earlier and later output and protect intentional target-side changes. The Additional Options reference explains the carried-state behavior.
Decide the Safest Jumpseller Migration Approach
Choose the least complex approach that can deliver the agreed business meaning. Use prepared source evidence and the available standard Demo result, then account separately for paid enhancement or custom proof. Data volume and a simple-looking storefront cannot settle the choice. The service comparison helps assign execution for that confirmed scope.
| Project evidence | Recommended direction | Reason |
|---|---|---|
| Supported source data, clean catalog, ordinary customers and orders, prepared Jumpseller setup, and customer-led execution readiness | Standard Migration | The project fits a predictable supported migration path |
| Supported source data, standard complexity, but the customer prefers included expert-led execution | Managed Migration | Execution support is needed even if custom migration logic is not |
| Supported data with bounded record filtering, field-value transformation, or field remapping needs | Standard Migration or Managed Migration with Add-ons | Add-ons can handle supported scope or mapping adjustments |
| Supported data plus unsupported app records, or external IDs/custom-field behavior whose required handling exceeds supported controls | Custom Migration for those requirements, with the broader execution path defined separately | The custom requirement should be scoped instead of buried inside a general service choice |
| Custom Platform source or bespoke transformation requirement | Custom Migration | The source structure requires custom interpretation or custom migration logic adjustment |
| Standard start, but Demo Migration exposes difficult product, customer, order, content, or integration behavior | Adjust the service path before Full Migration | Evidence should change the plan before execution creates rework |
The safest approach is evidence-led. A migration can start with a standard assumption, but that assumption should remain provisional until the difficult samples are reviewed.
Conclusion
The Jumpseller approach should preserve the distinction among sellable variants, personalization inputs, descriptive fields and inventory ownership. Standard Migration fits supported customer-led execution; Managed Migration supplies expert execution of agreed actions. Eligible Add-ons refine supported data, while Custom Migration handles tailored requirements with Self-Execute or Expert Handle.
Use available standard Demo samples to reveal gaps and the agreed paid scope to prove enhanced or custom output. Keep apps, live inventory automation, checkout and public route acceptance explicitly owned. For later paid actions, choose the source window separately and verify the combined earlier and later result.
Common Questions
Is Standard Migration enough for a Jumpseller migration?
Standard Migration can be enough when the source path is supported, the data is clean, Jumpseller can represent the required product, customer, order, content, and SEO structure, and the customer is ready to self-perform the migration process. Demo Migration should confirm the assumption before Full Migration.
When should Managed Migration be selected for a Jumpseller migration?
Managed Migration fits supported Jumpseller scope when experts should execute the agreed Migration Actions. The customer retains manual access and final verification. Wider review, launch management, app setup or target implementation must be expressly included if needed.
When are Add-ons relevant for Jumpseller?
Add-ons fit supported record filtering, expression-based value transformation or compatible field remapping. Mapping keeps the source or already transformed value unchanged. Advanced Database Mapping is unavailable with Jumpseller as Target; unsupported app data and bespoke interpretation require tailored review.
When does a Jumpseller migration require Custom Migration?
Custom Migration fits requirements such as unsupported app records, Custom Platform handling, bespoke transformations or changes to migration logic. Determine whether a field or external identifier has a supported destination before classifying it as custom. The agreed tailored scope can use Self-Execute or Expert Handle.
Can a project combine Managed Migration, Add-ons, and Custom Migration?
Yes. A project may use Managed Migration for execution, Data Filter or Advanced Data Mapping for a bounded supported requirement, and Custom Migration for specific unsupported requirements. Each component should have a clear reason and scope.
What should Demo Migration prove before the final approach is confirmed?
Demo can inspect the limited available standard sample and expose gaps around variants, Customers, Orders and content. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Enhanced output, dependency-owned records and live Jumpseller behavior need agreed paid or target-side proof.
Which Migration Action fits a Jumpseller follow-up?
Either continuation needs an earlier paid migration. Keep its saved configuration when valid, or choose a new configuration for intentional supported changes. The first paid run or a distinct result uses Perform a New Migration. Choose the source-data window separately, review combined output and define target effects without assuming protected data is erased.
Do all Jumpseller product options need variant migration?
No. Colors and Options can create stock-bearing variants, while text, file and checklist inputs serve different purchase purposes. Descriptive custom fields are another category. Identify the required selling unit and inventory meaning before selecting supported mapping, target configuration or tailored handling.