Choose the CS-Cart migration approach from the required result and who will execute the work. A variation Product, a visible catalog item, a seller offer and a financial entry are different units; a familiar field name does not establish supported handling.
Next-Cart Migration Services separates customer-operated Standard Migration, expert execution within standard capability through Managed Migration, and approved tailored work through Custom Migration. Confirm the actual CS-Cart product, edition, enabled components and selected Source setup before applying that framework.
What the Migration Approach Must Decide
Resolve three connected questions: what supported data must arrive, who runs the migration, and what behavior must be implemented separately. Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages, Blog Posts and URLs are possible scope areas, not a universal list available on every path.
With Product Variations enabled, group members are actual Products. Feature purpose affects which of them occupy catalog listings, so visible tiles are not a reliable record count. Vendor companies, administrators, offers, commissions and settlement belong to the actual Multi-Vendor requirement; they are not implied by selecting CS-Cart.
| Question | Evidence to resolve it | Direction |
|---|---|---|
| Is the required data supported? | Exact Source-to-CS-Cart path, available fields and target relationships. | Standard capability may fit when meaning and coverage agree. |
| Who should execute it? | Merchant capacity, access, coordination and business review responsibility. | Choose customer operation or agreed expert execution. |
| Will a supported adjustment suffice? | A defined record condition, value expression or compatible field destination. | Assess the four Standard Add-ons within their eligibility. |
| Is handling outside those boundaries? | Unsupported extraction, relationship, consumer or bespoke transformation. | Qualify approved Custom Migration scope. |
| What evidence is still missing? | Representative standard, enhanced or tailored outcomes and current target consumers. | Resolve the applicable scope and proof before broader execution. |
The CS-Cart migration entry provides a starting point for reviewing the intended direction and requirements. Confirm actual path eligibility rather than inferring it from a platform name. The merchant retains business requirements and final verification; target design, checkout, seller onboarding and integration deployment need explicit owners whether execution is self-operated or expert-handled.
When Standard Migration Can Fit
Standard Migration fits when the selected path supports the required data and the merchant can configure, run and review it. Size alone does not establish a need for custom handling.
Useful CS-Cart conditions include:
- Products and Categories have clear identity, placement, prices, stock, images and status.
- Features, Options and variation relationships are understood and supported by the selected path.
- Required Customer, Order, Review, Coupon and content records have confirmed treatment.
- Any seller operation outside the transfer scope has an accepted separate implementation; no required vendor relationship is silently omitted.
- Critical extension fields have supported handling or a clearly agreed separate scope.
- The merchant can provide access, operate the process and approve representative and broader results.
A conventional store can meet these conditions. A marketplace-adjacent project can also do so when required ownership is supported or deliberately outside the transfer scope. Do not infer vendor finance, seller dashboards or governance from ordinary Product and Order coverage.
Optional standard testing can reveal gaps, but it is not a substitute for checking the exact path or requirements excluded from that sample.
When Managed Migration Fits the Execution Need
Managed Migration changes execution responsibility within the same supported capability as Standard Migration. It can suit a clear catalog whose volume, active Order flow or coordination burden makes customer operation impractical.
Agree the expert Migration Actions and timing around business review. Relevant signals include an active Source, a large but understandable catalog, limited internal migration capacity and Product, Order, content or seller reviewers who need coordinated evidence.
Expert execution does not resolve unsupported seller relationships or unclear requirements automatically. The merchant still supplies requirements and access, owns business decisions and verifies the result. Vendor onboarding, launch management and target implementation are separate unless expressly agreed.
If tailored handling is required, use Custom Migration and its applicable Self-Execute or Expert Handle execution choice. A custom requirement does not become supported standard capability because experts run it.
When Add-ons Can Improve the Migration Scope
Use Standard Add-ons for a specific supported data requirement. Multiple controls can remain within standard scope; a custom-field or external-key label alone does not determine the service choice.
| Standard Add-on | Decision-relevant use | Boundary |
|---|---|---|
| Data Filter | Select supported records using defined field conditions. | Capacity quantities are not record-selection rules. |
| Data Transformation | Change supported values using an expression. | Value processing does not recreate seller rules or application logic. |
| Advanced Data Mapping | Route a supported source or transformed value to a compatible target field. | Mapping routes the value unchanged; actual fields and Value Types govern. |
| Advanced Database Mapping | Route an eligible supported database value to a compatible CS-Cart destination. | CS-Cart Target eligibility also requires supported Source setup, schema location and Value Type. Storage does not establish a working consumer. |
The processing order is Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping. For example, if the active path exposes the needed fields, a project could select active Products, normalize a code and route it into its compatible destination. Confirm every control and any continuing warehouse consumer rather than inventing a destination field from the example.
CS-Cart is an eligible Target for Advanced Database Mapping. That is directional support, not permission to route arbitrary tables or assume every Source setup qualifies. A needed change to a Standard Add-on is a Tailored Add-on; bespoke functionality is a Custom Add-on. Both require Custom Migration review and are not additional Standard Add-ons.
Qualify the exact tax-related field and path instead of applying a blanket Tax exclusion or universal support promise. Historical transaction amounts and live target tax behavior are separate requirements. Add-ons and Customization are unavailable in Demo; their outputs need the appropriate paid-scope evidence.
When Custom Migration Is Required
Custom Migration applies when approved requirements exceed supported migration and Standard Add-on boundaries. Examples can include unsupported extraction, custom platforms, bespoke relationships or migration logic, and Tailored or Custom Add-ons.
Assess the actual requirement before classifying it:
- Vendor ownership, commissions, settlement or seller financial records may need nonstandard interpretation.
- Launch-critical custom fields or extension tables may already fit supported mapping; use tailored handling only for the remaining unsupported requirement.
- Company or B2B relationships, configurators and changed workflows need a defined representation and consumer.
- ERP, PIM, POS, fulfillment and accounting keys need continuity, but the presence of an external identifier alone does not force Custom.
- A modified Source requires review of its actual extraction and schema, not an assumption based only on its platform label.
Marketplace financial terminology also needs installed-version meaning. Current CS-Cart distinguishes a payout from a vendor to the marketplace owner and a withdrawal in the other direction. Identify the event, recipient, amount, settled/open position and relevant Order; these entries are not automatically ordinary Order history.
Selecting CSV, XLS or XML as a generic Source Platform requires Custom Migration. Its included standard file workflow covers Products only; Customers, Orders, vendors and financial records need separate agreement. This differs from a supported platform's File Upload connection.
Agree the tailored output and acceptance evidence before execution. Target extension development, themes, storefront configuration, payment/shipping setup, vendor onboarding and integration deployment are included only when expressly agreed. Choose Self-Execute or Expert Handle for the tailored Migration Actions as applicable.
How Entity Points Affect CS-Cart Scope Planning
Entity Points size eligible successfully migrated Products, Customers, Orders and Blog Posts under the selected Plan. They do not measure catalog tiles, platform fit or marketplace complexity. A variation Product can remain an individual record even when it shares a visible catalog item.
Estimate which eligible records are required: launch Products, retained Customers, operational or archival Orders and useful Blog Posts. Historical, test, disabled or discontinued records need an explicit scope decision. Use a supported Data Filter when selection is required; entering a smaller capacity count does not filter records.
Eligible records consume points on their first successful transfer and remain counted once within the same purchased migration and applicable actual-store context. Later actions do not make every earlier record newly chargeable. Qualify any store or platform change and purchase implications separately.
A small dataset can need tailored seller handling; a large clean dataset can use standard capability. Revisit capacity when scope changes without confusing that review with the execution-service decision.
What Optional Demo Migration Can Establish
Demo Migration is optional and provides a limited standard sample for the active supported path. It does not run Add-ons or Customization and excludes Reviews and Coupons. A clean retail sample cannot establish untested vendor ownership, financial history, enhanced mapping or target extension behavior.
Use available standard evidence to ask:
- Are Product content, Categories, images, status, stock, Features, Options and variation relationships usable where supported?
- Do available Customer profiles, addresses, groups and Order links preserve intended meaning?
- Can staff explain the included purchased items, payment/shipping/tax references and any supported seller context?
- Are sampled CMS Pages, Blog Posts, metadata and priority routes useful?
- Does a gap require supported configuration, an Add-on, tailored handling or a separate target consumer?
When a requirement is outside Demo, assign its paid-scope or implementation proof explicitly. A passing sample establishes only the records and behavior exercised. Broader execution still needs scope coverage and acceptance.
Using Full Migration and Migration Actions
Before a paid run, agree the supported or tailored scope, Source change window, any pause or final capture, reviewers and protected Target changes. First paid execution uses Perform a New Migration; a Demo is not a paid continuation baseline.
| Migration Action | Use it to decide | Revalidation consequence |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Reuse an accepted configuration for a later paid activity. | Review actual processed records, relationships and continuing consumers. |
| Continue the Migration with a New Configuration | Reopen configuration for changed selections, mappings or other settings. | Recheck changed outputs and their dependencies across earlier and later results. |
| Perform a New Migration | Run the first paid migration or establish a distinct migration result. | Set the appropriate acceptance baseline; do not inherit earlier approval automatically. |
Choose the data-processing window separately. Continue the previous migration is an Additional Option that carries the most recent migration state and processes Source records not transferred in that state, using supported earlier relationships. It is not a creation-date-only rule, general synchronization of edits, Resume Migration or a fourth Migration Action, and it is unavailable in Demo.
An unchanged configuration alone does not establish a new-record-only dataset. A revised configuration does not establish complete updates to earlier stock, vendor assignments or groups. Identify the actual records and relationships affected, then compare the combined result and protected Target edits.
Target clearing is a separate explicit choice; a new action by itself does not authorize deletion. For a change of actual Store, platform or deployment assumptions, confirm eligibility and purchase requirements before relying on the prior setup. The Migration Actions and Additional Options reference owns the operational distinctions.
Conclusion
Choose the CS-Cart approach by supported data meaning, execution responsibility and any approved tailored requirement. Standard Migration supports customer operation; Managed Migration supplies expert execution within standard capability; Custom Migration addresses agreed nonstandard work. Standard Add-ons resolve bounded supported requirements rather than automatically replacing or requiring Custom.
Use optional Demo evidence within its limits, prove enhanced or tailored outputs through the applicable paid scope, and establish working target consumers separately. The CS-Cart validation priorities connect those outputs with the actual buying and marketplace outcomes needed for acceptance.
Common Questions
Can Standard Migration handle a CS-Cart migration?
Yes, when the selected Source-to-CS-Cart path supports the required data and the merchant can configure, run and review it. Confirm Features, Options, variation and seller relationships explicitly. A custom-field or external-key label alone does not determine whether tailored handling is required.
When should I choose Managed Migration for CS-Cart?
Choose it when supported standard capability fits but agreed expert execution is preferable to customer operation. Active trading, volume or limited internal capacity can increase that need. Requirements, business approvals and final verification remain with the merchant.
Can Add-ons replace Custom Migration for a CS-Cart migration?
They can resolve supported filtering, value-processing and compatible mapping requirements, including eligible database routing. Unsupported or bespoke handling still needs Custom Migration. First identify the exact gap rather than selecting a service from the field name.
What should Demo Migration prove for CS-Cart before Full Migration?
Optional Demo provides limited evidence for the available standard sample. It cannot run Add-ons or Customization and excludes Reviews and Coupons. Requirements outside the sample, including unsupported seller finance or target extension behavior, need separate paid or implementation evidence.
What evidence should be prepared for Custom Migration review in a CS-Cart migration?
Provide representative records and relationships, the intended CS-Cart representation, the working consumer and acceptance evidence. Identify the exact handling that exceeds supported migration and Add-ons, plus any separately agreed implementation responsibilities.
Should CS-Cart variation groups be counted by visible catalog items?
No. Variations are Product records whose feature purposes affect visible catalog grouping. Define the actual eligible source records and required target relationships before sizing; storefront tiles are not the Entity Points unit.
Does migrating Multi-Vendor Orders include seller balances and settlement records?
Not automatically. Vendor ownership, Order history, commissions, financial entries and live settlement are distinct requirements. Preserve event and money-direction meaning, qualify unsupported handling through agreed Custom scope, and choose Self-Execute or Expert Handle as applicable. Implementation work is included only when expressly agreed.