CS-Cart preparation begins with the operating model: a merchant-run Store Builder or a Multi-Vendor marketplace. That choice determines whether the evidence package must explain a shared catalog alone or also preserve sellers, their administrator identities and the financial relationships behind vendor Orders.
Map the Source catalog and transaction model to that intended destination. Marketplace scope adds vendor-owned Products, Order parts, commissions, accounting, withdrawals, storefront permissions and component-dependent money flows. Prepare those links with their sellers and administrator users, including historical records whose owners are no longer active.
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 intended CS-Cart or Multi-Vendor edition, build, enabled storefronts, languages, currencies, themes, components and external systems. Separately inventory the actual Source and map its operating relationships to that destination. If the Source is CS-Cart, include installation, database and version evidence: upgrades, retired extensions, custom templates and schema changes can affect its records. Do not infer older-build behavior from a feature documented in the current release.
Confirm the access and evidence available from the actual Source for the selected migration path. A self-hosted CS-Cart Source may require its database, file tree and administration owners; a different hosted Source may provide exports and media instead. Assign destination application and component owners separately. For marketplace scope, identify the people who can explain vendor relationships and accounting before execution is approved.
| 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 | Source access owner | Available export or database/file access, account identity and technical contact | Required Source records and files are reachable through the qualified path. |
| 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
Prepare Product properties, options, features, variations, Categories, pricing, downloads, images, SEO values and scope as separate relationships. In an enabled Product Variations component, group members are individual Products; their feature values define the variation relationship. Feature purpose can control descriptive filtering or whether variations appear as separate catalog items or choices within one item. Record that purpose and the default/member relationships, not only the visible storefront count.
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 group, type, purpose, values, Category and actual storefront/vendor ownership, and filter use | Feature inventory | Descriptive/filter use and variation purpose are distinguished from buyer 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
Record the storefront and company contexts actually available in the intended edition and build. In Store Builder, storefront ownership can scope catalog and features; Multi-Vendor adds vendor-owned Products, administrators, pages, shipping and Orders. Those are different ownership relationships, so do not assume the same feature or storefront model across editions. Map each Source record to the common catalog, intended storefront, vendor or continuing 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
Multi-Vendor preparation applies when the Source or Target operating model includes independent selling companies 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, applicable status, date, related Order and settled/open position | Financial history samples and payment-route evidence | Marketplace financial context and remaining obligations are traceable. |
| Split or vendor Orders | Record parent/suborder relationships and responsible vendor | Representative Order groups | Historical seller responsibility can be interpreted. |
Prepare the actual money flow as well as the financial records. Default marketplace collection and an enabled direct-to-vendor payment component have different responsibilities, and a vendor without its own payment method may use marketplace collection instead. Identify who received the money and which balances are settled or still due. Order-related accounting entries are distinct from payouts and withdrawals; do not apply a payout/withdrawal status model to every entry. Keep vendor companies, their administrator users and shopper Customers as separate identities.
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 account access separately from user-group rules and vendor administration. The exact Source-to-Target path and identity systems determine usable password continuity or required reset, activation or first-login handling. Assign the customer and seller communication as part of readiness.
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. |
Preserve historical totals and seller relationships rather than recalculating them under current Product, plan, commission or payment settings. A historical Order does not prove an unpaid vendor obligation or authorize another payout. Prepare the isolation of live accounting, payment, notification and fulfillment events, with the actual collection route and settled/open balances confirmed by their owners.
Inventory Platform Extensions, Themes, Custom Fields, and Integrations
Inventory the enabled components and custom code that own catalog, variation, SEO, vendor plans, marketplace payments, rewards, reports or external connections. Record the compatible destination component or replacement implementation along with its configuration and consuming code; copied fields or tables do not transfer behavior. Use “platform extension” or the exact component name to distinguish Platform functionality from 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 or export archive | Source data owner | Available Source dump with prefix, or attributable exports, capture date and recovery coverage | Required core, extension and vendor evidence is recoverable within the documented Source access limits. |
| Files and media | Hosting or technical owner | Available media/file archive or accessible Source tree with record links | Required images, downloads and attachments are available; theme/code access limits are recorded. |
| 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? | Recovery coverage and access are confirmed, and representative IDs with related files are listed. |
Preparation remains open when a critical edition, vendor, variation, split-Order, accounting, storefront or active-component decision lacks evidence. Resolve the gap, explicitly exclude the affected scope or hold it before execution. Noncritical exceptions need an accepted impact, owner and boundary; a due date alone does not make a missing marketplace relationship ready.
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 adds seller companies, administrator users, seller-owned Products and Order parts, plus the financial relationships created by enabled marketplace components. Prepare those ownership layers separately from shopper accounts and a merchant-run catalog. The distinction determines which people and evidence are needed before the destination is designed.
What is the difference between CS-Cart options, features, and variations?
Options collect buyer choices or input. Features provide structured values, and their configured purpose can support filtering or define variation presentation. With Product Variations enabled, groups connect individual Product records through feature values. Prepare the options, feature purposes, group members and default relationships separately.
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.
Does CS-Cart Multi-Vendor require separate migration qualification?
Yes. Multi-Vendor introduces vendor ownership, seller Products, split Orders, commissions, payouts, and other relationships that do not exist in a standard Store Builder model. Do not infer Multi-Vendor scope merely because a CS-Cart path is available. Confirm the exact edition, the required vendor-related data, and the target representation before migration planning is approved.
Why can the storefront Product count differ from the variation inventory?
A variation group may present several Product records as choices within one catalog item, depending on the feature purpose and enabled component. Prepare every member Product ID, SKU and stock owner, plus the default relationship and intended presentation. The displayed item count alone is not evidence that all variation records are covered.
Does every vendor Order imply a payout is owed by the marketplace?
No. Prepare the actual payment route, recipient and settled/open accounting position. A direct-vendor payment configuration or marketplace-collection fallback can change who holds the money. Link the Order to the relevant accounting evidence instead of treating imported history as a new payout instruction.