An X-Cart preparation package must explain which records are being moved and which installed model gives them meaning. Two catalogs can display similar choices while one stores child variants and another links independent Products. Establish that difference before an export or a destination module is treated as sufficient evidence.
Keep the actual Source and the intended X-Cart Target separate. Versions, editions, upgrades and components can change how similar choices are stored. For a non-X-Cart Source, gather its own equivalent evidence.
Attributes, legacy parent/variant combinations and linked independent Product Variations need different treatment. Memberships, vendors, modules and integrations add further relationships; confirm the model before selecting a target representation.
For each required area, record an action, owner, evidence artifact and readiness condition. Preparation is complete when the input is recoverable, the intended handling is feasible and critical prerequisites are resolved. Produced migration outcomes are tested later. Define the migration scope before treating an available field as a required output.
Record Actual Source Lineage and Access
Gather installed evidence for the actual Source:
- Platform: exact version, edition/package, upgrade history and hosting environment.
- Components: active and historical modules, custom code, themes and storefront or marketplace configuration.
- Connections: actual API generation, where used, and accessible files or exports.
Use X-Cart-specific evidence only for an X-Cart Source. Record the intended X-Cart generation and components separately; native import support does not establish selected-path coverage.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| For an X-Cart Source, identify the exact version and update history; otherwise record actual Source identity and lineage | Technical owner | Actual Source identity/version and available history; X-Cart admin screenshot, package information and upgrade notes where that is the Source | Actual Source generation and known upgrades are recorded; intended X-Cart generation is qualified separately. |
| Inventory active and inactive modules | Store administrator or developer | Actual Source module/component list with author, version, state and purpose where applicable; restricted component evidence and limits otherwise | Required module records, compatible target treatment and an accountable owner are identified; critical gaps are resolved, excluded by agreement or held. |
| Record the actual Source variation model; identify Product Variants or Product Variations usage for an X-Cart Source | Catalog and technical owners | Actual Source component state, representative Products and relevant data locations; X-Cart model-specific evidence only where that is the Source | The actual Source variation or sellable-item model is explicit, without assuming the intended X-Cart model already exists in the Source. |
| Confirm source connection and file access | Hosting or technical owner | Actual Source connection or permitted export status, allowlist/authentication notes where needed, file availability 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. |
| Record theme and custom-code layers | Developer or agency | Actual Source theme, custom module paths, overrides and deployment notes where accessible; otherwise available component/presentation evidence and access limits | Actual Source presentation and custom behavior are distinguishable from records; required inaccessible ownership evidence is resolved, excluded by agreement, or held. |
| Record APIs and synchronizations | Integration owner | API version, credentials owner, webhook or scheduled-job list | External authorities, record keys, update direction and required reconnection responsibilities are documented. |
Use current component and record evidence. For an accessible X-Cart Source, this can include the module list, database, code tree and representative records. A restricted or different Source needs its own permitted retrieval contract and explicit limits.
An old invoice or project document explains history without proving current activation or schema. Name the access owner; API, file and database access are distinct evidence paths.
Preserve Catalog Identity and Attribute Scope
Classify catalog meaning before mapping:
- Attributes: distinguish definitions, assigned values, specifications and buyer inputs. Preserve global, class-level and Product-specific scope; an option can change price or weight without separate stock.
- Legacy variants: preserve the parent, valid combinations and inherited values.
- Linked Product Variations: preserve each independent Product ID and its group relationship.
Keep Product and class identity explicit, then choose the intended destination representation.
Group the catalog evidence by its use:
- Identity and organization: Product ID, SKU, name, status, type where relevant, Categories, Product class, attributes and variant/variation relationships.
- Commerce and assets: prices, stock, weight, images, files and tax classes.
- Ownership and eligibility: memberships, vendor/seller relationships where used, and external identifiers.
For price rules, capture tier owner, quantity thresholds, membership, reference price and minimum quantities. Record whether the actual model uses parent/variant pricing, per-Product tiers or a reusable profile.
| Source pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Class-level attribute | Record class, attribute group, type, allowed values, and assigned Products | Product-class and attribute export | Shared definitions can be separated from Product-specific values. |
| Plain attribute or specification | Record whether the value is descriptive, filterable, or customer-entered | Representative Products and storefront screenshots | Specifications are not mistaken for sellable variations. |
| Selectable variation dimension | Record the active model, defining attributes, real combinations or linked Product groups, and each individual sellable identity | Model-specific manifest with Product/variant IDs, group or parent links, SKU, stock, price, weight, image, and inherited values where applicable | Each sellable combination has a stable identity. |
| Legacy Product Variants module | Record module generation, upgrade status, and variant records | Module evidence and representative Product IDs | Legacy and current variation structures are not mixed silently. |
| Product with files or digital delivery | Record file references and access rules | Product/file list and Order samples | Files and historical purchase relationships are available. |
| Membership- or vendor-restricted Product | Record access or ownership relationship | Membership/vendor matrix | Product visibility or ownership is documented beyond the Product row. |
Preserve evidence before normalization:
- Keep original attribute IDs and values.
- Merge names only when meaning, scope and owning model match.
- Distinguish Product-specific changes from class/global changes that can affect several Products.
- Preserve real combinations and independent grouped Products; matching labels alone do not justify generation or consolidation.
Prepare Categories, Menus and Buyer Rules
Categories, menus, classes, memberships, vendors and presentation can all affect discovery. Preserve Category hierarchy and Product assignments alongside the intended browsing and access rules. A Category assignment alone does not recreate a menu or buyer entitlement.
For memberships, record definitions, Customer assignments and the Product, Category, price or account rules they control. Separate current assignment from a pending request where used, and resolve overlapping source-group precedence. A label alone is insufficient.
For marketplace or multi-vendor scope, record the actual component, seller identifiers, Product/Order relationships and commission or settlement references. Use X-Cart constraints to qualify the applicable buyer and module boundaries.
| Catalog-scope area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Category hierarchy | Catalog owner | Parent-child list and Product assignments | Retained Categories have a clear purpose and parent. |
| Menus and browse paths | Storefront owner | Menu screenshots and destination list | Menu presentation is separated from Category data. |
| Product classes | Catalog architect | Class-to-Product and class-to-attribute map | Shared attribute definitions, assignment scope, and the effect of class-level changes are visible. |
| Membership restrictions | B2B or account owner | Membership-to-Product/Category/price matrix | Access and price effects are explicit. |
| Vendor or seller scope | Marketplace owner | Vendor-to-Product and vendor-to-Order samples | Seller ownership is not flattened into manufacturer or brand fields. |
Prepare Account and Order Evidence
Prepare account evidence by purpose:
- Identity and access: users, Customers, staff, administrators, vendors, account status and roles.
- Buyer context: memberships, profile fields, address books, marketing preferences and external IDs.
Login identity, commercial eligibility and operational permissions need distinct target treatments.
Retain the transaction-time record:
- Items and amounts: descriptions, SKUs, attributes, selected variations, prices, discounts, taxes, shipping and surcharges.
- History and relationships: payment labels, statuses, notes, shipments, refunds, returns, vendor context and external references.
- Module records: additional lines, subscriptions, payment transactions, fulfillment or marketplace settlement details where present.
Identify each owning component before deciding the agreed historical output.
| Record area | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Users and Customers | Classify Customer, administrator, vendor, and other roles | User-role inventory | Accounts are not merged solely because they share one table. |
| Memberships | Record current and historical membership meaning | Membership list and Customer samples | Required current/historical membership meaning, access/pricing rules, compatible target treatment and ownership are documented. |
| Addresses | Separate profile addresses from Order snapshots | Customer and Order address samples | Historical addresses remain interpretable. |
| Order statuses | Record status names, workflow meaning, and module dependencies | Status map and representative Orders | Historical state is understandable without the old admin color or icon. |
| Order items and totals | Include variation values, discounts, taxes, fees, shipping, and module-created lines | Representative Order detail | The transaction can be reconstructed from its historical evidence. |
| External IDs | Record payment, ERP, marketplace, shipment, or accounting keys | Identifier ledger | Required identifiers, their authoritative systems and intended target treatment are documented for later continuity testing. |
Keep original Order names, attributes, prices, addresses, statuses and transaction references in the historical snapshot. Record anomalies and approved dispositions separately.
Prepare account access independently:
- Qualify the exact password-verification path or reset/activation treatment and any external login.
- Record staff/vendor privileges and the destination access owner.
Historical payment and shipment references are separate from live credentials and future actions.
Assign Module and Integration Ownership
Modules can own fields, tables, entities, model behavior, API resources or storefront output. Paths and frameworks can differ across X-Cart generations.
Use the metadata and extension model to connect required business meaning with its component and target consumer. An installed-module list alone cannot establish that contract.
| Module effect | Evidence to prepare | Ready condition |
|---|---|---|
| Product or Customer field | Field key, data type, entity owner, representative IDs | Required values have a feasible compatible destination treatment and owner, or an explicit agreed exclusion; unresolved critical handling is held. |
| Variation or inventory extension | Combination records, stock source, external SKU key | Sellable identity and stock authority are explicit. |
| Subscription, booking, bundle, or service record | Parent Product, Customer, Order, and schedule relationships | Specialized records are not reduced to Product metadata. |
| Marketplace module | Vendor, offer, commission, payout, and Order relationships | Marketplace records are separated from core catalog identity. |
| Payment or fulfillment module | Historical transaction, shipment, or status references | History is separable from future configuration. |
| Custom code or table | Schema, key relationships, active workflow, data owner | The business entity, not only the table, is documented. |
| External PIM, ERP, WMS, CRM, or marketplace | Authority by field and stable IDs | The continuing system of record is named. |
Classify the module’s continuing role:
- Active: retain required behavior or identify its replacement.
- Historical/inactive: preserve needed records from historical-only or inactive modules before exclusion.
- Obsolete: exclude only after confirming that no required meaning depends on it.
A live requirement needs a compatible consumer; an agreed archive needs usable history and traceability. Identify jobs, notifications, stock feeds, payment processes and external writes that must be contained during restoration or testing.
Prepare Content, Files and URL Continuity
Inventory content by its owner:
- Commerce and pages: Product/Category descriptions, CMS or static Pages, and Blog Posts where provided by a module.
- Presentation: menus, banners, labels, translations, theme blocks and module-generated pages.
- Communications: email templates and their consuming setup.
A single CMS export may not include these different assets or recreate their behavior.
Record priority Product, Category, content, membership, vendor and module routes. Capture canonical paths, language/storefront scope, traffic importance, the generating component and intended disposition.
Qualify the actual version: X-Cart 5.6.x uses page-type prefixes and flat Category paths. Older .html addresses need explicit redirect handling; do not assume native redirects cover them. The URL and redirect plan owns the continuity decisions.
Keep two input packages connected:
- Assets: original media/files, record relationships, retrieval access, external storage, generated sizes, missing originals, case-sensitive paths and protection owner.
- Record evidence: actual export/API schema, selected fields and filters, module artifacts and counts.
A Product export alone cannot explain every module history, protected file or external dependency.
Preserve Recoverable Source Inputs
Preserve protected inputs before structural cleanup:
- Accessible X-Cart Source: capture the complete database, relevant application/public files, environment, module manifest and deployment/upgrade notes from the same Store state.
- Other or restricted Source: preserve available dated exports, archives and original assets under their actual recovery contract. Exports alone do not establish a full installation restore.
Name the recovery owner, coverage, limitations and retention period. Verify required retrieval/recovery evidence and track later creations, updates, deletions or schema changes. Resolve required omissions, exclude them explicitly by agreement or hold the affected scope.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database where accessible, or available actual Source archives | Actual Source database administrator or archive/export owner | For an accessible X-Cart Source: timestamped complete dump and restore-readiness note; otherwise dated exports/archives with coverage, limits and recovery owner | Accessible X-Cart core and module tables are complete and from the same Store state. Other or restricted Source recovery coverage and accepted limits are documented; required omissions are resolved, excluded by agreement, or held, without treating exports as a full restore. |
| Application and public files | Technical owner | Actual Source file archive or accessible source tree, original/remote/protected-file inventory and recovery limits | Required original media and protected/downloadable files are available. X-Cart modules, themes and application files are included for that actual accessible Source; required missing files are resolved, excluded by agreement, or held. |
| Environment | Technical owner | Actual Source PHP, database, queue, cache, storage and web-server notes where applicable and accessible; otherwise available provider/export constraints | Actual Source version-sensitive behavior and recovery limits can be interpreted; intended X-Cart runtime and deployment requirements are independent. |
| Module manifest | Developer or Store administrator | Actual Source active/inactive component list and versions where applicable; X-Cart module manifest only for an X-Cart Source | Actual Source component-owned records can be traced; intended X-Cart modules and consumers are qualified separately. |
| Change log | Project owner | Late changes after evidence collection | New Products, modules, or schema changes are visible. |
Resolve X-Cart Target Prerequisites
Qualify the intended X-Cart implementation independently:
- Record generation, edition/package, access roles, runtime/deployment requirements and technical/business owners.
- Confirm compatible enabled modules and record consumers for the agreed scope.
- Resolve the applicable pricing model. In 5.6.0.18 and later, reusable Wholesale profiles and per-Product Custom pricing need distinct treatment; capture profile assignment, enabled state and tier references where used.
Native import support, an installed file or a complete Source backup does not establish migration coverage or destination compatibility.
Use the actual Source model to define intended Product classes, variants or linked variations, memberships, vendors, history, files and custom-data consumers. Preserve identities and relationships when representation changes.
Resolve required access, component or compatibility gaps, agree an explicit exclusion or hold scope before selecting samples. An assigned owner does not supply missing prerequisites.
Choose Representative Commerce Samples
For each sample, preserve original IDs/values, module and external links, media, intended target representation, accepted exclusions and a reviewer. Linked variations need individual IDs and group membership; legacy variants need parent/combination evidence.
The manifest is ready when required dependencies are retrievable and expected meaning is clear. Successful migration is proved during subsequent testing.
Choose cases that exist in the actual Store:
- Catalog models: simple and class-based Products; descriptive attributes, buyer inputs, active variations and any legacy-to-current model transition.
- Buyer or seller rules: membership-restricted or vendor-owned Products; Customers with memberships, multiple addresses, external IDs or vendor roles.
- History: guest and registered Orders with variations, unusual totals, refunds, shipments or module-created records.
- Content and connections: priority Categories, pages, media, routes and any required active custom-module or external-system relationship.
Include price/quantity thresholds and profile-versus-Custom pricing cases where required. Retain both expected and prohibited buyer access so later tests can prove the boundary.
Complete the X-Cart Readiness Gate
| Readiness question | Required outcome |
|---|---|
| Is source lineage known? | Actual Source identity, generation, edition/package context, history, components and environment are recorded where present; intended X-Cart generation is separate. |
| Is catalog meaning complete? | Actual Source item identity, attributes, variations, Categories, memberships, vendors and media are represented where present; Product classes and X-Cart-specific models are required only where they exist. |
| Are accounts and Orders interpretable? | Required roles, memberships, addresses, Order snapshots, statuses and external references have retrievable evidence, feasible agreed handling and owners. |
| Are modules and custom data classified? | Required active/historical module records have evidence and feasible live, replacement, archive or exclusion dispositions; critical gaps are resolved or held. |
| Are content and routes inventoried? | Public paths, module routes, media, and presentation assets are documented. |
| Is actual Source recovery coverage established? | Accessible native X-Cart database/files have same-state recovery evidence. Other or restricted Sources have documented input/archive coverage, recovery limits and owner. Required omissions are resolved, excluded by agreement, or held; exports alone do not establish a full restore. |
| Is the intended X-Cart implementation prepared? | Actual generation/package, access roles, runtime/deployment owner and compatible module/record consumers are confirmed for agreed requirements. Required gaps are resolved, excluded by agreement, or held. |
| Is the sample manifest representative? | The manifest covers required core, complex, legacy, module-owned and external-system cases where present, with retrievable dependencies and expected outcomes. |
Keep open dependencies in a decision register with an owner, due date and scope effect.
Required access, item identity, module schema, account, file, vendor or external-key gaps must be resolved, explicitly excluded by agreement or hold the affected scope. Recording the unknown does not complete preparation. Use X-Cart validation priorities to define the later outcome evidence.
Conclusion
X-Cart preparation depends on source lineage. Identify the models behind three groups:
- Catalog: Product classes, attributes and variants or linked variations.
- Commerce: memberships, vendors and Order extensions.
- Components: platform version, module generation, custom modules and external systems.
Together, they explain which records exist and how they relate.
Use recoverable Source inputs, independent X-Cart prerequisites and a representative manifest to configure the agreed migration. An accessible X-Cart Source needs same-state database/file recovery; another or restricted Source needs its actual archive contract and accepted limits.
Carry unresolved scope forward explicitly. Preparation establishes evidence and feasibility; it does not approve a result that has not yet been produced.
Common Questions
Why must the X-Cart version and module generation be recorded?
X-Cart structures and module implementations have changed across generations. The same storefront concept can be stored through different modules, entities, or APIs, so the live version and module set determine which evidence is authoritative.
Are X-Cart attributes and Product variations the same thing?
No. Attributes can describe Products, collect buyer inputs or help define a variant/variation model. A price or weight modifier alone does not create a separately stocked item.
Capture the actual combination or linked Product identity and its SKU, stock, price, weight and image meaning under the installed model. Preserve the intended buying relationship rather than inferring it from a field label.
What should be prepared for X-Cart memberships?
Record membership definitions, Customer assignments, Product or Category restrictions, price effects, account rules, and representative Orders. A membership label alone does not preserve its commercial or access meaning.
Should inactive X-Cart modules be ignored?
Not automatically. An inactive module can still own historical Order records, Customer fields, or external identifiers. Record whether its data remains required before marking it obsolete.
What belongs in the X-Cart sample manifest?
Include simple and class-based Products, attributes and variations, memberships or vendors where used, complex Orders, important routes, module-owned records, and external-system relationships. Use exact source IDs and related evidence.
Why are both database and file backups required?
The database holds core and module records, while files can contain modules, themes, media, downloadable assets, configuration, and custom code. A complete source package needs both from the same Store state.
This database-and-file package applies to an actual X-Cart Source with the relevant access. Another or restricted Source uses its own permitted 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.
Should linked Product Variations be consolidated into one Product during preparation?
Preserve the original identities first. In the documented Product Variations model, the grouped items remain independent Products with their own properties. Capture each ID and the linking relationship, then decide the intended destination representation.
A legacy Product Variants parent/child export is a different model; do not apply its structure solely because the storefront choices look similar.
Does a successful X-Cart Product export complete the evidence package?
No. Record the installed export schema, selected fields and filters, then account for module data, memberships, historical Orders, files, and external relationships that it does not explain. Each required area needs an accessible artifact and owner.
Native export/import functionality does not prove coverage for the selected migration path.