When evaluating PrestaShop as a prospective Target Platform, the critical question is whether a source relationship keeps its commercial scope. A combination, Customer group or shared Product can look complete while stock, price or access belongs to a different shop or module.
PrestaShop migration risk is concentrated in structures that can preserve visible records while losing commercial scope. Products can exist while combinations no longer carry the correct reference, stock, price, image, or minimum quantity. Features can be confused with sellable choices. Customer groups can retain names while prices and access rules disappear. Multistore can copy Products and Categories into the wrong shop context. Modules and overrides can hide active data outside standard resources.
A strong risk analysis follows the complete chain from source assumption to platform constraint, migration consequence, operational impact, mitigation direction, affected owner, and control signal. The objective is not to list PrestaShop features but to expose where seemingly complete migration results can still create operational failure.
Product Combinations Can Be Misclassified or Partially Reconstructed
PrestaShop combinations represent purchasable variants of standard Products; packs and virtual Products require different treatment. Combinations can carry references, supplier references, barcodes, price and weight impacts, minimum quantity, availability dates, low-stock settings, images and option-value associations. Their stock must also retain the associated Product, combination and shop or shop-group context, including out-of-stock policy. A source platform may store child SKUs as independent Products, modifiers or an application-owned matrix.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Every source Product option can become a PrestaShop combination. |
| Platform constraint | Combinations are sellable child records with their own commercial and inventory fields; not every source option creates that identity. |
| Migration consequence | False combinations are created, real child SKUs collapse into the parent, or combination-level values are lost. |
| Operational impact | Buyers select unavailable items, stock and price attach to the wrong record, and fulfillment or ERP reconciliation fails. |
| Mitigation cue | Classify source values as combination-defining options, customization inputs, descriptive features, or module-owned logic. |
| Affected owners | Catalog governance, merchandising, inventory, fulfillment, supplier management, and integrations. |
| Control signal | Representative Product families retain the intended combinations, references, prices, quantities, images, and unavailable states. |
The risk is highest when the source has invalid option combinations or separately managed child identifiers. A complete option vocabulary does not prove that the correct combinations were reconstructed.
Features, Attributes, and Customizations Can Lose Their Distinct Purpose
PrestaShop distinguishes Product features from Product options and combinations. Features describe Products and can support comparison or filtering; option values participate in combinations; customization fields can collect text or files for a particular purchase. Source platforms often mix these meanings in one attribute table.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | One source attribute can be copied into one PrestaShop field type. |
| Platform constraint | Features, combination attributes, and Product customizations have different owners and lifecycles. |
| Migration consequence | Descriptive values become buyable combinations, personalization is lost, or filters become inconsistent. |
| Operational impact | Shoppers cannot compare or configure Products correctly, and Order lines lack required customization evidence. |
| Mitigation cue | Classify each source field by whether it describes the Product, defines a combination, or captures one-time Customer input. |
| Affected owners | Catalog, search, merchandising, fulfillment, Customer service, and Product-data teams. |
| Control signal | Representative Products show correct feature values, combination choices, and Order-linked customization data. |
A text field used for engraving should not become a reusable feature. Likewise, a technical specification should not multiply the combination grid merely because the source called it an option.
Category and Friendly-URL Continuity Can Break Despite Complete Records
PrestaShop Categories contain hierarchy, names, descriptions, images, position, shop context, and link rewrites. Friendly URLs also depend on shop URL configuration, route patterns, languages, and web-server rewriting. A source Category can simultaneously act as navigation, SEO landing page, internal grouping, or campaign collection.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Migrated Categories and slugs recreate discovery and route continuity. |
| Platform constraint | Category hierarchy, shop assignment, navigation, content, language, link rewrite, route pattern, and redirect ownership are separate. |
| Migration consequence | Categories appear in administration but resolve under the wrong shop, language, path, or weak destination. |
| Operational impact | Organic traffic, merchandising journeys, internal links, and Customer navigation decline. |
| Mitigation cue | Separate durable taxonomy from menu placement and campaign content, then map each priority source URL to the intended PrestaShop destination. |
| Affected owners | SEO, merchandising, content, regional teams, and platform administration. |
| Control signal | Priority Category and Product routes resolve uniquely in the correct shop and language with preserved intent. |
A copied link_rewrite value is not sufficient when the target shop uses a different domain, virtual path, language prefix, or route configuration.
Customer Groups Can Preserve Labels but Lose Commercial Meaning
PrestaShop Customer groups can participate in prices, discounts, Category visibility, payment or shipping behavior through modules, and other commercial rules. A source “wholesale,” “VIP,” or “dealer” field may be a true pricing group, a marketing segment, a company classification, or an external CRM label.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Migrating Customer group names preserves buyer treatment. |
| Platform constraint | Group membership has value only through its Product prices, discounts, visibility, tax, module, or shop relationships. |
| Migration consequence | Customers keep the expected label but receive public prices, wrong access, or incomplete account treatment. |
| Operational impact | Margin, B2B relationships, compliance, and Customer trust are affected. |
| Mitigation cue | Model each group through the commercial outcomes and shop scope it controls, not as a standalone Customer field. |
| Affected owners | B2B sales, pricing, finance, tax, Customer service, marketing, and CRM. |
| Control signal | Representative Customers in each important group receive the intended prices, visibility, and commercial context. |
Group price display is separate from the applied tax treatment. Category-specific group discounts depend on the Product’s default Category, so secondary membership is insufficient. Specific-price priorities can also depend on group, currency, country and shop. Pricing and tax owners need representative buyer outcomes across those contexts; a copied group label or tax-inclusive display does not establish the intended charge.
Historical Order prices remain transaction evidence and should not be used to infer the current Customer-group rule.
Multistore Context Can Hide Assignment and Inheritance Errors
PrestaShop multistore can manage several front offices through shop groups and shops. Changes can apply to all shops, a shop group, or one shop, and shops can use different URLs, themes, Products, Categories, prices, languages, or branding. Configuration records can also carry shop or shop-group scope.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Every source Store maps directly to one PrestaShop shop and can share the same records safely. |
| Platform constraint | Shop groups, shops, context selection, shared data, per-shop overrides, URLs, and configuration scope determine ownership. |
| Migration consequence | Products, Categories, prices, Customers, content, or settings are duplicated, shared unintentionally, or assigned to the wrong shop. |
| Operational impact | Regional assortments, B2B/B2C separation, branding, pricing, and administration become inconsistent. |
| Mitigation cue | Define which records are global, shop-group shared, or shop-specific before assigning migration scope. |
| Affected owners | Regional commerce, catalog, pricing, content, finance, Customer service, and platform administration. |
| Control signal | Representative records show the intended ownership and inheritance in each shop context. |
Shop-group sharing is a configuration decision: Customers and available quantities can be shared, while shared Orders depend on both. Inventory and account owners must agree which relationships are shared and which remain shop-specific. Reconciliation in each affected shop exposes unintended sharing that a default-shop comparison misses.
Multistore risk can remain hidden because the default shop appears correct while secondary shops inherit or omit values unexpectedly.
Historical Orders Can Lose the Evidence Needed by Service and Finance
PrestaShop Order history can involve Order details, Customers or guests, addresses, carriers, cart rules, invoices, payments, slips, states, messages, and customization records. Those resources explain the transaction but do not configure current payment, shipping, tax, or promotion behavior.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Order headers, totals, and statuses are enough to preserve history. |
| Platform constraint | Service and finance depend on line details, combination references, customization, addresses, payments, invoices, carriers, cart rules, state history, and refunds. |
| Migration consequence | Orders exist but cannot explain the purchased configuration, adjustment, payment, shipment, or return. |
| Operational impact | Customer service and finance rely on the legacy Store, reconciliation slows, and dispute handling weakens. |
| Mitigation cue | Preserve the historical snapshot and its related evidence while separating it from current checkout configuration. |
| Affected owners | Customer service, finance, fulfillment, tax, compliance, and reporting. |
| Control signal | Representative guest, customized, discounted, refunded, and multi-shop Orders remain understandable without reconstructing current rules. |
A familiar status label can also hide different lifecycle meaning. The target history should preserve what happened, not merely the name of the source state.
Modules, Overrides, and Custom Resources Can Hide Active Business Logic
PrestaShop modules can add entities, custom tables, hooks, configuration, webservice resources, payment or shipping methods, content and automation. PHP class and controller overrides are exclusive and can conflict when modules seek the same override. Theme overrides replace module templates or assets and introduce separate rendering dependencies. Copying visible data preserves neither kind of implementation.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Module fields and visible outputs can be moved into ordinary PrestaShop records. |
| Platform constraint | Modules and overrides can own data, behavior, templates, hooks, webservice resources, and exclusive class or controller changes. |
| Migration consequence | Values are copied without the module entity, hook, override, or update process that interprets them. |
| Operational impact | Payments, shipping, loyalty, subscriptions, marketplaces, content, reporting, or automation fail. |
| Mitigation cue | Identify the module or override, parent record, target owner, continuing consumer, and stable identifier for each active dependency. |
| Affected owners | Developers, application owners, operations, finance, marketing, and integrations. |
| Control signal | Every business-critical module or override dependency has one documented target owner and functioning relationship. |
A replacement module with a similar purpose is not automatically compatible with the source data schema. The entity and lifecycle must match.
Themes and Storefront Presentation Can Mask Missing Data Relationships
PrestaShop themes can override module templates and assets, while modules and hooks provide dynamic storefront content. Product cards, Category pages, faceted search, menus, badges, and checkout blocks may depend on theme-specific templates, JavaScript selectors, or module output. Copying Products and CMS content does not reproduce those presentation relationships.
| Risk-chain element | PrestaShop-specific interpretation |
|---|---|
| Assumption | Migrated records will appear correctly once the target theme is enabled. |
| Platform constraint | Themes, module templates, assets, hooks, selectors, layouts, and data fields jointly determine storefront presentation. |
| Migration consequence | Fields exist but are not rendered, Product cards omit important data, filters or blocks disappear, or custom markup conflicts. |
| Operational impact | Conversion, accessibility, content operations, and merchandising quality decline. |
| Mitigation cue | Separate durable commerce data from presentation dependencies and identify every field or module output the target storefront must consume. |
| Affected owners | Design, frontend development, merchandising, content, marketing, and accessibility. |
| Control signal | Priority storefront components render the intended Product, Category, content, and module-owned data without relying on obsolete overrides. |
This is a structural risk rather than a request to preserve the old theme. The control is a clear contract between target data and presentation.
PrestaShop Risk Ownership Must Follow Shop and Module Scope
| Risk domain | Primary owner | Supporting owners | Control signal |
|---|---|---|---|
| Combinations and features | Catalog governance | Inventory, fulfillment, search | Sellable and descriptive structures remain distinct. |
| Categories and URLs | Merchandising and SEO | Content, regional teams, platform administration | Priority routes preserve shop and language intent. |
| Customer groups | B2B or pricing | Finance, tax, CRM, support | Commercial treatment follows group and shop scope. |
| Multistore | Platform administration | Regional commerce, catalog, content | Global and shop-specific ownership is explicit. |
| Orders | Customer service and finance | Fulfillment, tax, reporting | Historical evidence remains traceable. |
| Modules and overrides | Application owners | Developers and consuming teams | Every active dependency has a continuing owner. |
| Themes | Frontend ownership | Merchandising, content, accessibility | Target presentation consumes the intended data. |
PrestaShop risk is controlled only when shop context and module ownership are explicit. Record counts cannot show whether those relationships remain operational.
Conclusion
PrestaShop migration risk concentrates in combinations, features, Category and URL context, Customer groups, multistore scope, historical Orders, modules, overrides, and theme dependencies. These structures can preserve visible records while losing the scope or behavior that made them useful.
Each material risk needs a complete chain from assumption through platform constraint, consequence, impact, mitigation, owner, and control signal. That chain makes hidden shop and module dependencies governable rather than leaving them to appear after launch.
Common Questions
Why can PrestaShop combinations migrate incorrectly even when options are present?
A combination is a sellable child record with its own reference, price and weight impacts, images and option-value associations. Its stock also has Product, combination and shop or shop-group scope. Copying option labels or one parent quantity does not reconstruct those relationships.
What is the risk of confusing PrestaShop features with attributes?
Features describe Products, while attribute values participate in combinations. Mixing them can create false variants, weaken filtering, or remove the values that identify the purchased item.
Why is PrestaShop multistore a major migration constraint?
Products, Categories, prices, content, Customers, URLs, and configuration can have global, shop-group, or shop-specific ownership. A correct default shop can hide errors in secondary shops.
Do migrated Customer groups preserve B2B or wholesale behavior automatically?
No. Group names have value only when their pricing, discounts, visibility, tax, module, and shop relationships are also represented.
Why are PrestaShop modules and overrides separate risks?
Modules can own tables, entities, hooks, webservice resources and custom behavior. PHP class/controller overrides can conflict, while theme overrides create separate template and asset dependencies. Visible values do not reproduce the implementation or its continuing consumer.
Who should own PrestaShop migration risk?
Ownership should be assigned across catalog, regional commerce, pricing, Customer service, finance, SEO, frontend, developers, and module owners, with one primary owner for each risk chain.
Does assigning a PrestaShop Customer group preserve every price and tax outcome?
No. Price display is separate from applied tax treatment, category-specific group discounts depend on the default Category, and specific prices can depend on buyer and shop context. Preserve those relationships and verify the intended charge for representative Customers rather than relying on the group name.