Choose a Zen Cart migration approach by separating what must move from who will run it. Supported records may fit customer-operated Standard Migration or expert-operated Managed Migration. Eligible Add-ons provide defined controls; identified requirements beyond supported capability need Custom Migration review.
Zen Cart's release, attributes, stock controller, plugins and customizations affect that decision. A selectable attribute, price adjustment and stock combination are different requirements. Native POSM availability does not establish active stock control or Next-Cart coverage for every relationship.
Use the Next-Cart Zen Cart migration page to explore transfer directions, then qualify the exact Source-to-Target path. Keep target installation, templates, modules, hosting and ongoing maintenance explicitly assigned alongside the migration scope.
Establish the Required Data and Behavior
Start with representative records and the outcomes they must support. A small catalog can contain bespoke relationships; a large catalog can use supported standard structures. Record volume alone cannot decide the handling path.
For Zen Cart, establish:
- Catalog meaning: Products, Categories, attributes, required inputs, downloads, price effects and the active stock model.
- Customer and Order meaning: identities, addresses, groups, statuses, method labels and historical total components.
- Content continuity: required pages, metadata, URLs, internal or external links and placement.
- Dependencies: plugin-owned records, custom tables, external identifiers and any target structures that differ from standard assumptions.
For each item, distinguish supported migration, eligible enhancement, tailored handling and separate target implementation. CMS Pages or Blog Posts are candidates only where supported by the selected path; neither label establishes native Zen Cart coverage. The Zen Cart constraints and risks explain why apparently similar fields may need different treatment.
Choose Standard or Managed Execution for Supported Scope
A prepared Zen Cart installation with supported records and compatible relationships can fit standard capability. Typical candidates include ordinary catalog and Category data, customer identity and address records, readable historical Orders and supported content. Attributes still need representative review; a clean-looking catalog is not evidence that every option or stock relationship is covered.
| Service | Suitable operational need | Responsibilities to keep explicit |
|---|---|---|
| Standard Migration | The customer can configure and perform the agreed supported Migration Actions. | Prepare access and the target, supply business meaning, review samples and verify the final result. |
| Managed Migration | The required handling fits supported capability, but the customer wants experts to perform the agreed Migration Actions. | Agree expert execution separately from sample interpretation, target implementation, project coordination and final business approval. |
Review Standard Migration and Managed Migration against those responsibilities. Limited time or migration experience can make expert execution useful; it does not change which records or transformations are supported.
Managed Migration does not replace Custom Migration for unsupported extraction, bespoke relationships or migration logic. Nor does either service automatically prepare hosting, upgrade Zen Cart, rebuild templates, install plugins or configure live payment, shipping and tax behavior. Name the customer, developer or provider responsible for those tasks and for launch approval.
Use Add-ons for Defined Changes Within Supported Capability
Select an Add-on from a specific requirement: a record condition, a supported value change or a compatible destination. Combining supported Add-ons does not itself require Custom Migration, and the presence of a custom field or database column is not an automatic Custom trigger.
When several Add-ons are active, processing follows Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping. Each stage receives the dataset from the preceding stage. Filtering selects records, transformation changes values, and mapping routes source or already transformed values without changing them during mapping.
| Add-on | Requirement it can address | Boundary to verify |
|---|---|---|
| Data Filter | Include or exclude records using supported field conditions for each selected data type. | It does not extract unsupported plugin tables. A condition on one data type is not a blanket filter for all selected types. |
| Data Transformation | Change supported field values through the available transformation controls. | The required operation and field must be supported; bespoke business logic needs tailored review. |
| Advanced Data Mapping | Route a supported source or transformed value to a compatible target field. | The destination must preserve the intended meaning and Value Type; mapping does not create unsupported relationships. |
| Advanced Database Mapping | Route supported data through eligible standard entity tables, fields or columns, including an approved new-column destination where supported. | Zen Cart Target support is only one gate: the exact Source setup, entity, schema location and Value Type must also qualify. |
The Tax data type is outside the Standard scope of both mapping Add-ons. Tax-related fields on another supported data type, such as Orders, are a separate question and require exact field and destination qualification.
Database storage does not recreate attribute selection, stock deduction, plugin workflows or checkout behavior. Identify the target consumer as well as the destination. Use the Add-ons guide for conceptual comparisons and the current Advanced Database Mapping eligibility reference before committing to that route.
Review Custom Migration for the Unsupported Requirement
Custom Migration applies to agreed tailored handling beyond supported capability. Bring a source example, the required target representation and acceptance evidence to the review. A plugin name, old release or external identifier alone does not prove that Custom handling is needed.
Requirements that may need tailored assessment include:
- Extraction and structures: a Custom Platform source, unsupported plugin records, custom tables or modified target structures.
- Catalog interpretation: attributes, bundles, kits, configurable Products or source variants needing bespoke transformation or relationships.
- Commercial history: custom order-total, coupon, gift-certificate, loyalty or subscription records whose required interpretation exceeds supported handling.
- Integrations: ERP, PIM, accounting, warehouse, shipping, marketplace or feed identifiers needing unsupported extraction, relationships or logic.
- Content and URLs: bespoke redirect, metadata or content transformations beyond available controls.
Payment, shipping, tax or other module requirements may contain two tasks: migrating agreed data and implementing current behavior. Resolve them separately. A supported external ID with a compatible destination may fit eligible mapping, while reconnecting the system that consumes it remains an implementation task.
Use a Custom Migration scope review to define the unsupported portion. The agreed Migration Actions can use Self-Execute or Expert Handle. Tailored data handling does not automatically include a store rebuild, module installation, template design or external-system deployment.
Distinguish file Sources from File Upload connections
Selecting CSV, XLS or XML as the Source Platform requires Custom Migration. The included standard file workflow covers Products only; Customers, Orders, CMS Pages or other required data types must be agreed explicitly.
That Source selection differs from a supported platform's File Upload connection method. A Product export alone cannot establish the complete Zen Cart migration scope. Confirm the selected platform and connection model before deciding what the file can prove.
Plan Entity Points Capacity Separately
Entity Points measure eligible migration capacity. They do not select records, filter the dataset or score technical complexity. A smaller project can need tailored work, while a larger supported dataset can remain within standard capability.
Eligible Products, Customers, Orders and Blog Posts consume Entity Points on their first successful migration within the same purchased migration and fixed actual Store path. Previously counted eligible records are counted once in that context; newly successful eligible records can consume additional capacity. Blog Posts remain conditional on path support.
For planning, check:
- the eligible records already counted within the purchased migration;
- the additional supported records expected in the first or a later paid run;
- the remaining capacity, independently of data selection and service scope.
Attribute values, stock combinations, Coupons, gift certificates and module records do not become separate counted data types because they need review. Keep their representation and custom-work effort separate from the Entity Points capacity plan.
Use Demo Findings to Classify the Gap
Demo Migration supplies limited evidence from a representative sample in the active supported path. Use difficult Products and available attribute relationships, downloads, Category placements, customer addresses, historical Orders and content to expose meaningful differences.
Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. A standard sample cannot prove enhanced or tailored output. Gift-certificate records, plugin behavior and every source feature are not assumed covered by the sample either.
| Finding or requirement | Handling decision | Evidence needed |
|---|---|---|
| A supported record was not selected | Correct supported scope or data selection. Investigate unexplained failures and skips separately. | Check the selected representative records and their relationships in the target. |
| Values need different field destinations | Review compatible Advanced Data Mapping or eligible Advanced Database Mapping. | Prove the configured destination and its consumer through the agreed paid scope. |
| Only a defined subset should move | Review Data Filter for supported conditions. | Verify included and excluded examples in the paid result. |
| Supported values need controlled changes | Review Data Transformation. | Compare representative original and changed values in the paid result. |
| Stock, pricing presentation or checkout is wrong | Qualify the target controller, modules, templates and configuration before assuming a data-service change. | Test the actual configured target behavior with its implementation owner. |
| Required plugin tables or relationships are unsupported | Define the extraction and interpretation gap for Custom Migration review. | Agree tailored acceptance evidence and prove the paid output; validate live consumers separately. |
| Historical totals need interpretation | Finance explains the required components. Choose expert execution for supported handling or Custom review for a bespoke gap. | Reconcile representative historical Orders from their retained components. |
| New records accumulated after Demo | Include eligible records in the first paid scope. Plan later Migration Actions only after a paid result exists. | Validate the intended source-data window and the resulting relationships. |
Do not assign every gap to Custom Migration or assume an Add-on can repair unsupported behavior. Record the failed expectation, the responsible handling layer and the next proof. A clean Demo qualifies its tested sample, rather than all untested records or paid-only settings. The current Demo and Full Migration guide owns the operating procedure.
Select Later Migration Actions From the Intended Result
The first paid run uses Perform a New Migration. Demo alone is not a paid result to continue. After an earlier paid migration, decide whether its result and configuration remain useful before choosing the next action.
| Migration Action | Decision it addresses | Zen Cart evidence to revisit |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Reuse the most recent configuration when it remains appropriate. This action does not by itself select only new records. | Affected Products, Customers, Orders, supported content and their earlier relationships. |
| Continue the Migration with a New Configuration | Change supported data selection, mappings, options, applicable Add-ons or approved Customization. | Changed attributes, groups, statuses, content, URLs and any earlier records affected by the revised configuration. |
| Perform a New Migration | Create a fresh result when the earlier result should no longer govern the work. Review the recorded path, store identities and applicable restrictions before proceeding. | Revalidate the complete agreed result, including retained relationships and relevant module or custom-data outcomes. |
Plan later activity against the recorded purchased Source-to-Target path and intended stores. If either platform or actual store changes, confirm eligibility and purchase requirements before proceeding. Do not assume that a new action or configuration removes an existing store-identity restriction.
Separate configuration, source selection and target protection
An action chooses configuration reuse or revision; it does not automatically establish a source-data window or delete existing target data. Check the applicable options independently and protect existing target records before any clearing choice.
The Continue the previous migration Additional Option is separate from the similarly named continuation actions. Current Documentation describes it as carrying the most recent migration state so that records not transferred in that state form the next data delta, with supported relationship context. Do not describe that behavior as a general synchronization of edits to existing records or infer it from the action name.
After any action, validate newly transferred records together with earlier records and relationships affected by the configuration. New plugin extraction or bespoke logic still requires scope review. Use the Migration Actions guide for the conceptual framework and the current Additional Options reference for the state-carrying option.
Conclusion
The right Zen Cart approach combines supported scope, an agreed operator, qualified enhancements and evidence for the required result. Resolve a specific unsupported requirement through Custom Migration review, plan Entity Points as capacity, and keep target implementation owned.
Before Full Migration, record what Demo has proved, what requires paid evidence and which live target checks remain. That decision record makes service selection and later activity accountable to the actual business requirement.
Common Questions
Is Standard Migration enough for Zen Cart?
It can be when the required records and relationships fit supported capability, the target is prepared and the customer can perform the agreed actions. Review any unsupported extraction or bespoke handling separately; a custom field with eligible compatible mapping does not automatically require Custom Migration.
When should Managed Migration be selected for a Zen Cart migration?
Choose it when supported capability fits but expert execution of the agreed Migration Actions is preferred. Business meaning, target setup and final verification still need explicit owners. Unsupported handling requires Custom Migration review rather than an assumption that Managed execution covers it.
Can Add-ons handle Zen Cart plugin data?
Only where the required source values, destinations and relationships fit supported capability. Eligible Add-ons can filter, transform or route those values; they do not recreate plugin behavior. Unsupported extraction or bespoke logic needs tailored review, while installation and live operation remain target responsibilities.
When should Migration Actions be considered for Zen Cart?
Use Perform a New Migration for the first paid run. After a paid result exists, choose configuration reuse, revised configuration or a fresh result according to the intended outcome. Verify the recorded path and intended stores, confirm eligibility for any proposed identity change, review source-window options separately and revalidate affected records and relationships. Demo alone is not a paid continuation baseline.
Does migration include upgrading Zen Cart or rebuilding its plugins and template?
Those tasks are not automatic migration entitlements. Upgrades, plugin replacement, template redevelopment, checkout configuration and external-system implementation need separately agreed responsibilities. Data handling and the live components that consume it each require acceptance evidence.
Do attribute choices prove that variant stock is in migration scope?
No. Selectable values and price effects do not establish combination inventory or transfer support. Qualify the actual release, enabled POSM or other stock controller, source records and supported target relationships. A stored quantity also needs a functioning target consumer.
Can a Product CSV cover the complete Zen Cart migration?
Selecting CSV, XLS or XML as the Source Platform requires Custom Migration with a Products-only included standard workflow. Other required data types must be agreed explicitly. A supported platform’s File Upload connection method is a different setup; it does not inherit that file-Source scope by name.
Does preserving an external identifier always need Custom Migration?
No. A supported value and compatible destination may fit eligible mapping. Escalate extraction, relationships or interpretation that exceeds supported capability. Preserving an identifier and reconnecting its accounting, inventory, shipping or marketplace consumer are separate tasks.