Before a move into CS-Cart, prepare the evidence behind the intended operation. Store Builder needs a merchant-owned catalog and buying model; Multi-Vendor can also require seller companies, administrator users, owned offers, Order parts and financial relationships.
Separate the actual Source records and access from the intended destination prerequisites. An owner, inventory entry or future plan cannot replace required input or a working consumer at the stage that needs it. Each preparation item below connects an action with its evidence, responsibility and ready condition.
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. |
For an older CS-Cart Source, identify any inventory-bearing legacy Option Combinations and their code, quantity, image and parent relationship separately from current Variations. Record allowed or forbidden selections, file attachments, required Products, bundles, rewards and extension-owned fields where 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.
- Storefront domains and languages: Owner: Platform administrator Evidence: Storefront settings and domain list Ready condition: Every public Store context is identified.
- Product and Category availability: Owner: Catalog owner Evidence: Storefront/company assignment export Ready condition: Shared and restricted catalog records are distinguishable.
- Features and filters: Owner: Merchandising owner Evidence: Feature-to-Category and storefront map Ready condition: Discovery vocabularies have explicit scope.
- CMS Pages and layouts: Owner: Content owner Evidence: Page, block, layout, menu, and storefront inventory Ready condition: Content and presentation are tied to the correct storefront.
- Company or vendor ownership: Owner: Marketplace owner Evidence: Product, Order, administrator, and page associations Ready condition: 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.
Use installed-version meaning for financial labels. In current Multi-Vendor documentation, payouts collect money from vendors for the marketplace; withdrawals move money from the marketplace to vendors. Record the actual direction and event rather than inferring an obligation from a label. Vendor Plans can record fees and commissions without by themselves transferring money.
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.
- Customer identity: Preparation action: Identify duplicates, shared emails, guests, approvals, and external keys Evidence: Customer exception list Ready condition: Identity exceptions have an owner and disposition.
- User groups: Preparation action: Record membership and every price, tax, access, or content effect Evidence: Group-to-rule matrix Ready condition: Group meaning is documented beyond its label.
- Profile fields: Preparation action: Record field owner, type, required status, and usage Evidence: Profile-field inventory Ready condition: Active custom values have a destination decision.
- Addresses: Preparation action: Separate reusable profiles from Order-time snapshots Evidence: Customer and Order examples Ready condition: Account and transaction records are distinct.
- Vendor administrators: Preparation action: Keep seller-admin identity linked to the vendor record Evidence: Administrator map Ready condition: Marketplace access is not flattened into Customer segmentation.
- External account IDs: Preparation action: Record CRM, ERP, loyalty, or B2B keys Evidence: Identifier map Ready condition: 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.
Record the actual storefront account policy. Store Builder can use configured sharing or separate populations; Multi-Vendor Ultimate shares Customers across storefronts. Keep Customer groups separate from administrator/vendor permissions, and assign any required tax or company/approval behavior to its actual implementation.
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.
- Product or catalog extension: Evidence to prepare: Fields/tables, Product IDs, settings, and representative records Ready condition: Active catalog values have a defined owner.
- Vendor or accounting extension: Evidence to prepare: Vendor, plan, commission, payout, or withdrawal records Ready condition: Marketplace financial data is classified separately.
- Payment or shipping extension: Evidence to prepare: Historical references and configuration summary Ready condition: Transaction evidence is separated from current Store setup.
- SEO or route extension: Evidence to prepare: SEO names, rewrite settings, and redirect tables Ready condition: Important source paths can be reconstructed.
- Theme or layout customization: Evidence to prepare: Theme files, layout/block assignments, screenshots Ready condition: Business content is separated from presentation.
- ERP/PIM/WMS/marketplace integration: Evidence to prepare: Authority, synchronization direction, and stable IDs Ready condition: Continuing systems can reconnect to target entities.
- Custom table or field: Evidence to prepare: Schema, parent keys, consumer, and business purpose Ready condition: Every active custom value has a disposition.
For a required destination workflow, prepare a compatible installed consumer, usable configuration, permissions and testable data relationship at the stage that needs it. A replacement name or future owner alone cannot make a critical missing consumer ready. Preserve required history even when the former live component is retired.
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
- Database backup or export archive: Owner: Source data owner Evidence: Available Source dump with prefix, or attributable exports, capture date and recovery coverage Ready condition: Required core, extension and vendor evidence is recoverable within the documented Source access limits.
- Files and media: Owner: Hosting or technical owner Evidence: Available media/file archive or accessible Source tree with record links Ready condition: Required images, downloads and attachments are available; theme/code access limits are recorded.
- Edition and scope record: Owner: Platform owner Evidence: Version, edition, storefronts, companies/vendors, languages, currencies Ready condition: Store Builder and Multi-Vendor relationships are explicit.
- Access register: Owner: Project owner Evidence: Access owner and connection status Ready condition: Required access is available without exposing credentials.
- Change log: Owner: Store administrator Evidence: Structural changes after the evidence cut-off Ready condition: 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 the patterns relevant to the agreed operation:
- 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.
Identify the test stage that can exercise each requirement. A limited standard sample cannot establish enhanced, tailored or live implementation outcomes that it does not execute. Keep expected inputs and acceptance criteria separate from observed test results.
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? | Applicable vendors, administrators, owned Products or offers, Orders, plans and accounting records have attributable evidence, defined relationships and ready consumers where required. |
| Are Customers and Orders interpretable? | Groups, profiles, addresses, statuses, totals, seller context, and external IDs are documented. |
| Are extensions and custom data classified? | Every required dependency has a business purpose, supported handling and the usable target prerequisites required for its stage; retired items have an explicit disposition. |
| Are content and routes inventoried? | Storefront, vendor, CMS, Blog, media, and SEO relationships are documented. |
| Are backup, access, and samples ready? | Required input and recovery evidence is actually obtainable, access works, and representative IDs, files and expected relationships are available to reviewers. |
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
Preparation is complete when the actual Source evidence is obtainable and the intended CS-Cart model is explicit. Catalog choices and stock, storefront scope, Customer and seller identities, purchased-item history, financial meaning, content and continuing consumers need attributable inputs and responsible owners.
Required missing evidence or prerequisites keep the affected scope open. After transfer, the CS-Cart validation priorities assess whether those prepared expectations became a meaningful, usable result.
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 domain, language, currency, theme, catalog, content, routes and actual company/vendor scope. Qualify which objects can be shared or vary in the selected product and edition; Store Builder and Multi-Vendor do not use identical rules.
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. Identify older inventory-bearing Option Combinations separately when the actual Source uses them.
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.