Prepare a Zen Cart migration by making the source relationships explainable before configuration begins. A label may represent a buying choice, buyer input or information displayed on a Product page. The preparation record must identify its meaning, owner and intended target representation.
Keep the actual Source and the intended Zen Cart installation separate. Another platform does not need to use Zen Cart tables or files to supply useful evidence. Equally, native Zen Cart features do not establish that the chosen migration path supports every required field or relationship.
The checklist should produce:
- a source inventory tied to original IDs and a dated snapshot;
- recoverable inputs with documented access and coverage limits;
- named owners for the required Zen Cart configuration and consumers;
- representative samples and a decision on every required gap.
Use the Zen Cart migration overview to explore transfer directions. The Zen Cart constraints and risks explain why the evidence below matters.
Identify the Source, Target and Access Owners
Record the actual Source platform, version and operating constraints. Where Zen Cart is the Source, include its PHP/database environment, document root, database prefix, administration owner, active template, overrides and plugins. Where another platform is the Source, collect its equivalent evidence and identify anything unavailable.
| Area | Owner and evidence | Ready condition |
|---|---|---|
| Actual Source access | Access owner: the connection or agreed exports required by the selected path, plus permissions, allowlists, accessible roots/prefixes and restrictions. | The connection reaches the intended Source, or agreed inputs are available. Required restrictions are resolved, excluded by agreement or held. |
| Source environment and dependencies | Technical owner or agency: actual version, active components, modified-file record and provider/export limitations. Commerce and integration owners: languages, currencies, tax zones, units, feeds and synchronization schedules. | The team can distinguish native records, code-dependent behavior and values controlled by an external system. |
| Intended Zen Cart installation | Target technical owner: selected release, runtime, deployment, access roles, languages, configuration and compatible components. | Target prerequisites are assessed independently of the Source archive; a present module file is not treated as enabled behavior. |
Database, hosting, admin and file access are different requirements, rather than interchangeable ways to reach the same evidence. Record the required access owner without putting credentials in planning documents.
Before approved cleanup, preserve original IDs, values and a timestamped snapshot. Log later creations, updates, deletions, imports, plugin or schema changes, attribute restructuring and URL changes. Keep the relationship between original and prepared inputs so anomalies or similar labels are not silently normalized.
Prepare Product, Attribute, Stock and Pricing Evidence
For a Zen Cart Source, capture Product ID, model/SKU, status, Product type, base price, tax class, quantity, stock behavior, weight, manufacturer, master and linked Categories, images, specials, featured state, quantity discounts, group pricing and download references where used. For another Source, capture the corresponding business facts under its own data model.
Prepare Option Names, Option Values and Product assignments separately. Keep their actual types, sort order, defaults, display-only flags and required-input settings. READONLY information is not a purchase selection; an unpurchasable placeholder on a selectable option has a different purpose.
| Source pattern | Evidence and responsible owner | Ready condition |
|---|---|---|
| Selectable size, color or format | Catalog owner: original option/assignment IDs, types, values, order, default and applicable input flags. | Choices retain their vocabulary and Product relationship; prompts and information remain distinguishable. |
| Price or weight effect | Pricing owner: adjustment, prefix, base-price inclusion, discount flags and owning Product. | The commercial effect is explicit, including any separately implemented final combination price or weight. |
| Text or file input | Catalog and fulfillment owners: Product examples and representative Order lines containing purchase-specific input. | Buyer-entered information is separated from reusable option values and stocked identity. |
| Download association | Digital-delivery owner: Product, attribute, original or remote file, storage location, expiry days and download-count settings. | The association and required file are available, with the intended delivery and access requirements recorded. |
| Combination stock or dependent choices | Inventory/application owner: installed and enabled POSM or other implementation, managed Products, combination quantities, model/SKU where present and dependency rules. | The actual stock/dependency owner and configured records are known; component availability alone does not establish management. |
| Group, wholesale or quantity pricing | Pricing owner: membership, Product relationships, thresholds, amounts, applicable dates and active pricing mechanisms. | Conditional amounts can be explained beyond the base Product price or group label. |
Similar option labels can carry different stock, price, download or historical meaning. Preserve their original identities before business-approved changes. Keep attribute price/weight adjustments separate from any component that assigns a final combination price or weight; stock management alone does not establish that pricing model.
Document Category Placement and Product Discovery
A Zen Cart Product has a master Category and can be linked into additional Categories. Linked placement retains one Product identity; a duplicate is a separate record. Catalog preparation should preserve the intended relationship rather than count every placement as another Product.
Prepare these independent evidence sets:
- Category hierarchy: the catalog owner records retained IDs, parents, purpose, status, language content, images, sort order, applicable Product-type restrictions and important routes.
- Master and linked placement: merchandising records every intended Product-to-Category relationship, including secondary placement.
- Manufacturers: the brand owner records assignments and public routes, separating public manufacturer meaning from internal supplier information.
- Merchandising lists: merchandising records specials, featured and new listings, including applicable status and date rules.
- Menus and sideboxes: the storefront owner supplies layout evidence and screenshots so presentation is distinguished from catalog relationships.
The area is ready when retained Categories have known parents and purpose, intended placements are explicit, and the team knows which discovery paths depend on target presentation.
Prepare Accounts and Historical Orders Separately
Account evidence should distinguish identity, address books, authorization, newsletter preference, pricing groups, wholesale level where used, gift-certificate balances, Reviews and external keys. Do not assume a group label preserves the commercial privileges it once controlled.
| Record area | Evidence to provide | Ready condition |
|---|---|---|
| Customer identity and access | Customer owner: duplicates, authorization exceptions, external keys, pricing membership and the intended login or reset/activation journey. | Identity exceptions and access decisions have owners; profile continuity is not mistaken for usable credentials. |
| Addresses | Customer and operations owners: reusable address-book entries and separate Order-time billing/shipping examples. | Current account details and transaction snapshots remain distinguishable. |
| Pricing and wholesale relationships | Pricing owner: group/level membership and the Product or price rules it affects. | Required commercial meaning is documented beyond names. |
| Order lines, statuses and comments | Operations owner: items, attributes, purchase-time descriptions, labels, sequence, customer visibility and representative histories. | Staff can explain the purchased item and lifecycle without replacing history with current catalog/account values. |
| Order totals and digital history | Finance and digital-delivery owners: subtotal, tax, shipping, discounts, coupons, gift certificates, fees, plugin lines, purchased files, remaining access and Order links. | Every material adjustment and retained download relationship has an owner and intended treatment. |
Include the checkout patterns the Source actually used, including guest checkout only where an identified implementation supplied it. Historical payment, status and download records require retention decisions; they do not authorize future payments, fulfillment or downloads.
Keep historical anomalies in the original snapshot and record approved treatment separately. Confirm the supported password-verification or reset/activation/first-login path and any external authentication owner. A migrated Customer profile does not establish continuing login or wholesale privileges.
Inventory Plugins, Overrides and External Consumers
For each component, record version, purpose, active state, owned records, database additions, overrides or direct edits, external services and business owner. Include inactive components that retain required history. A component name or copied file does not establish that it can interpret every retained record.
Use these checks to assign continuing consumers:
- Attribute or stock extension: preserve combination records, Product keys, SKU/quantity fields and the active stock owner.
- Checkout or order-total module: preserve configuration context and historical examples separately from future transaction rules.
- SEO or URL plugin: capture rewrite settings, route examples and redirect tables so important paths can be explained.
- Customer or loyalty extension: identify fields, balances, transaction histories and Customer keys, with an explicit destination decision.
- ERP, marketplace or fulfillment integration: identify external IDs, synchronization direction and the system authorized to change each value.
- Template-dependent content: record paths, screenshots and content sources so business content is separated from presentation code.
Assign containment owners for test notifications, payment and shipping processes, feeds and external writes. A required schema or consumer gap needs resolution, an agreed exclusion or a hold. Unsupported extraction or bespoke relationships can be taken to a Custom Migration scope review; implementation of the target consumer remains separately assigned.
Prepare Content, Media and URL Evidence
Classify content by its actual owner: EZ-Pages, define pages, Product/Category descriptions, banners, sideboxes, templates, language files or the equivalent Source structure.
For an EZ-Page, record HTML content, internal/external link fields, language, visibility, placement and the route actually followed. HTML content takes precedence over links; an external link takes precedence over an internal one. Even unintended editor content can change the result. Decide whether the target needs a content page, a storefront link or another route.
Prepare three inventories:
- Priority destinations: Product, Category, manufacturer, policy, contact, help and other important content URLs, including EZ-Pages where present.
- Route ownership: native ID/Category-path routes, SEO-plugin rewrites, static paths and external redirects, with intended target treatment.
- Original media: image and download locations, accessible originals or approved remote sources, missing files, filename-case differences and generated thumbnails that are not source originals.
Database references are not substitutes for accessible files. Preserve original paths and record any unresolved coverage limit before the scope is treated as ready.
Protect Recovery Inputs Before Cleanup
When the actual Source is an accessible Zen Cart store
Preserve the complete database and site files, including required downloads, templates, overrides, plugins and configuration references. Tie the package to the same store state and record the database prefix and source environment. A database-only backup does not contain the separate file tree or establish a full installation restore.
The database administrator and technical owner should supply recovery evidence for the package, rather than relying on filenames or a statement that a backup exists.
When the Source is another platform or access is restricted
Preserve the dated exports, archives and original media actually available. The export/archive owner should state coverage, limitations and recovery responsibility. Do not present those inputs as a complete Zen Cart installation backup or a full restore of an inaccessible Source.
For either case, record:
- snapshot time, retrieval location, retention and the person responsible for recovery;
- available inputs, required access and any unresolved omissions;
- changes after the evidence cut-off and their relationship to prepared inputs.
Resolve required missing files or records, explicitly exclude them by agreement, or hold the affected scope. A documented limitation is useful evidence, but it is not permission to ignore a required omission.
Confirm the Intended Zen Cart Build and Owners
Before selecting migration samples, confirm the selected release, compatible runtime and deployment, languages, configuration, access roles and required plugins or custom components. Record which behavior is enabled and which Products or records use it.
Assign owners for three separate concerns:
- Commercial interpretation: purchase choices, price/weight effects, account pricing, Category placement and historical download context.
- Configured consumers: stock control, dependent choices, content/link handling, templates, checkout and other required live behavior.
- Migration execution: the person operating the agreed transfer, distinct from target development and ongoing maintenance.
Where Managed Migration is agreed, record the expert execution tasks without assuming that target implementation is included. Use the Zen Cart migration approach guide for the service decision. Required compatibility or consumer gaps still need resolution, an approved exclusion or a hold.
Select Samples With Explainable Expected Results
For each sample, record original IDs and values, business reason, related files, option/plugin dependencies, intended target representation, accepted exclusions and reviewer. Choose cases the actual Source uses; record nonapplicable cases explicitly instead of inventing them.
The sample set should cover:
- ordinary, inactive and multi-Category Products, including linked identity where present;
- attribute-heavy choices, required input, price/weight effects, managed combination stock and dependencies where used;
- downloadable Products with original files and purchase history;
- specials, quantity/group/wholesale pricing and meaningful Customer authorization or pricing groups;
- Orders with attributes, comments, different addresses, coupons/gift certificates, unusual totals and downloads;
- priority native/rewritten URLs, active plugin data and template-dependent content.
A sample is ready when its evidence can be retrieved and its intended meaning explained. That is preparation evidence, not proof that migration or target operation has succeeded. Plan the later checks through Zen Cart validation priorities.
Apply the Final Readiness Gate
| Readiness area | Required evidence before proceeding |
|---|---|
| Source and target identity | The actual Source model, environment and constraints are clear; intended Zen Cart prerequisites are recorded independently. |
| Product relationships | Required choices, attributes, downloads, Categories, pricing, media and stock owners are represented under the actual Source model. |
| Customers and Orders | Groups, addresses, statuses, comments, totals, digital history and external keys have interpretable evidence and owners. |
| Plugins and custom data | Each active dependency has a business purpose, intended schema/consumer and destination decision. |
| Content and routes | Priority content, original media and native/rewritten paths have intended target owners and treatment. |
| Recovery and access | Required connection or agreed inputs are available. Native Zen Cart database/files have same-state recovery evidence; other or restricted Source limits are explicit. |
| Zen Cart implementation | The selected build, access roles, runtime/deployment owner and required compatible, enabled consumers are confirmed. |
| Representative samples | Ordinary and difficult records have source IDs, expected relationships, exclusions where approved and named reviewers. |
Give unresolved items an owner, due date and scope consequence. Required access, file, stock, Category-link, pricing, account, custom-table or external-key gaps must be resolved, explicitly excluded with approval or hold the affected scope. An unknown dependency is not ready merely because it appears in a log.
Conclusion
Zen Cart preparation should leave the next operator with explainable records, usable inputs, assigned target consumers and representative samples. Keep the actual Source recovery contract distinct from the intended Zen Cart build.
Proceed only with required gaps resolved or explicitly handled. Carry every held item into migration configuration and the later validation plan, with its owner and scope consequence intact.
Common Questions
Why must Zen Cart attributes be prepared separately from Product fields?
Option Names, Option Values and Product assignments carry different roles and flags. Prepare choices, buyer input, price/weight effects and downloads with their relationships. Qualify the stock owner separately; a flat Product row does not explain these distinctions.
What is the difference between a master Category and a linked Category?
A Product has a master Category and can appear in additional Categories through links to the same identity. Record all intended placements so they are not lost or mistaken for duplicate Products.
Does a Zen Cart database backup include images and downloadable files?
The database normally holds references rather than the separate files. An accessible native Zen Cart Source needs its database and site files, including required original images, downloads and implementation files. Another or restricted Source needs its own available inputs and recovery contract, with limitations and an owner. Required gaps need resolution, an agreed exclusion or a hold; exports alone do not establish a full restore.
How should Zen Cart plugin data be documented?
Record the plugin and version, affected entities/fields/tables, original IDs, active state, external dependencies and continuing business purpose. Identify the target schema and consumer. Retained active data needs an owner; obsolete data can be archived or excluded through an explicit decision.
Which Orders should be included in the source sample set?
Choose ordinary Orders and relevant exceptions from the actual Source: attributes, discounts, coupons/gift certificates, different addresses, comments, unusual totals, downloads and external references. Preserve purchase-time values so the intended history can be explained.
Should rewritten Zen Cart URLs be treated as native Product URLs?
Identify their owner first. A route may be native, generated by an SEO plugin, static or externally redirected. Record its actual destination and intended target treatment rather than assuming the same structure will exist.
Are READONLY attributes and display-only option prompts the same thing?
No. READONLY supplies information without becoming a cart or Order selection. A display-only assignment on a selectable option can prompt a valid choice and remain unpurchasable itself. Preserve the Option Name type and assignment flags so neither is treated as an ordinary sellable choice.
Does having POSM available mean every Product has separate option stock?
No. Record activation, Product management, actual combinations, quantities, model/SKU values where present and configured dependencies. Keep price/weight ownership separate; stock support does not establish a final combination-pricing model.
How should an EZ-Page with content and link fields be prepared?
Preserve all values and the route they produce. HTML content precedes link fields, and an external link precedes an internal one. Even unintended content can change the result. Record whether the target needs a page, a storefront link or another route, with language and placement requirements.