CS-Cart represents commerce through relationships that are easy to flatten incorrectly. Products can carry features, filters, options, option exceptions, and Product variations. Categories and Products can belong to different storefront scopes. Multi-Vendor editions add vendors, vendor administrators, seller-owned Products, marketplace Orders, commissions, and payout context. Customer groups can affect prices, access, and promotions. Platform extensions can introduce records that do not belong to the core catalog at all.
These differences matter because similar source labels do not guarantee similar behavior. A “color” field may be a descriptive feature, a filtering value, an option that modifies price, or a feature used to generate separate Product variations. A source store may translate into an independent CS-Cart storefront, a regional marketplace branch, or simply a localized presentation. A supplier may be an internal reference in one system and a marketplace vendor with Product and Order ownership in another.
CS-Cart migration therefore requires a translation of entity ownership and relationships. The objective is to preserve what each record means to the catalog, storefront, seller, Customer, Order, and connected systems, not merely to reproduce field names.
CS-Cart Separates Catalog Facts, Buying Choices, and Sellable Variations
CS-Cart uses different structures for Product facts and Product choices. Features are inseparable Product properties such as brand, material, ISBN, or technical specification. They can be grouped and used for comparison, filtering, or catalog organization. Options are separable buyer choices such as engraving, gift wrap, or warranty; they do not have independent stock but can affect price or weight. Product variations are Products grouped by selected feature values, and each variation remains a Product with its own commercial identity.
| Source value | CS-Cart owner | Meaning that must remain distinct |
|---|---|---|
| Technical specification | Product feature or feature group | Describes the Product and may support filtering or comparison. |
| Buyer-selected migration approach | Product option and option variant | Changes the purchased configuration without becoming independent stock. |
| Color/size child SKU | Product variation within a variation group | Remains a Product and may carry its own SKU, price, stock, image, and catalog visibility. |
| Forbidden choice combination | Option exception or variation availability rule | Prevents invalid configurations rather than creating a new attribute value. |
| Reusable merchandising choice | Global option or template-like structure | One definition may be assigned to multiple Products. |
| Search facet | Filter based on features or other supported values | Requires normalized values and correct Category relationships. |
The distinction between variations and catalog items is especially important. Every variation is a Product, but a variation may or may not occupy its own visible place in Product lists. A source catalog that exposes each child SKU as a separate Product may need several visible catalog items; another catalog may present one parent while keeping most variation choices inside the Product page.
A migration that maps all source options into CS-Cart features loses buying behavior. Mapping all specifications into options creates unnecessary purchase choices. Mapping all child SKUs into one Product can remove independent inventory and identity. The correct structure follows what the source value controls.
Products, Categories, Features, and Filters Form the Discovery Model
A CS-Cart Product includes core commercial fields, images, price, quantity, status, shipping and tax information, descriptions, Categories, features, options, files, and extension-owned values. Categories provide hierarchy and storefront scope; features supply structured facts; filters expose selected values for discovery.
A source Category may represent navigation, an SEO landing page, a brand, a technical classification, or an internal grouping. Those meanings should not automatically remain Categories. A source brand stored as a Category may fit a CS-Cart brand feature. A specification tree used for faceted navigation may need feature groups and filters. A merchandising landing page may require content and blocks in addition to Product assignments.
| Source discovery structure | CS-Cart translation question | Relationship consequence |
|---|---|---|
| Category hierarchy | Which Categories remain buyer-facing and which are internal? | Product assignment and storefront ownership depend on the answer. |
| Brand Categories | Should brand become a Product feature? | Brand can support filtering and comparison without duplicating navigation. |
| Facet values | Are they normalized features, options, or custom extension fields? | Only the correct owner can support consistent filters. |
| Multi-Category Products | Which Categories and storefronts should expose each Product? | A Product can be present but absent from an important buyer path. |
| Product files | Are they downloads, attachments, manuals, or extension records? | File ownership determines access and Order-line meaning. |
CS-Cart Product codes are identifiers but are not inherently guaranteed to be unique. When the Source Store relies on SKU uniqueness for ERP, warehouse, or marketplace matching, the external identifier relationship should be explicit rather than inferred from the platform label alone.
Storefronts Change Product, Category, Customer, and Configuration Scope
CS-Cart storefront behavior differs by edition. In Store Builder Ultimate, storefronts can operate as independent stores with their own Products, Categories, settings, user bases, and checkout mechanisms. In Multi-Vendor Ultimate, storefronts can represent regional marketplace branches with selected vendors, currencies, languages, payment methods, shipping methods, themes, layouts, and blocks.
That difference means “store” is not a universal source-to-target unit. The same Product may belong to one storefront, appear across several storefronts through Category assignments, or follow vendor visibility across marketplace branches. Categories may belong to one storefront or, in marketplace contexts, have broader scope. Customer accounts and administrators may also be global or storefront-specific depending on configuration.
| Source context | Store Builder interpretation | Multi-Vendor interpretation |
|---|---|---|
| Brand or regional store | Independent storefront with its own catalog and settings | Marketplace branch containing selected vendors and regional configuration. |
| Product ownership | Storefront-owned Product that may appear through assigned Categories | Vendor-owned Product visible where the vendor participates. |
| Product price | Can differ by storefront | Normally follows the vendor Product across branches unless another pricing structure applies. |
| Category | Belongs to a specific storefront | May be global or associated with a specific storefront. |
| Customer base | Can be separated by storefront | May be shared or scoped according to marketplace design. |
| Administrator | Storefront-specific administrative relationship | Marketplace administrators and vendor administrators have different ownership. |
Migration scope must therefore identify whether source storefront differences belong to data, configuration, or independent operations. Locale, currency, payment, shipping, theme, and checkout settings are not substitutes for Product and Category ownership. A record can be correctly migrated and still appear in the wrong storefront if its scope relationship is missing.
Vendors and Common Products Add Marketplace Ownership
CS-Cart Multi-Vendor introduces a vendor as a commercial owner, not merely a manufacturer label. Vendors can have administrators, Products, storefront participation, Order items, shipping methods, plans, commissions, balances, payouts, and profile data. A source supplier field should become a vendor only when that organization actually owns marketplace activity.
Some marketplace implementations also use common Products or shared catalog concepts. A common Product can provide a shared catalog identity while vendor offers carry seller-specific commercial information. This differs from copying the same Product into several vendor catalogs and differs again from one store-owned Product with supplier metadata.
| Source relationship | CS-Cart marketplace destination | Meaning to preserve |
|---|---|---|
| Manufacturer or brand | Product feature, manufacturer-like value, or brand data | Descriptive origin without seller ownership. |
| Supplier reference | Internal field or external identifier | Operational sourcing without marketplace account behavior. |
| Marketplace seller | Vendor record | Ownership of Products, Order lines, commissions, and payouts. |
| Seller administrator | Vendor user or administrative relationship | Access belongs to the correct vendor. |
| Shared catalog item with seller offers | Common Product plus vendor-specific offer data where used | Shared identity remains separate from seller price and stock. |
| Marketplace Order | Parent Order and vendor-related Order or line context | Seller responsibility and settlement remain interpretable. |
Vendor migration is incomplete if seller Products arrive without vendor ownership, or if vendor accounts arrive without their Products, administrators, Order context, and external identifiers. Conversely, turning every source supplier into a vendor creates marketplace relationships that did not exist.
Customers, User Groups, and Commercial Segmentation
CS-Cart users can include Customers, administrators, and vendor users. Customer groups can influence Product prices, discounts, tax treatment, payment methods, shipping methods, and access to Products or Categories. Profile fields and addresses carry additional Customer information, while external systems may own account numbers, credit status, or company relationships.
A source Customer label must be interpreted by function. Wholesale, VIP, dealer, staff, tax-exempt, distributor, or subscription status may map to a CS-Cart user group only when the group is the correct owner of that behavior. A company account with several buyers may require a different structure or platform extension. A CRM segment used only for marketing should not automatically become a pricing group.
| Source Customer meaning | CS-Cart owner to consider | Key relationship |
|---|---|---|
| Individual buyer | Customer user and addresses | Identity, login, addresses, and Orders remain connected. |
| Pricing tier | User group and Product pricing relationship | Customer membership affects the intended commercial values. |
| Access segment | User group and Product/Category restriction | Visibility remains distinct from descriptive tagging. |
| Vendor employee | Vendor user relationship | The user belongs to the correct seller, not the Customer population. |
| External company account | Custom profile data, platform extension, or external identifier | Buyers remain linked to the authoritative organization where required. |
Order history and Customer segmentation should remain separate. A historical Order may record the price and tax applied at purchase time; it should not be recalculated from the Customer’s current group after migration.
Orders Preserve Marketplace and Commercial Snapshots
A CS-Cart Order can include Customer or guest identity, addresses, Product and variation references, option selections, quantities, prices, discounts, taxes, shipping, payment labels, statuses, notes, files, promotions, and marketplace ownership. In Multi-Vendor contexts, seller-related Order structures and commissions add another layer.
Order lines are historical snapshots. A variation’s current Product name, price, stock, feature values, or vendor may change later. The Order must still explain what the Customer purchased. Similarly, historical payment and shipping labels should remain readable even though current checkout methods are Target Store configuration.
| Order element | Historical relationship to retain |
|---|---|
| Product line | Product or variation identity, code, quantity, price, and chosen options. |
| Promotion | Discount amount and source rule or coupon context where available. |
| Tax | Applied tax amount and label at the time of purchase. |
| Shipment | Carrier, method, tracking, fulfilled quantity, and seller context where available. |
| Payment | Historical method label and transaction reference where available. |
| Vendor context | Seller ownership, commission, payout, or vendor Order relationship. |
| Status | Source lifecycle meaning used by service, fulfillment, and reporting teams. |
The Target Store does not need to reproduce every obsolete workflow to preserve history, but the imported Order should remain intelligible. A record that shows a total without the Product configuration, seller, discount, tax, and status context is not equivalent to the source commercial history.
Content, Languages, URLs, and Storefront Presentation
CS-Cart storefront content can include Pages, Blog records where installed, Product and Category descriptions, banners, menus, blocks, layouts, themes, metadata, SEO names, and language-specific values. These assets have different owners and should not be compressed into one generic content entity.
Product and Category descriptions belong to the catalog. Pages and navigation have their own hierarchy and storefront scope. Blocks and layouts describe presentation. SEO names and redirects govern routes. Language values may be stored as translations associated with a shared entity rather than as independent Products or Categories.
| Source asset | CS-Cart destination layer | Boundary to preserve |
|---|---|---|
| Product or Category translation | Language-specific catalog value | One entity remains connected to several localized values. |
| Informational page | Page hierarchy and storefront assignment | Content, parent relationship, access, and route remain distinct. |
| Menu or navigation item | Menu structure or storefront block | Navigation is not inferred solely from Category existence. |
| Banner or promotional block | Presentation or marketing record | Visual placement is separate from underlying Product data. |
| Legacy URL | SEO name and redirect relationship | Source path and destination remain explicit. |
| Theme layout | Target presentation configuration | Theme structure should not be mistaken for portable content data. |
This separation matters in multi-store and marketplace environments, where the same content can be global, storefront-specific, vendor-specific, or language-specific.
CS-Cart Extensions, Custom Tables, and Integrations Own Additional Data
CS-Cart platform extensions can add Product fields, marketplace behavior, loyalty records, subscriptions, bookings, reviews, reward points, payment or shipping data, external feeds, and custom workflows. Their records may live in extension-specific tables and may depend on hooks, settings, scheduled tasks, or external services.
In CS-Cart, an add-on is a platform extension rather than a generic label for ordinary Product fields. Migration scope should identify the extension, its entities, and the core records it extends.
| Data owner | Typical records | Translation requirement |
|---|---|---|
| CS-Cart core | Products, Categories, features, options, variations, users, Orders, storefronts | Preserve native entity and relationship semantics. |
| Multi-Vendor layer | Vendors, vendor users, seller Products, commissions, payouts | Keep seller ownership connected across catalog and Orders. |
| CS-Cart platform extension | Reviews, rewards, subscriptions, booking data, special Product fields | Inspect extension schema and target capability separately. |
| Custom development | Bespoke tables, fields, statuses, or workflow records | Define an explicit destination for every active business relationship. |
| External system | ERP item, CRM account, warehouse, marketplace listing, accounting reference | Preserve identifiers needed for reconciliation and reconnection. |
Import and export formats do not define the complete data model. A field may be exportable without carrying the related extension configuration or workflow. Conversely, an external identifier may be small in size but essential for connecting the migrated record to ERP, PIM, WMS, CRM, or marketplace data.
CS-Cart Translation Decisions by Relationship
A reliable CS-Cart mapping resolves the owner of each source value before deciding the destination field.
| Source pattern | Translation question | Wrong-owner consequence |
|---|---|---|
| Color and size with child SKUs | Is this a variation group based on features? | Independent Product identity, stock, or catalog visibility is lost. |
| Engraving or gift wrap | Is this an option without independent stock? | A service choice is incorrectly represented as a sellable variation. |
| Technical specification | Is this a feature and possibly a filter? | Discovery and comparison become inconsistent. |
| Several regional stores | Are they independent storefronts or marketplace branches? | Product, Category, Customer, and configuration scope is mixed. |
| Supplier or seller | Is it descriptive sourcing or vendor ownership? | Vendor Products, users, Orders, commissions, and payouts are either lost or invented. |
| Customer tier | Is it a user group, external CRM segment, or company relationship? | Price and access behavior is attached to the wrong Customer structure. |
| Extension field | Which CS-Cart module owns it and what record does it extend? | Data is copied without the capability that interprets it. |
CS-Cart migration preserves meaning when catalog facts, buying choices, variations, storefront scope, vendor ownership, Customer segmentation, Order history, content, and extension records remain distinct but connected.
Conclusion
CS-Cart is not a flat Product-and-Order schema. Features describe Products; options represent separable choices; variations remain Products grouped by selected features. Storefronts can own catalog and Customer scope differently across Store Builder and Multi-Vendor editions. Vendors introduce marketplace ownership, while user groups influence commercial treatment. Orders depend on historical line, promotion, tax, payment, shipment, status, and seller context. Platform extensions and external systems can own records outside the core data types.
The strongest migration scope assigns every source value to the CS-Cart structure that controls the same business meaning. This protects Product discovery, buying choices, seller accountability, Customer treatment, historical Orders, localized storefronts, and integration continuity without forcing unlike records into superficially similar fields.
Common Questions
What is the difference between a CS-Cart feature and an option?
A feature is an inseparable Product property such as brand, material, or ISBN and may support filtering or comparison. An option is a separable buyer choice such as engraving, gift wrap, or warranty; it can affect price or weight but does not hold independent stock.
When should source child SKUs become CS-Cart Product variations?
They fit Product variations when each child remains a Product and the group differs through selected feature values. The mapping should preserve child SKU, stock, price, image, and catalog-visibility relationships rather than combining the children into one flat option list.
Can one source store always become one CS-Cart storefront?
No. In Store Builder, a storefront may be an independent store with its own catalog and Customers. In Multi-Vendor, a storefront can be a regional marketplace branch containing selected vendors and regional configuration. The source operating boundary determines the correct model.
Should every source supplier become a CS-Cart vendor?
No. A vendor owns marketplace Products and seller-related commercial records. A manufacturer, brand, supplier code, or purchasing source may remain descriptive or external-system data when it does not represent a seller account.
Why must CS-Cart platform-extension data be separated from core data?
A platform extension can own its own tables, statuses, configuration, and relationships. Copying its fields into a core Product or Customer record does not preserve the workflow that interprets those fields.
How should shared marketplace catalog records be translated?
Separate the shared Product identity from vendor-specific offers, price, stock, ownership, and Order responsibility. Whether the Target Store uses common Products or another marketplace structure, those layers should not be collapsed into duplicate unrelated Products.