Zen Cart preparation should make the actual source Store understandable before migration configuration is finalized. A long-running installation may combine native Products, linked Categories, attributes, downloads, Customer pricing groups, Order totals, EZ-Pages, define pages, templates, plugins, overrides, language files, and custom database fields. The storefront can look coherent while the records that support it are distributed across several technical and business owners.
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
Begin by identifying the exact installation. Record the Zen Cart version, hosting environment, database, document root, admin path, active language packs, currencies, tax zones, templates, plugins, overrides, and external synchronizations. The same visible Store can behave differently when one installation uses current native functionality and another depends on older plugins or direct file modifications.
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.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Record the exact Zen Cart and PHP environment | Hosting or technical owner | Version screenshots, environment note, database version | The source installation and compatibility context are unambiguous. |
| Confirm source access | Access owner | Connection status, allowlist details, database prefix, file-root note | The required source connection reaches the correct Store. |
| Inventory templates, overrides, and plugins | Developer or agency | Active template, plugin list, override directories, modified-file record | Native data and code-dependent behavior can be separated. |
| 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. |
Create a change log once this evidence is captured. Routine trading can continue, but new plugins, database changes, major attribute restructuring, or URL changes should be recorded so the prepared source model does not silently become stale.
Prepare Products, Attributes, Downloads, and Pricing Relationships
Zen Cart uses Product attributes to represent selectable values, customer-entered text, file uploads, read-only information, price or weight adjustments, and downloadable files. Option Names, Option Values, and the attribute assignment to a Product are separate records. Some installations also use variant-stock or dependent-attribute functionality, whether native to the current version or supplied by a plugin.
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, sort order, and required/default state | 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 native or plugin owner, combinations, SKU, and quantity | 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. |
Do not normalize attribute labels or merge option values without business approval. Similar names can carry different price, stock, download, or Order-line meaning.
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.
Order preparation should preserve historical evidence. Select Orders that represent guest and registered checkout, attributes, downloads, discounts, coupons or gift certificates, taxes, shipping and payment labels, comments, status history, different billing and shipping addresses, and plugin-generated Order totals. Keep Order-time addresses and Product descriptions distinct from current Customer and catalog records.
| 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. |
Historical records should not be edited merely to make them uniform. Document anomalies separately when they explain the original transaction.
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.
Create a dependency ledger with plugin name, version, purpose, active status, affected entities, database additions, modified or overridden files, external systems, and the person who can confirm whether the behavior remains required. Use “Zen Cart plugin” or the specific component name so platform extensions are not confused with migration-service enhancements.
| 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
Zen Cart content can appear through EZ-Pages, define pages, Product and Category descriptions, banners, sideboxes, template files, and language files. Prepare an inventory that names the content owner, language, current route, menu or sidebox placement, embedded links, images, and intended disposition.
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 a Restorable Zen Cart Source Package
Preserve a recoverable Zen Cart source state before structural cleanup or migration execution. The package should include the database, relevant file tree, download directory, configuration references, template and plugin evidence, and an environment note tied to the same Store state.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup | Database administrator | Timestamped dump and database-prefix note | The dump is complete and belongs to the intended Store. |
| Files and downloads | Hosting or technical owner | File archive or accessible source tree | Original images, downloads, templates, overrides, and plugins are available. |
| Environment record | Technical owner | PHP, database, server, and Zen Cart version note | Version-dependent behavior can be interpreted. |
| Access register | Project owner | Access owner and connection status | Required access is available without exposing credentials in documentation. |
| Change log | Store administrator | Changes after the evidence cut-off | Late structural changes can be incorporated deliberately. |
Select Representative Migration Test Samples
Prepare a compact sample manifest with source IDs, business reason, linked files, and expected source relationships. It should include both ordinary records and the relationships most likely to be misunderstood. The Zen Cart sample manifest is ready when every source expectation, plugin or attribute dependency, linked file, and identifier is complete and assigned to a reviewer.
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 |
|---|---|
| Is the exact installation known? | Version, hosting, database, languages, template, overrides, and plugins are recorded. |
| Are Product relationships complete? | Attributes, downloads, Categories, pricing, media, and stock extensions are represented. |
| 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? | EZ-Pages, define pages, media, and important native or rewritten URLs are documented. |
| Are backups and access ready? | The source package is restorable and required access is available. |
| Is the sample set representative? | Ordinary and complex records are listed with source IDs and expected relationships. |
Unresolved items belong in a decision log with an owner and due date. Preparation is incomplete when a critical plugin table, download file, Category link, pricing relationship, or external identifier is still described only as unknown.
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 restorable source package, representative sample manifest, and explicit readiness gate provide the foundation for migration configuration.
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.
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.