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.
Record the actual Source generation and components separately from the intended X-Cart destination. X-Cart Stores can differ across versions, editions, upgrades, and module generations. Attributes can be specifications, customer-selectable values, or variation dimensions. In the documented Product Variations model, linked variations remain independent Products; the legacy Product Variants model has a different parent/combinations structure. Memberships, vendor records, custom modules, and integrations add their own relationships. For a non-X-Cart Source, capture its equivalent evidence without assuming that it already follows either model.
The preparation goal is to describe the actual Store, not an assumed generic X-Cart schema. Each readiness area should identify an action, owner, evidence artifact, and ready condition. This creates a controlled basis for migration configuration.
Establish X-Cart Version, Edition, Access, and Module Lineage
For an X-Cart Source, record its exact version, edition or package context, upgrade history, active and historical modules, custom code, theme, storefront or marketplace configuration, API generation where used, and hosting environment. Capture equivalent installed evidence for another Source. Record the intended X-Cart generation and required components separately: destination availability and native import support do not establish the selected migration path’s 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 | Every business-critical module has an owner. |
| 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 systems and their record keys are known. |
For an accessible X-Cart Source, use the actual module list, database, code tree, and representative records to establish lineage. For another or restricted Source, use its own component/record evidence and permitted retrieval contract, with access limits recorded. An old project document or invoice can explain history but cannot establish current activation or schema. Name the access owner for the selected Source; API, file, and database evidence are not interchangeable simply because the platform supports them.
Prepare Products, Product Classes, Attributes, and Variations
Distinguish the Product, Product class, attribute definition, assigned value, customer selection, specification, and variation relationship. Capture global, class-level, and Product-specific attribute scope. An option can alter price or weight without creating a separately stocked item. For Product Variations, preserve each linked Product ID and its group relationship. For legacy Product Variants, preserve parent/child combinations and any values inherited from the parent. Select the intended destination representation explicitly.
Create a catalog inventory that includes Product ID, SKU, name, status, Product type where relevant, Category assignments, Product class, attributes, variations or variants, prices, stock, weight, images, files, memberships, tax classes, vendor or seller ownership where applicable, and external identifiers.
| 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. |
Freeze original attribute IDs and values before approved normalization. Confirm semantic equivalence within their scope and owning model before merging names. Record whether a change is Product-specific or shared; class/global changes can affect multiple Products. Preserve actual combinations and independent grouped Products rather than generating or consolidating records solely from matching labels.
Prepare Categories, Navigation, Membership Visibility, and Catalog Scope
Categories, menus, Product classes, memberships, vendors, and storefront presentation can all shape discovery. Prepare the Category hierarchy and Product assignments, but do not assume that Category membership reproduces navigation or access rules.
For Stores using memberships, prepare Customer assignments and the actual Product, Category, pricing, or account rules they control. A membership label is not the rule itself, and an extension can add different commercial behavior. For marketplace or multi-vendor installations, record the actual component, vendor ownership, seller identifiers, Product/Order relationships, and commission or settlement references where present.
| 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. |
| Navigation and menus | 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 Customers, Memberships, Addresses, and Orders
X-Cart Customer data can include users, addresses, memberships, roles, profile fields, account status, marketing preferences, vendor profiles, and external IDs. Separate login identity from Customer, staff, administrator, vendor, or membership roles.
Order preparation should retain Order-time Product descriptions, SKUs, attributes, variation selections, prices, discounts, taxes, shipping, payment labels, statuses, notes, shipments, refunds, returns, vendor context, and external references where present. Record which modules create additional Order items, surcharges, subscription records, payment transactions, fulfillment data, or marketplace settlement details.
| 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 | Membership-dependent catalog or price behavior has an owner. |
| 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 | Continuing systems can locate the same record. |
Keep original Order names, attributes, prices, addresses, statuses, and transaction references in the historical snapshot. Record anomalies and approved dispositions separately. Prepare account access as its own dependency: the supported password-verification path or reset/activation handling, external login, staff/vendor privileges, and destination access owner must be known. Historical payment and shipment references remain separate from live credentials and future actions.
Inventory Modules, Custom Code, Custom Tables, and External Systems
X-Cart modules can extend or replace core data structures, add database tables, decorate model behavior, create API resources, add fields, or control storefront rendering. Current and older X-Cart generations also use different module paths and frameworks. Prepare an ownership ledger rather than a simple installed-module list.
| Module effect | Evidence to prepare | Ready condition |
|---|---|---|
| Product or Customer field | Field key, data type, entity owner, representative IDs | The value has a destination owner or deliberate exclusion. |
| 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 modules as active and required, active but replaceable, historical-only, inactive with retained data, or obsolete. Preserve relevant records before exclusion. A retained record needs both a schema and an intended destination consumer; copying a custom field or table does not itself preserve its behavior. Also identify jobs, notifications, stock feeds, payment processes, and external writes that need containment when sample data is restored or tested.
Prepare Content, Media, URLs, and Storefront Assets
X-Cart content can include Product and Category descriptions, static or CMS Pages, Blog Posts where a module provides them, menus, banners, labels, translations, email templates, theme blocks, and module-generated pages. Prepare content by owner rather than treating all visible text as one CMS export.
Record important Product, Category, content, membership, vendor, and module routes. Include canonical paths, language or storefront scope, traffic importance, route-generating module, and intended disposition. Themes and modules may create routes that are not represented by ordinary content records.
Prepare original media and files with their record relationships, retrieval access, external storage, generated sizes, missing originals, case-sensitive paths, and protection owner. Pair this with the actual export or API schema, selected fields and filters, module-specific artifacts, and record counts. A standard Product export cannot explain every module history, protected file, or external dependency.
Build the X-Cart Source Recovery and Input Package
Preserve a protected Source recovery and input package before structural cleanup. For an accessible self-hosted X-Cart Source, include the complete database, relevant application and public files, environment, module manifests, and deployment or upgrade notes from the same state. For another or restricted Source, preserve available dated exports, archives and original assets with recovery coverage, limitations and owner; record exports do not establish a full installation restore. Name the recovery owner and retention period, and record 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. |
Confirm the Intended X-Cart Generation and Module Consumers
Record the actual intended X-Cart generation, package/edition context, access roles, runtime/deployment requirements, and compatible enabled modules needed for the agreed scope. Assign technical and business owners. Native import functionality, an installed file, or a complete Source backup does not establish selected-path coverage or destination compatibility.
Use the actual Source item and attribute model to confirm the intended Product class, variant/linked-variation, membership, vendor, history, file and custom-data consumers. Preserve Source identities and relationships when the destination representation differs. Required component, access or compatibility gaps need resolution, an explicit agreed exclusion, or a hold before samples are selected.
Select Representative Migration Test Samples
Prepare each sample with original IDs and values, module/external relationships, media files, intended destination representation, accepted exclusions, and a reviewer. Preserve group membership and individual IDs for linked variations, and parent/child evidence for legacy variants. The manifest is ready when every selected dependency is retrievable and the intended meaning is clear; successful execution belongs to subsequent testing.
Include:
- simple Products and Products from several Product classes;
- Products with descriptive attributes, customer-entered values, and active variations;
- one legacy-variant or migrated-variation case if the Store has passed through that module change;
- Products restricted by membership or owned by vendors where used;
- Customers with memberships, several addresses, external IDs, or vendor roles;
- guest and registered Orders with variations, unusual totals, refunds, shipments, and module-created records;
- important Category, content, media, and route examples;
- one active custom-module record and one external-system relationship.
Apply the Final 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? | Roles, memberships, addresses, Order snapshots, statuses, and external references have owners. |
| Are modules and custom data classified? | Active and historical module-owned records have a disposition. |
| 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? | Core, complex, legacy, module-owned, and external-system cases are included. |
Keep unresolved dependencies in a decision register with an owner, due date, and scope effect. Required access, variation identity, module schema, account, file, vendor, or external-key gaps must be resolved, explicitly excluded with approval, or hold the affected scope. Recording an unknown does not make the preparation complete.
Conclusion
X-Cart preparation depends on source lineage. Version, module generation, Product classes, attributes, variations, memberships, vendors, Order extensions, custom modules, and external systems determine which records exist and how they relate.
A Source package with documented recovery coverage and limits, independent X-Cart implementation prerequisites, and a representative evidence manifest allows migration configuration to reflect the actual Store. Full native database-and-file recovery remains required for an accessible X-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 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 customer-entered values, or participate in sellable variations. Only the relationships that define separate SKU, stock, price, weight, or image meaning should be treated as variation identity.
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.