A source field called “option” can become a purchasable PrestaShop combination, a descriptive feature, or a Customer customization. Those destinations carry different identity, price, stock, and Order relationships. When PrestaShop is the prospective Target Platform, the useful starting point is the business meaning of the source value and the record that should own it.
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.
Native identity also needs a separate relationship from business references. A Product and its combinations have distinct target identities; a reference or supplier reference is not the same thing as either identity. An ERP key can identify the parent, the sellable combination, or the supplier relationship. Preserving its text at the wrong level can break matching even when every reference is present.
A pack connects an offer to component Products and quantities. Its composition does not determine which stock balance changes: the configured stock treatment can use the pack, its components, or both. A pack therefore needs both component relationships and an explicit quantity owner; a related-Product link or a combination cannot stand in for that model.
Product Price Basis Is a Separate Translation Decision
PrestaShop Product pricing must preserve not only the numeric amount but also what that amount represents. The Source Product price can be interpreted as Tax excluded or Tax included, and the Target Product price field can likewise be treated as Tax excluded or Tax included. Those are separate source-interpretation and target-placement decisions.
A numerically identical value can produce the wrong storefront price when its tax basis is misread. Source price interpretation, target price placement, and the configured PrestaShop tax treatment are separate parts of the amount’s meaning. A combination price impact adds another layer, while a Specific Price applies only within its defined buyer or group, country, currency, quantity, and time context. One displayed price cannot replace all of those relationships, and an Order line retains the amount agreed at purchase rather than inheriting today’s rule.
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.
Group membership and the default Customer group are also distinct. A Customer can belong to several groups while one is the default; flattening that structure into a single label loses information. The Product’s default Category matters to group-specific Category discounts as well, so the same Category memberships can produce a different commercial result when the default relationship changes. These rules remain target configuration with a defined Customer and Product context.
Customer profile data does not establish usable authentication by itself. Password continuity depends on the exact supported Source-to-Target path and the account configuration; other paths need activation, an invitation, reset, or first-login handling. Neither a Customer group nor a copied password-like value proves continuity.
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. Customer sharing, available-quantity sharing, and Order sharing are separate shop-group relationships whose dependencies depend on the selected generation and configuration. Shared catalog identity should therefore remain distinct from the shop or group that owns prices, quantity, account access, and transaction context.
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 common references and relationships while names, descriptions, slugs, and metadata vary by language and shop. A feature definition and value can likewise be shared vocabulary while the Product assignment gives them meaning. 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.
Multistore, Multilingual, and Product-Relationship Scope
PrestaShop can carry Product and content meaning across multiple shops and languages while also maintaining relationships among Products. These dimensions interact: the same Product can have shop assignments, localized values, combinations, Categories, and related-Product context that should not be flattened into one global record.
Shop and language scope are part of a relationship’s identity. A localized value belongs to the corresponding target language and shop; an accessory or related-Product reference belongs to the intended target Product, not merely to a matching translated name. Platform capability does not establish that a selected migration path carries every relationship or shop-specific module field. The accepted model must retain those distinctions within the supported scope.
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 carry variation references, price and weight impacts, quantity, images, and availability. Descriptive features and Customer-entered customizations serve different purposes; neither automatically creates a separate stock-bearing combination.
Are PrestaShop features the same as attributes?
No. Attributes supply selectable combination dimensions, while features describe Product characteristics. The field label does not decide its role: “color” could be a buying choice for one Product and a descriptive feature for another. Preserve the definition, value, and Product assignment without turning every specification into a choice.
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 define discounts, price display, visibility, or module-owned treatment. Customers may belong to several groups with one default group. Preserve membership and default meaning separately, together with the rule that uses them; copying group names does not create commercial behavior or a company hierarchy.
How does multistore change data mapping?
Multistore adds shop and shop-group context to shared records. Product identity, shop assignments, localized fields, price and quantity ownership, Customer sharing, and Order context are separate relationships. Their sharing rules depend on the selected generation and configuration; neither flattening everything into one shop nor duplicating everything preserves that meaning.
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.
How should Product relationships be handled in PrestaShop migration?
Accessories, related Products, and comparable merchandising links are relationships between Product identities. Their target references must resolve to the intended Products within the shop and language scope. Platform support for a relationship does not prove that the selected migration path carries it or that a theme displays it; data ownership and storefront consumption remain separate.
Does a PrestaShop price value preserve the same selling price in every context?
No. The amount needs its source and target tax basis, and its owner may be the Product base price, a combination impact, or a scoped Specific Price. Buyer or group, country, currency, quantity, and time conditions can change the effective price. A historical Order amount is a transaction snapshot, not a rule for future selling.