PrestaShop data migration is a translation into a catalog model that separates purchasable variation, descriptive characteristics, customer-entered personalization, shop scope, and module-owned behavior. Familiar records such as Products, Categories, Customers, Orders, Coupons, CMS Pages, images, and URLs change meaning when they enter PrestaShop’s combination, feature, customer-group, multistore, language, and module relationships.
The central distinction is that a source platform may use one broad “option” or custom-field layer for several different jobs. In PrestaShop, a value may need to become an attribute used by a combination, a feature shared by the whole Product, a customization field completed by the customer, a Product association, a Category assignment, a customer-group relationship, a shop-specific value, or a module-owned record. Mapping by field name instead of business meaning can leave the catalog technically populated but commercially incoherent.
PrestaShop Catalog Meaning Begins With Product Structure
PrestaShop Products can be standard Products, Products with combinations, packs, or virtual Products. The Product record also carries associations to Categories, brand and supplier context, images, attachments, related Products, features, customization fields, pricing, stock, languages, and shop scope. These relationships determine how the Product is selected, displayed, governed, and sold.
| Source-side meaning | PrestaShop destination question | Relationship consequence |
|---|---|---|
| One sellable item with no selectable versions | Does it remain a standard Product? | Product identity, reference, price, stock, image, tax, Category, and URL stay at Product level. |
| Size, color, capacity, finish, or another purchasable version | Should attributes create combinations? | Combination identity can own reference, price impact, quantity, image, and selected values. |
| Stable specification such as material or country of origin | Should it become a feature? | The value describes the Product as a whole rather than creating a different purchasable version. |
| Customer-entered text or uploaded personalization | Should it become a customization field or another target structure? | Customer input remains separate from attributes and descriptive features. |
| Group of existing Products sold together | Is it a pack, association, Category, or merchandising relationship? | The target should preserve Product identity and grouping intent without duplication. |
| Module-generated choice or record | Which module or target process owns it? | Core Product fields should not absorb active extension behavior by accident. |
The correct target representation follows what the value does. A “Color” value might create a combination, describe a Product feature, support a Category or filter experience, or exist only as module output. The label alone is insufficient.
Combinations, Attributes, Features, and Customizations Are Not Interchangeable
PrestaShop combinations represent purchasable versions of a Product. They are created from attribute values and can carry their own reference, price impact, quantity, image association, weight impact, availability, and other variation-level data. Features describe characteristics shared by the Product rather than changing which version the customer buys. Customization fields collect customer-provided text or files.
This separation should remain visible in the migrated model:
| PrestaShop structure | Commercial meaning | Common source-to-target error |
|---|---|---|
| Attribute group and value | Selectable dimension such as size or color | Converting descriptive specifications into choices customers must select. |
| Combination | A valid purchasable attribute combination | Flattening real variants into one Product and losing child SKU, price, image, or stock. |
| Feature and feature value | Stable Product characteristic | Turning filterable or comparative specifications into free text. |
| Customization field | Customer-entered text or file | Treating personalization as a fixed attribute value or Order note. |
| Pack | Product relationship that groups existing Products | Duplicating component data or confusing a bundle with a variation. |
| Virtual Product | Non-physical Product with associated delivery meaning | Preserving a file reference without its Product and access relationships. |
A source platform may store child variants as separate Products. PrestaShop may represent them as combinations under one parent Product when they are truly versions of the same item. Conversely, independent Products should not be collapsed into combinations when they have separate merchandising, content, lifecycle, or reporting identities.
Combination generation also depends on the attribute vocabulary. Inconsistent source values such as “Large,” “L,” and “large” should be examined before they become separate target attribute values. However, normalization should not merge values that carry distinct SKUs, prices, stock, or customer-facing meaning.
Categories, Brands, Suppliers, and Associations Shape Discovery
PrestaShop Categories form hierarchical catalog paths and can carry descriptions, images, metadata, friendly URLs, Product associations, and shop context. A Product can be associated with multiple Categories while one Category can serve as its main Category. Brands, suppliers, related Products, accessories, and packs create additional discovery or operational relationships.
Source platforms often mix these roles. A collection may be a real Product family, a seasonal campaign, a brand archive, a filter result, a navigation shortcut, or an SEO landing page. Reproducing every source grouping as a PrestaShop Category can preserve clutter and duplicate intent.
| Source structure | Possible PrestaShop meaning | Decision signal |
|---|---|---|
| Permanent hierarchical family | Category tree | Customers and staff use the hierarchy as a stable catalog path. |
| Brand or manufacturer grouping | Brand relationship, Category, feature, or content page | The destination follows browsing, trust, reporting, and Product-governance needs. |
| Supplier reference | Supplier relationship or external procurement key | The value supports sourcing or administration rather than storefront branding. |
| Seasonal or campaign collection | Temporary Category, merchandising rule, or content landing page | The structure may not deserve permanent catalog hierarchy. |
| Related or accessory Products | Product association | The relationship supports cross-selling without changing Product identity. |
| Bundle of existing Products | Pack or another defined bundle structure | Components remain identifiable and the bundle does not become a fake variation. |
The main Category and friendly URL relationship deserves particular attention because Category context can influence how Product paths are generated and interpreted. A Product can remain assigned to the correct set of Categories while still receiving an unintended primary path if the main relationship is not defined.
Customer Identity and Customer-Group Treatment Must Be Separated
A PrestaShop Customer record carries identity, contact information, addresses, account state, language context, and Order relationships. Customer groups can influence how the Store treats the buyer through discounts, price display, visibility, or other configured behavior. The group is therefore not merely a label.
| Source customer pattern | Target-model question | Relationship outcome |
|---|---|---|
| Ordinary retail account | Which identity, address, language, and Order links remain authoritative? | Customer history remains attached to the correct account. |
| Wholesale or trade buyer | Which group, pricing, tax, visibility, or external account relationship defines treatment? | Buyer identity remains separate from commercial rules. |
| Loyalty or membership segment | Is the value a core group, module record, CRM segment, or historical label? | The target stores only the relationship that will continue to be used. |
| Guest buyer | Should the Order retain identity without creating a normal account? | Historical Order interpretation remains possible without false account continuity. |
| Duplicate Customers | Which record owns the email, addresses, Orders, and external identifiers? | Consolidation decisions do not sever Order relationships. |
A source customer group may have affected prices, tax treatment, catalog access, approval, or communication outside the core Store. Migrating the group name alone does not preserve those outcomes. The target model must state which behavior belongs to PrestaShop configuration, which belongs to a module, and which remains owned by an external CRM or ERP.
Multistore Adds Shop-Specific Ownership to Shared Records
PrestaShop multistore allows one back office to manage multiple shops or shop groups. The migration consequence is that Products, Categories, Customers, content, languages, currencies, URLs, and module behavior may be shared, inherited, or shop-specific. A record count cannot show whether that ownership was preserved.
| Multistore area | Ownership decision |
|---|---|
| Products and combinations | Which shops receive the Product, variation, visibility, price, and quantity context? |
| Categories | Which root tree and shop association govern browse placement? |
| Customers and groups | Which identities and commercial treatments are shared or shop-specific? |
| Languages and localized fields | Which translated names, descriptions, slugs, and metadata belong to each language and shop? |
| CMS Pages and content | Which storefront, language, navigation path, or domain owns the content? |
| URLs and domains | Which shop replaces each important source route? |
| Modules | Which module records or settings apply globally, by shop group, or by individual shop? |
Flattening shop assignments into a default shop can make shared data appear complete while removing brand, regional, language, or B2B/B2C boundaries. The opposite mistake—duplicating every shared record per shop—creates unnecessary divergence and makes future catalog governance harder.
Orders Preserve Transaction Evidence, Not Future Store Configuration
PrestaShop Orders connect Customers or guest identities to Product snapshots, combinations, quantities, prices, discounts, taxes, shipping, payment labels, addresses, messages, status history, and module references. Historical Orders should remain intelligible even when the source workflow has no exact PrestaShop equivalent.
| Order relationship | Meaning in the target record |
|---|---|
| Product and combination line | Purchased name, reference, selected attributes, quantity, and price at the time of sale. |
| Customer or guest identity | Buyer context and relationship to historical account data. |
| Addresses | Billing and delivery snapshots used for the transaction. |
| Discounts and vouchers | Historical effect on the Order rather than automatic recreation of future promotion rules. |
| Payment and carrier labels | Evidence of the original transaction, not proof of active target modules. |
| Status and messages | Historical workflow and service context that may need semantic mapping. |
| Module or external reference | Cross-system key or extension-owned context with a defined target purpose. |
A payment module, carrier, tax rule, email template, or checkout customization is a live target configuration concern. Historical labels can be preserved without pretending that the future workflow has been deployed. This boundary keeps Orders useful for support and finance while preventing transaction history from being confused with operational setup.
Modules, Overrides, Themes, and Custom Data Need Explicit Ownership
PrestaShop’s module and override ecosystem can extend Products, combinations, Customers, Orders, checkout, promotions, Reviews, loyalty, marketplace feeds, SEO, shipping, payment, analytics, and administration. A value displayed in the back office or storefront may therefore come from a core table, a module table, an override, theme logic, or an external system.
| Dependency type | Data-model interpretation |
|---|---|
| Module-owned entity | Identify its parent Product, Customer, Order, content item, or external record and the target module that will consume it. |
| Custom field on a core record | Use a native field or governed extension field only when the target owner is known. |
| Override or custom code | Determine whether it changes storage, calculation, validation, or presentation rather than assuming it is transferable data. |
| Theme field | Separate durable content from source-specific layout or template markup. |
| External identifier | Preserve ERP, CRM, PIM, accounting, marketplace, or fulfillment keys in a governed integration relationship. |
| Cached or derived output | Recreate it from authoritative target data rather than copying stale technical residue. |
Module residue should not be copied simply because it exists. Conversely, a module-owned field that controls Product identity, Customer entitlement, Order interpretation, or integration continuity cannot be dismissed as optional metadata. The target model must identify the continuing consumer.
Content, Languages, and URLs Carry Shop Context
PrestaShop Product, Category, CMS Page, and other content fields can be localized. Names, descriptions, slugs, metadata, and image captions may vary by language and shop. A source platform may instead use separate Stores, duplicated records, translation plugins, or language-specific URLs.
The target model should distinguish shared identity from localized expression. One Product may retain a common reference and relationship structure while its name, description, slug, and metadata vary by language. A translated source record should not become a duplicate Product unless it genuinely represents a separate commercial item.
URLs also need object ownership. A source route may identify a Product, Category, brand page, CMS Page, language path, or shop domain. The target route should resolve to the PrestaShop object and shop context that replace that intent. Friendly URL strings without the correct record, language, and shop relationship are not sufficient.
Target Ownership Should Be Defined Before Field Mapping
A complete PrestaShop target model assigns every important source value to one of these outcomes:
- a native Product, combination, attribute, feature, customization, Category, Customer, Order, content, or shop relationship;
- a governed module or custom field with a continuing target owner;
- an external-system relationship whose stable identifier must remain traceable;
- target configuration or presentation that should be rebuilt rather than migrated as data;
- legacy residue that should be archived or excluded.
| Decision area | Strong ownership question |
|---|---|
| Product variation | Which Product and attribute combination owns SKU, price, quantity, image, and purchasable identity? |
| Product information | Which values are features, descriptions, attachments, or localized content rather than combinations? |
| Catalog discovery | Which Categories, brands, suppliers, associations, and URLs preserve customer intent? |
| Customer treatment | Which group or external relationship governs pricing, visibility, tax, or entitlement? |
| Multistore | Which shop or shop group owns each assignment and localized value? |
| Module/custom data | Which target module, team, or external system will continue to use the record? |
This ownership view prevents PrestaShop from becoming a container for copied source labels. The migrated catalog can instead operate as a coherent set of Product, Customer, Order, content, shop, and module relationships.
Conclusion
PrestaShop data-model differences are concentrated in the separation between Products and combinations, attributes and features, fixed content and customer customization, Customer identity and group treatment, shared records and multistore ownership, historical Orders and future configuration, and core records and module-owned extensions.
A reliable migration preserves those distinctions before fields are mapped. The result is not merely a populated database; it is a target catalog and account structure whose records retain clear commercial meaning across shops, languages, modules, and connected systems.
Common Questions
Why are PrestaShop combinations different from general product options?
Combinations are purchasable versions of a Product created from attribute values. They can own variation-level reference, price impact, quantity, image, weight, and availability. A descriptive feature or customer-entered customization has a different role.
Are PrestaShop features the same as attributes?
No. Attributes create selectable combination dimensions, while features describe stable characteristics of the Product. Confusing them can turn specifications into unnecessary choices or flatten real variations into descriptive text.
How should source variants stored as separate Products be translated?
Determine whether they are genuinely versions of one Product or independent commercial items. Shared identity, common content, selectable differences, SKU ownership, stock, pricing, and lifecycle help determine whether combinations are appropriate.
Why do customer groups require more than label mapping?
A customer group can be connected to discounts, price display, visibility, tax treatment, or module behavior. Preserve the Customer-to-group relationship only together with a clear definition of the commercial treatment that will continue in the target Store.
How does multistore change data mapping?
Multistore adds shop and shop-group ownership to Products, Categories, Customers, content, languages, URLs, and modules. Shared records should remain shared where appropriate, while shop-specific assignments must not be flattened into the default shop.
How should module-owned data be handled?
Trace each module record to its parent object, business meaning, and continuing target consumer. Preserve durable entities and integration keys; rebuild active behavior in the target environment; exclude cached, derived, or obsolete residue without a continuing purpose.