CS-Cart preparation must begin by identifying whether the intended operating model is a merchant-run Store Builder environment or a Multi-Vendor marketplace. Both use related catalog structures, but marketplace preparation adds vendor ownership, vendor administrators, seller-specific Products and Orders, commissions, accounting records, withdrawals, storefront permissions, and extension-dependent money flows.
The objective is to prepare source evidence before migration configuration is finalized. Every major area should name the action, owner, evidence, and ready condition. Product options, features, and variations must remain distinct; storefront scope must be explicit; vendor records must not be reduced to Customer accounts; and historical Orders must preserve seller and financial context.
Confirm the CS-Cart Edition, Version, Storefronts, and Access
Record the exact CS-Cart or Multi-Vendor edition, version, installation path, database, active storefronts, companies or vendors, languages, currencies, themes, platform extensions, and external synchronizations. Long-running installations may include upgraded Product-variation structures, retired extensions, custom templates, or database modifications that change the available source records.
Prepare the source access required for the selected migration path. The technical owner should confirm the correct database, file tree, admin environment, and any access restrictions. For Multi-Vendor, also identify the marketplace administrator and the people who understand vendor relationships and accounting records.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm edition and version | Technical owner | Version and license/edition evidence | Store Builder and Multi-Vendor assumptions are not mixed. |
| Record storefront scope | Commerce owner | Storefront list, domains, languages, currencies, company assignments | Every active storefront has a documented business purpose. |
| Confirm source access | Hosting or database owner | Connection status, database prefix, file-root note | Required source records and files are reachable. |
| Inventory themes and extensions | Developer or agency | Active theme, extension list, custom-table and modified-file record | Core records and extension-owned behavior can be separated. |
| Identify external systems | Integration owner | ERP/PIM/WMS/marketplace/accounting list and stable keys | Values maintained outside CS-Cart have a named authority. |
Create a change log after the evidence cut-off. New extensions, Product-variation changes, vendor merges, storefront changes, or Category restructuring should be recorded while preparation is active.
Prepare Products, Options, Features, Variations, and Categories
CS-Cart separates Product properties, selectable options, Product features, variations, Categories, quantity discounts, downloadable files, images, SEO values, and storefront assignments. Options can collect buyer choices or input. Features describe structured characteristics and can support filtering or comparison. Variations group similar Products based on feature values and can carry independent Product identity.
Prepare a Product inventory that identifies which structure owns each commercial or descriptive value.
| Source pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Selectable option | Record option type, variants, required status, combination rules, and price/weight effects | Product and option assignment export | Buyer-choice behavior is explicit. |
| Product variation | Record variation group, feature values, Product IDs, SKU, price, stock, images, and status | Variation-group manifest | Each independently managed Product remains identifiable. |
| Product feature | Record feature group, type, values, Category/storefront scope, and filter use | Feature inventory | Descriptive and discovery values are separated from options. |
| Product in several Categories | Record all assignments, primary merchandising context, and storefront scope | Product-to-Category export | Shared placement is visible without duplicate Product assumptions. |
| Downloadable Product | Record files, activation conditions, Product relationship, and original path | Product/file manifest | Files and Product relationships are available. |
| Quantity or wholesale price | Record Product, threshold, user group or customer context, currency, and amount | Pricing inventory | Conditional commercial values are not reduced to base price. |
Record forbidden or allowed option combinations, file attachments, required Products, bundles, reward relationships, and extension-owned Product fields where they are active. Do not merge similar option and feature labels without confirming whether one is a buyer choice and the other a specification.
Document Storefront, Company, and Catalog Scope
CS-Cart can use multiple storefronts, and Multi-Vendor can introduce vendors whose Products, administrators, pages, shipping methods, and Orders belong to distinct marketplace participants. Prepare a scope matrix that shows which records belong to the common catalog, a specific storefront, a vendor, or an external channel.
| Scope area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Storefront domains and languages | Platform administrator | Storefront settings and domain list | Every public Store context is identified. |
| Product and Category availability | Catalog owner | Storefront/company assignment export | Shared and restricted catalog records are distinguishable. |
| Features and filters | Merchandising owner | Feature-to-Category and storefront map | Discovery vocabularies have explicit scope. |
| CMS Pages and layouts | Content owner | Page, block, layout, menu, and storefront inventory | Content and presentation are tied to the correct storefront. |
| Company or vendor ownership | Marketplace owner | Product, Order, administrator, and page associations | Seller-owned records are not treated as marketplace-owned by default. |
Prepare Vendors, Administrators, Plans, and Financial Relationships
This section applies when the source or target operating model includes Multi-Vendor. A vendor is an independent selling company with associated administrators, Products, Orders, shipping context, status, and accounting relationships. Vendor plans, transaction fees, commissions, payouts, withdrawals, and marketplace payment extensions can add further records.
Prepare a vendor ledger that distinguishes active, pending, disabled, merged, historical, and duplicate vendors. Record the administrators assigned to each vendor, Product ownership, Order ownership, plan or commission context, account balance evidence, payout and withdrawal records, and external seller identifiers.
| Marketplace record | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Vendor identity | Record company ID, status, legal/contact data, storefront page, and external key | Vendor inventory | Each retained seller has one intended identity. |
| Vendor administrators | Record user account, vendor relationship, status, and permissions context | Administrator-to-vendor map | Seller access relationships are documented. |
| Vendor-owned Products | Record Product and Category ownership, approval status, and storefront scope | Product-to-vendor export | Catalog ownership is explicit. |
| Vendor plans or commissions | Record plan, fee, commission, effective dates, and owning extension | Plan/commission inventory | Financial rules are separated from ordinary vendor profile fields. |
| Accounting, payouts, and withdrawals | Record transaction type, vendor, amount, status, date, and related Order | Financial history samples | Marketplace financial context is traceable. |
| Split or vendor Orders | Record parent/suborder relationships and responsible vendor | Representative Order groups | Historical seller responsibility can be interpreted. |
Do not assume that every Customer with a company name is a vendor, or that a vendor administrator account contains the full seller record.
Prepare Customers, User Groups, Addresses, and Account Fields
CS-Cart Customer records can include addresses, user groups, approval status, profile fields, newsletters, rewards, reviews, and external identifiers. Multi-Vendor also includes vendor administrators, which require separate ownership from ordinary Customers.
| Record area | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Customer identity | Identify duplicates, shared emails, guests, approvals, and external keys | Customer exception list | Identity exceptions have an owner and disposition. |
| User groups | Record membership and every price, tax, access, or content effect | Group-to-rule matrix | Group meaning is documented beyond its label. |
| Profile fields | Record field owner, type, required status, and usage | Profile-field inventory | Active custom values have a destination decision. |
| Addresses | Separate reusable profiles from Order-time snapshots | Customer and Order examples | Account and transaction records are distinct. |
| Vendor administrators | Keep seller-admin identity linked to the vendor record | Administrator map | Marketplace access is not flattened into Customer segmentation. |
| External account IDs | Record CRM, ERP, loyalty, or B2B keys | Identifier map | Continuing systems can locate the same account. |
Prepare Orders, Seller Ownership, Totals, and Historical Status
Order preparation should preserve what was purchased, by whom, from which seller, at what price, and under which historical payment, shipping, tax, discount, and status context. Multi-Vendor Orders may be split so each vendor manages a related part of the original purchase.
| Order evidence | Preparation action | Ready condition |
|---|---|---|
| Product and variation lines | Record Product ID, variation/features/options, seller, quantity, price, and snapshot text | Purchased items and seller ownership remain interpretable. |
| Parent and vendor Orders | Record original Order and related seller-specific Orders | Multi-Vendor history is not flattened into unrelated transactions. |
| Billing and shipping addresses | Preserve Order snapshots separately from Customer profiles | Historical address evidence is complete. |
| Taxes, shipping, discounts, fees, and rewards | Inventory every material total and extension owner | Final totals can be explained. |
| Payment and fulfillment references | Record labels, transaction IDs, shipping methods, tracking, and responsible vendor | Historical processing context is traceable. |
| Statuses, refunds, and comments | Record sequence, visibility, affected seller, and related records | Staff can interpret the historical lifecycle. |
| Accounting references | Link Orders to commission, payout, withdrawal, or balance records where applicable | Marketplace financial history remains connected. |
Historical Orders should not be recalculated from current Product, vendor-plan, commission, shipping, or payment settings.
Inventory Platform Extensions, Themes, Custom Fields, and Integrations
CS-Cart extensions can own Product variations, SEO names, vendor plans, marketplace payments, rewards, reviews, layouts, custom fields, Order totals, reports, or external connections. Use “platform extension” or the component’s exact name so platform functionality is not confused with migration-service enhancements.
| Dependency effect | Evidence to prepare | Ready condition |
|---|---|---|
| Product or catalog extension | Fields/tables, Product IDs, settings, and representative records | Active catalog values have a defined owner. |
| Vendor or accounting extension | Vendor, plan, commission, payout, or withdrawal records | Marketplace financial data is classified separately. |
| Payment or shipping extension | Historical references and configuration summary | Transaction evidence is separated from current Store setup. |
| SEO or route extension | SEO names, rewrite settings, and redirect tables | Important source paths can be reconstructed. |
| Theme or layout customization | Theme files, layout/block assignments, screenshots | Business content is separated from presentation. |
| ERP/PIM/WMS/marketplace integration | Authority, synchronization direction, and stable IDs | Continuing systems can reconnect to target entities. |
| Custom table or field | Schema, parent keys, consumer, and business purpose | Every active custom value has a disposition. |
Prepare CMS Pages, SEO Names, Media, and Route Evidence
Prepare CMS Pages, Blog Posts where present, Product and Category descriptions, vendor pages, menus, layouts, blocks, banners, attachments, and media by owner and storefront. Record language, status, route, storefront, vendor relationship, embedded links, and intended disposition.
For priority Product, Category, feature, CMS, vendor, and Blog routes, record the source object, storefront, language, SEO name, current path, business importance, and redirect or exclusion decision. Blog Posts, vendor storefront pages, and CMS blocks can share labels while belonging to different owners, so record their IDs, storefront scope, author or vendor relationship, media, and menu placement separately. Preserve original images, downloadable files, attachments, and theme assets outside the database backup.
Build the Backup and Input-Readiness Package
| Package component | Owner | Evidence | Ready condition |
|---|---|---|---|
| Database backup | Database administrator | Timestamped dump and database-prefix note | All core, extension, and vendor tables for the intended Store are included. |
| Files and media | Hosting or technical owner | File archive or accessible source tree | Images, downloads, attachments, themes, and extensions are available. |
| Edition and scope record | Platform owner | Version, edition, storefronts, companies/vendors, languages, currencies | Store Builder and Multi-Vendor relationships are explicit. |
| Access register | Project owner | Access owner and connection status | Required access is available without exposing credentials. |
| Change log | Store administrator | Structural changes after the evidence cut-off | Late changes can be incorporated deliberately. |
Select Representative Migration Test Samples
Prepare a sample manifest with source IDs, business reason, owning storefront or vendor, related files, and expected source relationships. The CS-Cart sample manifest is ready when every source expectation, storefront or vendor owner, linked file, and identifier is complete and assigned to a reviewer.
Include at least:
- simple Products and Products with options, features, variations, several Categories, files, or special pricing;
- records scoped to different storefronts;
- ordinary Customers, user-group Customers, vendor administrators, and custom profile fields;
- standard Orders and Orders with variations, unusual totals, refunds, tracking, and external IDs;
- for Multi-Vendor, vendor-owned Products, parent/suborders, plans, commissions, payouts, or withdrawals;
- priority CMS, Blog, Product, Category, vendor, and SEO routes;
- one active platform-extension record and one external-system relationship.
Apply the Final CS-Cart Readiness Gate
| Readiness question | Required outcome |
|---|---|
| Is edition and storefront scope known? | Version, Store Builder or Multi-Vendor model, storefronts, languages, and companies/vendors are recorded. |
| Is catalog evidence complete? | Products, options, features, variations, Categories, pricing, media, and scope are represented. |
| Are marketplace relationships prepared? | Vendors, administrators, seller-owned Products, Orders, plans, and accounting records have owners. |
| Are Customers and Orders interpretable? | Groups, profiles, addresses, statuses, totals, seller context, and external IDs are documented. |
| Are extensions and custom data classified? | Every active dependency has a business purpose and destination decision. |
| Are content and routes inventoried? | Storefront, vendor, CMS, Blog, media, and SEO relationships are documented. |
| Are backup, access, and samples ready? | The source package is restorable and representative IDs are listed. |
Preparation remains open when edition, vendor ownership, Product variation, Order-splitting, accounting history, storefront scope, or an active extension record is still undocumented.
Conclusion
CS-Cart preparation must reflect the actual operating model. Products, options, features, variations, storefronts, Customers, Orders, content, and extensions form one preparation layer; Multi-Vendor adds sellers, administrators, seller-owned catalog records, split Orders, plans, commissions, payouts, and withdrawals.
A controlled source package makes those relationships explicit and supplies representative records for migration configuration.
Common Questions
Why must CS-Cart Store Builder and Multi-Vendor be distinguished before migration?
Multi-Vendor introduces vendors, vendor administrators, seller-owned Products, split Orders, plans, commissions, accounting, payouts, and withdrawals. Those relationships do not belong to an ordinary Store Builder data model.
What is the difference between CS-Cart options, features, and variations?
Options collect buyer choices or input, features describe and classify Products, and variations group independently managed Products based on feature values. Prepare them as separate evidence sets.
How should multiple CS-Cart storefronts be documented?
Record each storefront’s domain, language, currency, theme, Products, Categories, content, routes, features, and company scope. Shared and restricted records should be visible in one matrix.
What vendor records belong in a Multi-Vendor preparation package?
Include vendor profiles, statuses, administrators, Product ownership, Order ownership, plans, commissions, accounting transactions, payouts, withdrawals, and external seller identifiers where used.
Should CS-Cart extension data be treated as ordinary Product or Order fields?
Not automatically. Record the extension, affected entities, tables or fields, representative IDs, and business consumer. Active records need an explicit owner; obsolete data can be archived or excluded.
Which Orders should be selected for CS-Cart preparation?
Use ordinary and complex Orders, variation and option lines, several totals and statuses, refunds, tracking, external IDs, and, when Multi-Vendor is involved, parent/suborders, vendor responsibility, and linked accounting records.