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 Product variants. They can carry references, supplier references, barcodes, quantity, price and weight impact, minimum quantity, availability dates, low-stock settings, images, and associations with Product option values. 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. |
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. |
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. Overrides can replace classes, controllers, templates, CSS, or JavaScript. Theme overrides can change module rendering without changing the underlying module data.
| 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, quantity, price and weight impact, images, and option-value associations. Copying option labels does not reconstruct the correct child combinations or their commercial fields.
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?
They can own tables, entities, hooks, templates, webservice resources, and custom behavior. Visible field values do not reproduce the code and relationships that interpret them.
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.