A Zen Cart migration needs evidence for the relationships behind the storefront. An option label can identify a purchase choice, an unpurchasable prompt, or information shown only on the Product page. Preparation should make those meanings, their owners, and their intended destination representations explicit before execution.
Begin with the actual Source and the intended Zen Cart installation as separate evidence sets. A long-running Zen Cart Source can combine Products, linked Categories, attributes, downloads, Customer pricing groups, Order totals, EZ-Pages, define pages, templates, plugins, overrides, language files, and custom fields. For another Source, record its equivalent structures without assuming Zen Cart storage. Destination versions and enabled components determine the intended representation, while migration-path coverage must be confirmed separately.
The preparation objective is to convert that environment into controlled source evidence. Each major area should define the action to complete, the person who owns the answer, the evidence to provide, and the condition that makes the area ready. This allows ordinary records, platform configuration, plugin-owned data, and custom code to be distinguished before migration configuration begins.
Establish Source Access and Record the Zen Cart Environment
For a Zen Cart Source, record the exact version, environment, database, document root, administration access owner, languages, currencies, tax zones, templates, plugins, overrides, and external synchronizations. For another Source, collect equivalent evidence from its own owners. Record the intended Zen Cart build and configuration separately: an included feature, present module file, or older project note does not establish that the required behavior is enabled.
Prepare the source access shown as required for the selected migration path. Database, hosting, admin, or file access should not be presented as interchangeable choices. The technical owner should provide the access that corresponds to the actual installation and remain available when permissions, allowlists, file paths, or database prefixes need clarification. Native Zen Cart database and file evidence applies when that is the actual Source and the required access is available. Another or restricted Source needs its own permitted connection/export contract, file coverage and limits; intended Zen Cart access is separate.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| For a Zen Cart Source, record its exact Zen Cart/PHP environment; otherwise record the actual Source model and environment | Hosting or technical owner | Actual Source identity/version/environment evidence; Zen Cart/PHP/database version screenshots or notes where applicable and accessible, otherwise available provider/export constraints | Actual Source identity and compatibility context are unambiguous; intended Zen Cart build is assessed separately. |
| Confirm source access | Access owner | Actual Source connection or agreed export status, allowlist details where needed, database prefix/file root where accessible, and access restrictions | The required connection reaches the correct actual Source Store, or agreed inputs are available; required restrictions are resolved, excluded by agreement, or held. |
| Inventory actual Source templates, overrides and plugins where present | Developer or agency | Actual Source active template, plugin list, override directories and modified-file record where accessible; otherwise available component/field ownership evidence and restrictions | Actual Source native data and code-dependent behavior can be separated; required inaccessible ownership evidence is resolved, excluded by agreement, or held. |
| Record languages, currencies, tax zones, and units | Commerce owner | Settings evidence and active-language list | Storewide values that affect Product and Order meaning are documented. |
| Identify imports and external synchronizations | Integration owner | Feed schedule, external-system list, last-run details | Values that may change during preparation have a named authority. |
Freeze original IDs, values, and a timestamped source snapshot before approved cleanup. Record later creations, updates, deletions, imports, plugin/schema changes, attribute restructuring, and URL changes. Preserve the original-to-prepared input relationship so similar option labels or historical anomalies are not silently rewritten.
Prepare Products, Attributes, Downloads, and Pricing Relationships
Prepare Option Names, Option Values, and Product assignments separately, including their actual types and flags. READONLY information is distinct from an unpurchasable display-only placeholder and from a real purchase choice. Text/file input belongs to the buyer’s transaction, not automatically to stocked variant identity. For combination stock or dependent options, record the installed POSM or other owner and which Products are configured to use it. Inclusion in a release does not establish activation or per-Product management.
Prepare a Product inventory that includes Product ID, model or SKU, status, price, tax class, quantity, stock behavior, weight, Product type, manufacturer, master Category, linked Categories, images, specials, featured state, quantity discounts, Customer pricing groups, attributes, and download references where used. The evidence should reveal which values identify a sellable choice and which values are only descriptive or customer-entered.
| Source pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Selectable size, color, or format | Record Option Name, Option Value, attribute assignment, type, sort order, default/display-only flags, and required-input state where applicable | Representative Product IDs and attribute export | The choice vocabulary and Product relationship are complete. |
| Price- or weight-changing attribute | Record adjustment, prefix, base-price inclusion, discount treatment, and owning Product | Pricing sample and attribute settings | The commercial effect is explicit rather than inferred from the label. |
| Text or file input | Separate purchase-specific input from reusable option values | Product list and representative Order lines | Buyer-entered data will not be mistaken for a stocked variant. |
| Downloadable Product | Record file, attribute, expiry days, download count, and storage location | Product/file manifest and accessible original files | The Product-to-download relationship and source file are available. |
| Variant-level stock or dependency rule | Identify the installed and enabled owner, configured Products, managed combinations, model/SKU where present, quantity, and dependency rules | Combination table or plugin export | Independent stock and dependency relationships are documented. |
| Customer-group or quantity pricing | Record Product, group, threshold, amount, and dates | Pricing relationship inventory | Conditional prices are not reduced to the base Product price. |
Preserve original option and assignment IDs before business-approved normalization. Similar labels can carry different price, stock, download, or Order meaning. Capture base price and the actual adjustment, prefix, inclusion, and discount flags. Keep attribute price/weight offsets separate from a component that assigns a final combination price or weight; stock management alone does not establish the pricing model.
Document Categories, Linked Products, Manufacturers, and Discovery
Zen Cart Products have a master Category and can also be linked into other Categories. Category hierarchy, linked Product placement, manufacturer browsing, specials, featured Products, new-Product listings, and search can all influence discovery. The preparation record should distinguish catalog classification from template menus and sideboxes.
Prepare the Category tree with IDs, parent relationships, status, language content, images, sort order, Product-type restrictions, and important routes. For each multi-Category Product, record the master Category and linked Categories. A linked placement should not be mistaken for a duplicate Product record.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Category hierarchy | Catalog owner | Parent-child export and retained Category list | Every retained Category has a known parent and purpose. |
| Master and linked Categories | Merchandising owner | Product-to-Category relationships | Shared placement is visible without creating duplicate Products. |
| Manufacturer records | Brand owner | Manufacturer list, Product assignments, public-route notes | Public brand meaning is separated from internal supplier data. |
| Specials, featured, and new listings | Merchandising owner | Active Product lists and date rules | Time- or status-dependent merchandising is identified. |
| Menus and sideboxes | Storefront owner | Screenshots and layout/module notes | Presentation is separated from catalog relationships. |
Prepare Customers, Pricing Groups, Addresses, and Order History
Customer preparation should distinguish account identity, address-book entries, authorization state, newsletter preference, pricing group, wholesale level where used, gift-certificate balance, reviews, and external identifiers. A Customer pricing group can affect commerce behavior and should be documented as a relationship rather than preserved as a label alone.
Prepare historical Orders from the checkout patterns actually used by the Source, including guest checkout only where its owning implementation exists. Include registered identity, attributes, downloads, discounts, coupons or gift certificates, taxes, shipping/payment labels, comments, status history, differing addresses, and plugin-generated totals. Preserve Order-time addresses and descriptions separately from current account/catalog data. Historical payment, status, and download records need their own intended retention decisions; they do not authorize future actions.
| Record area | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Customer identity | Identify duplicates, authorization states, pricing groups, and external keys | Customer exception list | Identity exceptions have an owner and disposition. |
| Address books | Separate reusable Customer addresses from Order snapshots | Customer and Order address examples | Current account data and transaction history are not conflated. |
| Pricing or wholesale groups | Record membership and every Product or price relationship it affects | Group-to-rule matrix | Commercial meaning is documented beyond the group name. |
| Order statuses and comments | Record labels, sequence, customer visibility, and representative Orders | Status inventory | Historical states can be interpreted without relying on label alone. |
| Order totals | Identify subtotal, tax, shipping, discount, gift certificate, fee, and plugin lines | Representative total sets | Every material adjustment has a known source owner. |
| Download history | Record purchased file attributes, remaining access, and Order relationship | Download-related Orders | Digital purchase context is included in the source evidence. |
Keep historical anomalies in the original snapshot and document approved dispositions separately. Prepare account identity, authorization and pricing relationships alongside the supported password-verification or reset/activation/first-login path. Name any external authentication owner. Customer profile continuity does not itself establish usable login credentials or continuing wholesale privileges.
Inventory Plugins, Overrides, Templates, and Custom Data
Zen Cart plugins can add fields, tables, pricing rules, stock logic, Order totals, SEO routes, Customer properties, reports, feeds, or integrations. Overrides and direct modifications can also change behavior without creating an obvious plugin record. Preparation must identify what business data each component owns.
Record each plugin or module’s version, purpose, active state, owned records, database additions, overrides or modified files, external services, and business owner. Identify inactive components with retained history as well as required current dependencies. A retained record needs an intended schema and consumer; a copied file or installed module does not establish eligibility for every Order. Prepare containment owners for test notifications, payment/shipping processes, feeds, and external writes.
| Dependency effect | Evidence to prepare | Ready condition |
|---|---|---|
| Attribute or variant-stock extension | Combination records, Product keys, SKU and quantity fields | Each active combination has a defined source owner. |
| Order-total or checkout module | Configuration summary and representative historical Orders | Historical values are separable from current Store configuration. |
| SEO or URL plugin | Rewrite settings, route examples, and redirect tables | Important source paths can be reconstructed. |
| Customer or loyalty extension | Fields, balances, transaction history, and Customer keys | Active account data has an explicit destination decision. |
| ERP, marketplace, or fulfillment integration | External IDs, direction of synchronization, and authority | Continuing systems can identify the same Product, Customer, or Order. |
| Template-dependent content | Template paths, screenshots, and content source | Business content is separated from presentation code. |
Prepare EZ-Pages, Define Pages, Media, and URL Evidence
Inventory content by its actual owner: EZ-Pages, define pages, descriptions, banners, sideboxes, templates, and language files. For an EZ-Page, record HTML content, internal/external link values, language, placement, and the route actually followed. Content takes precedence over link values, and an external link takes precedence over an internal link. Preserve that meaning rather than treating every EZ-Page as an ordinary content page.
Record priority Product, Category, manufacturer, EZ-Page, policy, contact, and informational URLs. Native Product and Category paths can use IDs and Category paths, while SEO plugins may replace them with rewritten routes. The route inventory should therefore identify whether each important path is native, plugin-generated, static, or externally redirected.
Back up original images and download files with their paths. The database can contain filenames without containing the files. Flag missing files, external image URLs, case-sensitive path differences, and generated thumbnails that are not source originals.
Create the Zen Cart Source Recovery and Input Package
Preserve a protected recovery and input package before structural cleanup. For an accessible Zen Cart Source, include the complete database, relevant file tree, downloads, configuration references, template/plugin evidence, and environment tied to the same Store state. For another or restricted Source, preserve its available dated exports, archives and original media with actual recovery coverage, limitations and owner; exports alone do not establish a full installation restore. Record snapshot time, retrieval location, access owner, recovery responsibility, and retention. Database filenames are not substitutes for accessible originals. Resolve required omissions, exclude them explicitly by agreement, or hold the affected scope.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup where accessible, or available actual Source archives | Actual Source database administrator or archive/export owner | For an accessible Zen Cart Source: timestamped complete dump, database-prefix note and recovery evidence; otherwise dated exports/archives with coverage, limitations and recovery owner | An accessible native dump is complete and belongs to the correct Store/state. Other or restricted Source coverage and accepted recovery limits are documented; required omissions are resolved, excluded by agreement, or held, without treating exports as a full restore. |
| Files and downloads | Hosting or technical owner | Actual Source file archive or accessible source tree, original/remote-media inventory and recovery limits | Required original images and downloads are available. Zen Cart templates, overrides and plugins are included for that actual accessible Source; required missing files are resolved, excluded by agreement, or held. |
| Environment record | Technical owner | Actual Source environment evidence; PHP/database/server/Zen Cart version notes where applicable and accessible, otherwise available provider/export constraints | Actual Source version-dependent behavior and recovery limits can be interpreted; intended Zen Cart runtime and deployment are assessed independently. |
| Access register | Project owner | Actual Source access/export owner, connection or agreed input status, and restrictions | Required actual Source access or agreed inputs are available without exposing credentials in planning documents; required unresolved restrictions hold the affected scope. |
| Change log | Store administrator | Changes after the evidence cut-off | Late structural changes can be incorporated deliberately. |
Confirm the Intended Zen Cart Build and Enabled Owners
Prepare the intended Zen Cart build, runtime/deployment owner, languages and Store configuration, access roles, and compatible plugins or custom components independently from the Source archive. Record which required behavior is enabled and which Products or records use it; an available component or copied file does not establish configuration or selected migration-path coverage.
Use the actual Source evidence to confirm ownership for purchase choices, managed option stock or dependencies, price/weight effects, Category placement, account pricing, historical downloads and content/routes. Keep the intended stock owner separate from the component interpreting price or weight, and distinguish EZ-Page content from link destinations where relevant. Required compatibility or consumer gaps need resolution, an explicit agreed exclusion, or a hold before samples are selected.
Select Representative Migration Test Samples
Prepare samples with original IDs and values, business reason, related files, option/plugin dependencies, intended destination representation, accepted exclusions, and reviewer. Include ordinary records and relationships that the actual Source uses, such as linked Category placement or managed option combinations. A sample is ready when its evidence can be retrieved and its intended meaning explained; preparation does not establish successful execution.
Include at least:
- a simple Product, an inactive Product, and a linked multi-Category Product;
- an attribute-heavy Product with price or weight effects;
- text or file input, variant-stock, or dependent attributes where used;
- a downloadable Product with source file and purchase history;
- Products with specials, quantity pricing, or Customer-group pricing;
- Customers from meaningful pricing or authorization groups;
- Orders with attributes, comments, different addresses, gift certificates, unusual totals, and downloads;
- priority native and rewritten URLs;
- one active plugin-owned record and one template-dependent content example.
Apply the Final Zen Cart Readiness Gate
Zen Cart is ready for the next migration step when the source can be explained without undocumented assumptions.
| Readiness question | Required outcome |
|---|---|
| Are the actual Source and intended Zen Cart environments identified? | Actual Source identity, environment and scope are recorded. Zen Cart version, hosting, database, languages, templates, overrides and plugins apply where that is the Source; destination build and configuration are separate. |
| Are Product relationships complete? | Actual Source attributes or purchase choices, downloads, Categories, pricing, media and stock owners are represented where present; Zen Cart-specific structures are required only where they exist. |
| Are Customers and Orders interpretable? | Groups, addresses, statuses, totals, comments, and external IDs have owners. |
| Are plugins and custom data classified? | Every active dependency has a business purpose and destination decision. |
| Are content and routes inventoried? | Actual Source content, media and important native/rewritten URLs are documented; EZ-Pages and define pages are identified where present, with intended destination owners. |
| Are backups and access ready? | Actual Source access or agreed inputs are available. Accessible native Zen Cart database/files have same-state recovery evidence; other or restricted Source archives have documented coverage, limits and owner. Required omissions are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
| Is the intended Zen Cart implementation prepared? | Actual build/configuration, access roles, runtime/deployment owner and compatible enabled stock, pricing, account, content and other required consumers are confirmed. Required gaps are resolved, excluded by agreement, or held. |
| Is the sample set representative? | Ordinary and complex records are listed with source IDs and expected relationships. |
Assign unresolved items an owner, due date, and scope consequence. Required access, file, option-stock, Category-link, pricing, account, custom-table, or external-key gaps must be resolved, explicitly excluded with approval, or hold the affected scope. Unknown dependencies are not ready merely because they appear in a decision log.
Conclusion
Zen Cart preparation is strongest when the Store is treated as a connected catalog and historical record rather than a flat Product export. Attributes, downloads, linked Categories, Customer pricing groups, Order totals, EZ-Pages, plugins, overrides, templates, and original files each need a clear owner and evidence set.
A Source package with documented recovery coverage and limits, independent Zen Cart implementation prerequisites, a representative sample manifest, and an explicit readiness gate provides the foundation for migration configuration. Full database-and-file recovery remains required for an accessible native Zen Cart Source; another or restricted Source uses its actual archive contract and accepted limitations. Carry any held scope into the next decision.
Common Questions
Why must Zen Cart attributes be prepared separately from Product fields?
Attributes connect Option Names and Option Values to Products and can affect price, weight, required selection, buyer input, downloads, or stock. A flat Product row cannot preserve those relationships reliably.
What is the difference between a master Category and a linked Category?
A Product has a master Category and can be linked into additional Categories. Record both relationships so additional placement is not mistaken for a duplicate Product or lost during catalog preparation.
Does a Zen Cart database backup include images and downloadable files?
No. The database normally stores references. Original images, downloads, templates, overrides, and plugin files must be prepared from the file system as well. That native database-and-file package applies to an actual Zen Cart Source with the relevant access. Another or restricted Source needs its own available inputs, archives and original media, with recovery coverage, limitations and owner recorded. Exports alone do not establish a full installation restore; required gaps need resolution, an agreed exclusion, or a hold.
How should Zen Cart plugin data be documented?
Record the plugin, version, affected entities, fields or tables, representative source IDs, external dependencies, and continuing business purpose. Active data needs an explicit owner; obsolete records can be marked for archive or exclusion.
Which Orders should be included in the source sample set?
Include ordinary Orders and Orders with attributes, discounts, gift certificates, different billing and shipping addresses, comments, unusual totals, downloads, and external references. These expose the relationships that basic Orders do not.
Should rewritten Zen Cart URLs be treated as native Product URLs?
Not automatically. Record whether each important route is native, generated by an SEO plugin, static, or externally redirected. That ownership determines the evidence needed to reproduce the path relationship.
Are READONLY attributes and display-only option prompts the same thing?
No. READONLY attributes provide information and are not purchase calculations or Order selections. A display-only assignment can instead be an unpurchasable prompt that requires the buyer to choose another value. Preserve the Option Name type and Product-assignment flags so the intended destination does not treat either as an ordinary sellable choice.
Does having POSM available mean every Product has separate option stock?
No. Prepare evidence that the component is installed and enabled, the Product is managed, and its actual combinations and quantities are recorded. Capture model/SKU values where present and configured dependency rules. Determine price and weight ownership separately; combination-stock support alone does not prove final combination pricing.
How should an EZ-Page with content and link fields be prepared?
Record all values and the route they actually produce. HTML content takes precedence over internal or external links, while an external link takes precedence over an internal one. Even unintended content can change the result. Decide whether the destination needs a content page, a navigation link, or another route while preserving the original evidence.