X-Cart preparation must begin with the exact source generation and installed module set. X-Cart Stores can differ materially across versions, editions, upgrades, and module generations. Product attributes may act as specifications, customer-selectable values, or variation dimensions. Older installations may use Product Variants, while newer source environments can use Product Variations and a different module or API structure. Memberships, multi-vendor records, custom modules, and external integrations can further change what a Product, Customer, or Order record means.
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
Record the exact X-Cart version, edition or package context, upgrade history, active modules, custom modules, theme, Storefront or marketplace configuration, API generation, and hosting environment. Version lineage is especially important when the catalog has passed through Product Variants or Product Variations changes, module replacements, or custom database migrations.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Identify the exact X-Cart version and update history | Technical owner | Admin screenshot, package information, upgrade notes | The source generation and known upgrades are recorded. |
| Inventory active and inactive modules | Store administrator or developer | Module list with author, version, state, and purpose | Every business-critical module has an owner. |
| Identify Product Variants or Product Variations usage | Catalog and technical owners | Module state, representative Products, relevant data locations | The active variation model is explicit. |
| Confirm source connection and file access | Hosting or technical owner | Access status, allowlist or authentication notes | The intended source installation is reachable. |
| Record theme and custom-code layers | Developer or agency | Theme name, custom module paths, overrides, deployment notes | Presentation and custom behavior are distinguishable from core records. |
| Record APIs and synchronizations | Integration owner | API version, credentials owner, webhook or scheduled-job list | External systems and their record keys are known. |
Do not infer current Store structure from an old project document or module invoice. The live module list, database, code tree, and representative records should agree.
Prepare Products, Product Classes, Attributes, and Variations
X-Cart Product preparation should distinguish the base Product, Product class, attribute definition, attribute value, customer-selectable value, specification, and sellable variation. An attribute named “Color” may be a descriptive field on one Product and a variation dimension with independent SKU, price, stock, weight, or image on another.
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 attributes used to build variations and every active combination | Variation manifest with SKU, stock, price, weight, and image | 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. |
Normalize attribute names only after the catalog owner confirms that two values carry the same meaning. Shared Product classes can amplify an incorrect change across many Products.
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, document which Products, Categories, prices, content, or account functions depend on membership. For marketplace or multi-vendor environments, record vendor ownership, vendor-specific identifiers, seller Products, commissions or settlement references where present, and the relationship between vendor and Order records.
| 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 inheritance is 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. |
Avoid “cleaning” historical Orders by replacing old Product names or attributes with current catalog values. The source snapshot is part of the evidence.
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. An inactive module can still own records needed for historical Orders.
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 file assets with their database relationships. Record external storage, generated sizes, missing originals, case-sensitive paths, and files protected by module-specific access rules.
Build a Restorable X-Cart Source Package
A self-hosted X-Cart source package should include a database backup, relevant application and public files, environment details, module manifests, deployment or upgrade notes, access status, and a record of structural changes after the evidence cut-off.
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database | Database administrator | Timestamped dump and restore-readiness note | Core and module tables come from the same Store state. |
| Application and public files | Technical owner | File archive or accessible source tree | Modules, themes, media, and protected files are available. |
| Environment | Technical owner | PHP, database, queue, cache, storage, and web-server notes | Version-sensitive behavior can be interpreted. |
| Module manifest | Developer or Store administrator | Active/inactive module list with versions | Module-owned entities can be traced. |
| Change log | Project owner | Late changes after evidence collection | New Products, modules, or schema changes are visible. |
Select Representative Migration Test Samples
Prepare a sample manifest that includes source IDs, related module or external-system records, media files, and the expected source relationships. The sample manifest is ready when the selected evidence is complete, traceable, and assigned to a reviewer.
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? | Version, edition context, upgrade history, module generation, and environment are recorded. |
| Is catalog meaning complete? | Product classes, attributes, variations, Categories, memberships, vendors, and media are represented. |
| 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 the source package restorable? | Database and files correspond to the same Store state. |
| Is the sample manifest representative? | Core, complex, legacy, module-owned, and external-system cases are included. |
Critical unknowns should remain open decisions with an owner. Do not finalize preparation while the variation model, module owner, vendor relationship, or external identifier remains unclassified.
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 restorable source package and representative evidence manifest allow migration configuration to reflect the actual Store.
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.