For a move into PrestaShop, begin with the product meaning: combinations represent selectable variations, features describe Products, and customization inputs collect purchase-specific information. Resolve the actual shop context and required relationships before choosing the Next-Cart scope and who will execute its agreed Migration Actions.
Choosing the right migration approach for PrestaShop is not mainly a question of store size. It is a question of interpretation burden. PrestaShop can support structured product combinations, product features, customization fields, category governance, customer groups, multistore capability, friendly URLs, and module-supported flexibility. Those strengths are useful when the merchant knows how the source store should be translated into PrestaShop. They become risky when product logic, customer segmentation, shop scope, module behavior, or custom data remains unclear.
Choose the lightest service arrangement that satisfies the defined PrestaShop data outcome. Standard Migration provides customer-led supported migration; Managed Migration provides expert execution of agreed Migration Actions within that capability. Eligible Add-ons refine supported data, while tailored requirements use Custom Migration with Self-Execute or Expert Handle. The customer supplies business meaning and verifies the final result.
For PrestaShop, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
What Migration Approach Means for PrestaShop
A PrestaShop migration approach defines how much execution support, mapping control, customization review, and validation discipline the project needs. It should not be chosen only from Product, Customer, Order, or Blog Posts volume. Volume matters for planning, but PrestaShop complexity often comes from how records behave after migration.
Products may need to become combinations, features, or customization fields. Categories may affect navigation, SEO metadata, friendly URLs, group access, and multistore root-category planning. Customer groups may carry pricing, access, or segmentation meaning. Modules and overrides may own business logic that ordinary records do not explain. A source store may also contain custom fields, external IDs, ERP references, CRM records, review data, loyalty data, subscription data, or other dependencies outside standard migration behavior.
Do not classify a specification as a combination merely because the source calls it an attribute. A combination can carry its own stock and selling reference; a feature describes the Product. A customization input has purchase and fulfillment meaning. For multistore, identify the installed version, shop or shop-group context and inherited versus local values. Those distinctions define the required representation, not a promise that every structure is supported.
| Approach decision | PrestaShop-specific question |
|---|---|
| Is Standard Migration enough? | Are the required records supported, structured clearly, and easy for the merchant to validate? |
| Is Managed Migration safer? | Is the scope supported and should experts perform the agreed Migration Actions? |
| Are Add-ons enough? | Is the need bounded to supported record filtering, field-value transformation, or field remapping? |
| Is Custom Migration needed? | Does the requirement involve custom fields whose required handling exceeds supported mapping scope, unsupported module data, Custom Platform handling, external IDs, or bespoke transformation? |
| Does launch timing affect the approach? | Will new records, changed configuration, or a refreshed target result require Migration Actions? |
The selected approach should be grounded in representative source examples, not broad confidence. If no one can explain how the difficult products, categories, groups, shop scope, URLs, and module data should behave in PrestaShop, the approach is not ready.
When Standard Migration May Be Enough
Standard Migration can be suitable when the PrestaShop target structure is already clear and the merchant can manage required review tasks responsibly. It is strongest when the source store uses ordinary commerce records, product choices map predictably, categories are clean, customer groups are limited or well documented, multistore is not required or already planned, and module/custom behavior is not central to the migration outcome.
Standard Migration can be the right choice when the customer understands the source structure, can execute supported actions and can verify the PrestaShop result. A limited standard Demo can expose gaps. Add-on and custom output needs agreed paid proof; live purchase behavior, modules and shop configuration retain separate acceptance owners.
| Standard Migration readiness signal | Why it matters in PrestaShop |
|---|---|
| Product combinations are already defined. | Selectable choices can be reviewed without deep reinterpretation. |
| Features are clean and commercially useful. | Product comparison data can be preserved without clutter. |
| Customization fields are simple or not required. | Personalization does not create heavy fulfillment risk. |
| Category tree and URLs are manageable. | Discovery and SEO review remains controlled. |
| Customer groups are limited and documented. | Group meaning can be validated without bespoke logic. |
| Multistore is absent or simple. | Shop assignment does not dominate the project. |
| Modules and custom fields are not business-critical. | Standard records can carry most of the migration value. |
Standard Migration becomes risky when the merchant expects it to resolve unclear source logic automatically. If combinations, features, groups, shop assignments, or custom data need interpretation rather than transfer, a stronger approach should be considered.
When Managed Migration May Be Safer
Managed Migration fits supported PrestaShop scope when experts should perform the agreed Migration Actions. A combination-heavy catalog, many images or several shop contexts may increase execution work without changing the supported capability. Agree the actions and timing, and assign customer owners for the final review.
Expert execution can reduce the customer’s hands-on migration workload. It does not automatically include project management, business interpretation, validation services, module implementation or launch coordination. The customer retains manual access and verifies combinations, price meaning, shop assignments and historical records; broader tasks require explicit agreement.
Managed Migration and Custom Migration answer different questions. Experts can execute supported scope through Managed Migration. Unsupported data, bespoke transformation or changes to migration logic require tailored Custom Migration scope, with its own Self-Execute or Expert Handle choice. Coordination beyond agreed actions requires explicit scope in either arrangement.
| Managed Migration fit signal | What Managed Migration helps with | What it does not automatically solve |
|---|---|---|
| Large supported catalog | Expert execution of the agreed supported Migration Actions. | Unsupported product logic or custom module behavior. |
| Important SEO paths | Execution at the agreed migration stage; the customer owns URL acceptance. | Full SEO strategy, redesign, or external redirect implementation beyond agreed scope. |
| Customer groups need careful checking | Agreed migration execution; the customer verifies group meaning. | Rebuilding unsupported pricing or access logic. |
| Internal team has limited bandwidth | Reduces hands-on migration-operation burden. | Merchant-side business decisions and final approval. |
Managed Migration is safest when the merchant can still define what success looks like. Execution support cannot replace business interpretation.
When Add-ons Are the Right Layer
Add-ons fit PrestaShop migrations when the requirement is bounded, supported, and specific. The four Standard Add-ons follow one fixed processing sequence: Data Filter -> Data Transformation -> Advanced Data Mapping -> Advanced Database Mapping. Each solves a different problem and should be applied only when the exact Source setup, Target support, and requested data structure qualify.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| Standard Add-on | PrestaShop use case | Boundary to protect |
|---|---|---|
| Data Filter | Apply supported data type field conditions to exclude obsolete Products, old Orders, retired Categories, inactive Customers, or content that should not move. | Filtering decides which records continue; it does not solve unclear catalog meaning. |
| Data Transformation | Apply expressions to transform supported labels, statuses, or other field values before later mapping stages. | Expressions are not custom development or module implementation. |
| Advanced Data Mapping | Remap supported source or transformed fields to compatible PrestaShop target fields without changing the value during mapping. | Mapping cannot create unsupported target behavior. |
| Advanced Database Mapping | Route eligible supported data through compatible database tables, fields, or columns when both the exact Source setup and PrestaShop Target role qualify. | Schema, field/column, semantic, and Value Type compatibility must be confirmed; storage does not recreate application behavior. |
A Tailored or Custom Add-on need is not a fifth Standard Add-on. It is reviewed and quoted through Custom Migration when a Standard Add-on function needs project-specific modification or the required Add-on behavior is bespoke.
PrestaShop supports Advanced Database Mapping as Target, but the exact Source setup must also support it. Then verify the eligible data type, table, field, column, semantic meaning and Value Type. A module table or multistore relationship is not qualified merely because it is visible in the database. Storage does not implement the module or its live behavior.
Account for Product price basis
PrestaShop planning must also account for the migration's Product price basis. The verified migration model can interpret the Source Product Price Type as Tax excluded or Tax included, and the Target Product Price Field can likewise be Tax excluded or Tax included.
This is not merely a display preference. The chosen basis determines how a source price is interpreted before it is written into the target price field. A representative review should therefore compare Products across different tax classes and confirm that the selected source basis, target basis, and PrestaShop tax configuration produce the intended sell price. The exact UI selection belongs in Documentation; the migration approach should record the intended price meaning and the evidence that will prove it.
When Custom Migration Should Be Considered
Custom Migration should be considered when the migration requirement exceeds supported standard behavior. PrestaShop’s open-source nature makes this boundary especially important. Many stores rely on modules, overrides, custom fields whose required handling exceeds supported mapping scope, custom database tables, ERP/CRM connectors, tax rules, shipping logic, payment behavior, loyalty systems, reviews, subscriptions, marketplace extensions, or internal reporting IDs. Some of that information may not belong to ordinary product, customer, order, category, or content records.
Custom Migration is the right review path when the project requires tailored handling, not just extra care. The merchant should provide sample records, source evidence, target expectations, and business reasons for the custom requirement.
| Custom Migration trigger | Why it matters for PrestaShop |
|---|---|
| Custom fields or database columns whose required handling exceeds supported mapping | The value may need non-standard interpretation, merging, splitting, bespoke transformation, or a destination that the Standard mapping Add-ons cannot support. |
| Module-owned records | Standard migration may not include data created or stored by modules. |
| Overrides or custom code | Behavior may not be represented as ordinary records. |
| External identifiers | ERP, CRM, accounting, warehouse, loyalty, or reporting continuity may depend on preserved IDs. |
| Complex product logic | Source options may not map cleanly into combinations, features, or customization fields. |
| Multistore transformation | Records may need deliberate assignment across shops, domains, languages, or pricing contexts. |
| Custom Platform source | The source structure itself may require analysis before PrestaShop mapping can be trusted. |
Custom Migration does not automatically mean full target-store setup, app implementation, theme redesign, or integration deployment. It means the migration requirement needs tailored review or non-standard handling within an agreed scope.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete PrestaShop scope.
How Entity Points Affect Planning
Entity Points size counted capacity rather than PrestaShop complexity. Eligible Products, Customers, Orders and Blog Posts consume points on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Features, combination relationships, shop context, modules and other structures still need scope review without becoming additional independently counted Data Types.
For PrestaShop, Entity Points should be considered alongside structure burden. A small store can require Custom Migration if its product choices depend on custom fields whose required handling exceeds supported mapping scope or module behavior. A large store can fit Standard Migration or Managed Migration if the data is supported, the structure is clean, and validation is realistic.
| Planning signal | What it tells the team | What it does not prove |
|---|---|---|
| Product volume | Expected catalog scale and possible Entity Points impact. | Whether combinations, features, customizations, and categories are correct. |
| Customer volume | Buyer-data scale. | Whether customer groups, duplicates, tax status, or B2B-style treatment is usable. |
| Order volume | Historical record volume. | Whether refunds, discounts, order statuses, payment references, and custom fields remain meaningful. |
| Blog Posts volume | Content volume where included in scope. | Whether URLs, redirects, CMS Pages, and navigation are launch-ready. |
Entity Points should support service planning, not replace migration approach selection.
What Demo Migration Should Decide
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed PrestaShop approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
Use the following contexts to select available standard samples and identify requirements that need paid or target-side proof:
| Sample area | Decision it should support |
|---|---|
| Combination-heavy product | Whether attributes and combinations are interpreted correctly. |
| Feature-heavy product | Whether comparison/specification data remains useful. |
| Personalized product | Whether available standard values expose a gap; custom input and fulfillment behavior need agreed paid or target-side proof. |
| Category with SEO value | Whether metadata, friendly URL, visibility, and product assignment are acceptable. |
| Customer group example | Whether available Customer values preserve context; pricing, access and communication rules need separate target acceptance. |
| Multistore example | Whether available shop-context values are clear; multistore configuration and public behavior need separate acceptance. |
| Module/custom-field record | Whether Add-ons, Custom Migration, target setup, or exclusion is needed. |
| Refunded or discounted order | Whether historical order context remains readable. |
Use Demo findings to classify a standard data issue, a supported enhancement, tailored handling or target setup. Unresolved combination or shop meaning should hold the affected scope before Full Migration. Enhanced and custom output requires agreed paid proof; a standard sample cannot establish module behavior or complete launch readiness.
Migration Actions and Launch Timing
PrestaShop launch planning may require later migration activity after a paid migration has produced an earlier result. Demo findings should inform the first paid configuration rather than be treated as an earlier paid result.
Use the three Migration Actions according to the state that should carry forward:
| Migration Action | PrestaShop-specific use | Revalidation focus |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid, including accepted price basis and mappings; choose the source-data window separately. | Validate the later records and representative regression samples under the unchanged rules. |
| Continue the Migration with a New Configuration | Supported data selection, price basis, filters, mappings, Add-ons, or another supported configuration area must change after an earlier paid result. | Validate the changed rule, affected Products or relationships, and representative records previously accepted under the older configuration. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; agree target effects and protect target-owned data. | Repeat the complete acceptance set for catalog, Customers, Orders, content, URLs, multistore context, and agreed special handling. |
Keep Migration Actions separate from the source-data Additional Options. “Continue the previous migration” carries the appropriate previous migration state; it does not independently mean newly added records or updates. The action chooses how configuration is used, while the selected source window determines which records are processed.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records. “Continue the previous migration” applies to the appropriate previous migration state. Neither option is implied by an action name. When configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
Signals That the Approach Is Too Light
A PrestaShop approach is too light when it assumes standard record transfer can solve unclear target meaning. Warning signs should be addressed before Full Migration.
| Warning signal | Likely response |
|---|---|
| Products mix selectable choices, feature values, and personalization fields without a decision model. | Rework catalog scope before proceeding. |
| Customer groups affect price, visibility, or access but are described only as labels. | Strengthen preparation and service-path review. |
| Multistore scope is unclear. | Define shop structure or consider stronger handling. |
| Modules, overrides, or custom fields whose required handling exceeds supported mapping scope own important data. | Review Custom Migration requirements. |
| URL priorities and category landing pages are not ranked. | Add preparation and validation around SEO continuity. |
| Demo Migration findings cannot be classified. | Pause before Full Migration and refine scope or service path. |
Choosing a stronger approach is not about making the project heavier than necessary. It is about matching the support path to the parts of PrestaShop that actually create business risk.
Conclusion
The PrestaShop approach should follow combination identity, descriptive features, purchase customization and actual shop context. Standard Migration is customer-led supported execution; Managed Migration supplies expert execution of agreed actions. Eligible Add-ons refine supported values, while tailored requirements use Custom Migration with Self-Execute or Expert Handle.
Use representative records to define the required destination meaning, then distinguish available standard Demo evidence from paid proof for enhanced or custom output. Assign modules, multistore setup, live pricing and purchase acceptance to their owners. The approach is ready when scope, execution and final verification are explicit.
Common Questions
When is Standard Migration enough for a PrestaShop migration?
Standard Migration fits when the required records and destination representation are supported and the customer can execute the available actions and verify the result. Define combinations, features and shop context first. Use limited standard Demo evidence, with separate paid proof for enhancements or customization and target checks for live behavior.
When should Managed Migration be considered for PrestaShop?
Choose Managed Migration for supported PrestaShop scope when experts should execute the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result. Broader coordination, validation services, module work or launch management must be agreed explicitly.
How are Add-ons different from Custom Migration in a PrestaShop migration?
Standard Add-ons provide supported filtering, expression-based transformation and compatible mapping. Advanced Database Mapping requires both exact Source support and PrestaShop Target support, then eligible compatible schema. Custom Migration handles requirements outside that scope and can use Self-Execute or Expert Handle; a custom field alone does not make a project custom.
What should Demo Migration prove for PrestaShop before Full Migration?
Demo can inspect limited available standard samples and reveal gaps in combinations, features, Customer context, Orders and content. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded. Enhanced or tailored output requires agreed paid proof; modules, live purchase behavior and multistore operation require separately owned checks.
When are Migration Actions relevant?
The first paid run uses Perform a New Migration. Either continuation requires an earlier paid migration and uses its saved configuration or an intentional new configuration. Select the source-data window separately: newly added records are different from edits to existing records. Review combined output and agree target effects without assuming protected data is erased.
What evidence should be prepared for Custom Migration review in a PrestaShop migration?
Prepare PrestaShop examples that expose custom columns, module-owned records, and behavior created by overrides or custom code. For every requirement, identify the business purpose, target representation, module or system owner, and evidence that will prove the agreed Custom Migration outcome.
Should combinations, features and customization inputs be treated as the same product data?
No. Combinations represent selectable variations with selling and stock meaning; features describe Products; customization inputs collect purchase-specific information. Identify the required target representation and confirm supported handling. Matching source labels alone can preserve text while losing the intended selling or fulfillment meaning.
Does database access make every PrestaShop multistore or module requirement standard?
No. Advanced Database Mapping still requires both role gates and eligible compatible schema. Shop context, relationships and module ownership need explicit review. Database storage does not configure multistore behavior or implement a module; unsupported extraction or tailored interpretation requires agreed Custom Migration scope.