PrestaShop preparation starts with shop context: the same Product or Customer identifier can participate in different shop assignments, localized values, or commercial rules. Preserve those relationships before cleaning or consolidating the Source Store. The intended PrestaShop environment needs evidence for what is shared, what remains shop-specific, and which implementation will consume each record.
PrestaShop preparation must document both the commerce records and the shop context in which those records operate. Products can depend on combinations, attributes, features, customization fields, suppliers, manufacturers, Categories, images, stock, customer groups, languages, currencies, and multistore assignments. Customers and Orders can also differ by shop, group, carrier, module, currency, tax, and historical status.
Every preparation task should identify the owner, evidence artifact, and ready condition. The package should separate source records from target configuration: historical Orders, Product combinations, Customer groups, shop assignments, URLs, and module-owned data belong to migration readiness, while live carrier, payment, tax, theme, email, and checkout behavior remains target-side implementation.
Source access, evidence and recovery
Identify the actual Source Platform separately from the intended PrestaShop installation. For a PrestaShop Source, confirm back-office, permitted hosting/database/filesystem, image/download, cron, Webservice, module, and connected-service access. Preserve the version, PHP/database environment, database prefix, theme, languages, currencies, shops, modules, overrides, custom code, and original identifiers. For another Source, collect equivalent relationships without inventing PrestaShop IDs. Record the intended destination version, deployment, multistore configuration, compatible enabled modules, theme consumers, and implementation owners separately.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; PrestaShop administrator when PrestaShop is the Source | Working account and permission summary | For a PrestaShop Source, Products, combinations, Customers, Orders, shops, modules, and configuration can be inspected. Another Source provides access to its own selected records. | Actual Source administration. PrestaShop back-office access applies when that installation is the Source; intended Target administration is confirmed separately. |
| Create recoverable backups | Source infrastructure or platform-recovery owner | Dated actual Source backups or exports and available files/images/downloads, coverage, limits, protected location and recovery owner; native database/filesystem archives where available | Required Source evidence is recoverable under the declared method; full-Store restoration limits are explicit. Resolve a required recovery gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery method and available artifacts. Another hosted Source need not expose a database or filesystem, and a partial export does not prove full Store restoration. |
| Record the technical environment | Source technical owner; intended Target build owner separately | Actual Source software and component inventory; for a PrestaShop Source, PrestaShop, PHP, database, theme, module, override, and deployment details where applicable | Version-dependent data and customizations are documented. | Actual Source versions/components. Native PrestaShop/PHP/database details are conditional on that environment; intended Target deployment and module compatibility are independently assessed. |
| Capture actual Source interfaces and integration access | Source and continuing integration owners | Actual Source interface/permission owners and available resources; for a PrestaShop Source, Webservice key owner and access status, allowed resources, external endpoints, and identifier maps | Continuing systems and available source interfaces are known. | Actual Source interfaces and continuing systems. PrestaShop Webservice evidence applies only when used by that Source; interface availability does not establish selected migration-path coverage. |
| Preserve source identifiers | Data owner | Actual Source storefront/context, Product/choice, Customer, Order, address, classification, application and external keys; shop, combination, Category and module IDs where present in that Source | Cross-table and cross-system relationships can be reconciled. | Actual Source identifiers and context only. Do not invent PrestaShop shop or combination IDs for another platform; proposed destination relationships are recorded separately. |
Record the recovery method available in the actual Source: evidence date, included records/files, remote assets, missing areas and responsible owner. Preserve PrestaShop database, filesystem, image and download archives where the Source permits them; another hosted Source may provide exports/files or managed recovery instead. A partial archive can recover selected evidence without restoring the complete Store. Resolve, agree exclusion or hold a required coverage gap before cleanup or execution.
Do not delete inactive modules, overrides, or old fields until their data ownership has been reviewed. An inactive component can still own historical Product, Customer, or Order records.
Define Multistore, Shop Group, Language, and Currency Scope
PrestaShop multistore can apply data and settings at all-shops, shop-group, or individual-shop context. Customer, quantity, and Order sharing are separate controls; Order sharing depends on Customer and quantity sharing. Preserve the actual group settings rather than inferring them from a shared Customer. Products, Categories, prices, languages, carriers, modules, and URLs can still vary by context.
| Scope area | Evidence to prepare | Ready condition |
|---|---|---|
| Shop tree | Shop-group IDs, shop IDs, names, status, default shop, domains, and physical URI | Every storefront context is listed once. |
| Shared-data settings | Customer sharing, Order sharing, quantity sharing, and group-level rules | Shared identities are distinguished from duplicated records. |
| Product/shop assignments | Product and Category availability, shop-specific status, price, text, and images | Product presence is not inferred from the default shop alone. |
| Language and currency | Shop assignments, translations, default language, currency, exchange context, and fallbacks | Localized records remain tied to the intended shop. |
| URL context | Domain, subdomain or path, SSL domain, physical URI, virtual URI, and main URL | Every public shop has a complete route identity. |
Record which shops should remain separate, which will be consolidated, and which historical shop identifiers must remain on Customers or Orders. This decision should exist before duplicate Products or Customers are normalized.
Prepare Products, Combinations, Attributes, and Features
PrestaShop distinguishes Products from combinations. Attributes and attribute values generate combinations, while features describe characteristics that do not create a variation. Combination-level records can carry references, supplier references, barcodes, price impact, weight impact, quantity, minimum quantity, availability dates, images, and default-combination status.
| Catalog pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple Product | Product ID, reference, type, price, tax group, stock, Category, manufacturer, supplier, images, and shop assignments | The Product can be interpreted without hidden combination data. |
| Product with combinations | Product ID, combination IDs, attribute values, references, price/weight impacts and base values, stock, images, and default combination | Every sellable combination is traceable independently. |
| Product feature | Feature, value, language, Product assignment, filter or comparison use | Descriptive information is separated from buyable choices. |
| Pack or virtual Product | Component/file relationships, quantities, access rules, and Order examples | Non-simple Product behavior has complete source evidence. |
| Supplier/manufacturer relationship | IDs, references, Product links, purchase context, and external keys | Brand and procurement ownership remain distinct. |
| Multi-shop Product | Shop assignments, shop-specific values, Categories, prices, and status | Shop context is preserved rather than flattened. |
Include inactive, online-only, unavailable, discontinued, out-of-stock, pre-order, minimum-quantity, and date-limited cases. These states need an explicit destination decision rather than automatic normalization.
Prepare Customizations, Specific Prices, Stock, and Customer Groups
Customization fields can collect text or file input and remain attached to a Product and later to an Order line. Record the field type, required state, labels, files, assignments, and intended input consumer. Specific prices can depend on Product, combination, shop, currency, country, customer group, Customer, quantity, and date range. Preserve those qualifiers, the reduction type, and priority together. Stock can belong to a Product or combination and may be shared across shops; retain the quantity authority and the actual minimum-quantity and out-of-stock settings independently.
| Commercial structure | Evidence | Ready condition |
|---|---|---|
| Customization field | Field ID, Product, type, required state, label, uploaded-file location, and Order-line example | Buyer-entered data remains distinct from reusable Product attributes. |
| Specific price | Product/combination, shop, currency, country, group, Customer, quantity, date, reduction type, and priority | Every conditional price has complete context. |
| Product price basis | Whether the Source Product price is interpreted as Tax excluded or Tax included, plus the intended target price basis | Representative Products reconcile to the expected storefront price under the configured PrestaShop tax rules. |
| Customer group | Group ID, members, default-group use, price display, reduction, Category access, and shop assignment | Group meaning is documented beyond its name. |
| Stock | Product/combination ID, shop or shared quantity context, timestamp, reserved state where available, minimum quantity, out-of-stock rule, and external authority | The sellable-unit and shop context for each quantity are known. |
| Cart rule | Code, conditions, actions, restrictions, dates, usage, and historical Order references | Historical discount evidence is separated from future promotion setup. |
Historical Order prices and discounts should remain snapshots. They should not be reconstructed from current specific prices, groups, or cart rules. For current catalog pricing, document the Source Product price basis as Tax excluded or Tax included, document the intended target price basis separately, and select representative Products whose final storefront prices can be reconciled against the configured PrestaShop tax rules.
Prepare Categories, CMS Pages, Friendly URLs, and Discovery Paths
PrestaShop Categories can have parent-child hierarchy, shop assignment, localized names and descriptions, images, metadata, friendly URLs, group access, and Product membership. CMS Pages and Categories can provide legal, service, and editorial content. Navigation modules and theme structures can create additional discovery paths.
| Storefront area | Evidence to prepare | Ready condition |
|---|---|---|
| Category hierarchy | Category IDs, parents, shop assignments, access groups, Product membership, and translations | Taxonomy and access scope are complete. |
| Product and Category URLs | Friendly URL, shop, language, canonical intent, metadata, and priority | High-value routes have explicit destination decisions. |
| CMS content | CMS Page/Category IDs, language, shop assignment, status, route, and menu relationship | CMS content remains separate from theme presentation. |
| Navigation | Menu module, links, hierarchy, shop/language context, and destination object | Customer paths are not assumed from Categories alone. |
| Internal links and redirects | Source page, linked object, old path, and destination intent | Links can be rewritten and priority paths retained. |
Collect priority URLs from analytics, search data, backlinks, campaigns, Customer emails, and internal navigation. A sitemap alone will not reveal every route that has commercial value.
Prepare Customers, Addresses, Orders, and Historical Documents
Customer preparation should include account identity, default and additional groups, shop context, language, addresses, consent, company or tax information, external IDs, and authentication dependencies. Record the exact Source-to-Target password-verification decision or required reset, activation, SSO, or first-login handling, with identity and communication owners. Order preparation should preserve the Customer or guest context, cart, currency, shop, carrier, payment module, addresses, Product and combination lines, customizations, totals, statuses, invoices, delivery slips, messages, refunds, and external references. Historical snapshots must not be recalculated from current rules. Identify email, payment, stock, fulfillment, and module events that the import plan must contain.
| Record area | Evidence | Ready condition |
|---|---|---|
| Customer account | Customer ID, email, shop, default/additional groups, language, status, addresses, consent, and external ID | Duplicate and shared accounts are resolved deliberately. |
| Authentication | Password scheme, SSO/social login, reset path, and account communication owner | Account access is planned without assuming credential portability. |
| Order lines | Product/combination references, snapshot labels, customizations, quantity, price, tax, and discount | Purchased items remain understandable independently of current catalog data. |
| Order totals and state | Currency, subtotal, shipping, discounts, taxes, final total, current state, and history | Historical commercial meaning can be reconciled. |
| Documents and after-sale records | Invoice, delivery slip, credit slip, return, message, payment, carrier, and tracking references | Support and finance evidence is recoverable. |
| External IDs | ERP, marketplace, accounting, payment, and fulfillment keys | Cross-system lineage remains traceable. |
Select guest, registered, multi-group, multi-shop, combination, customized, discounted, refunded, returned, and partially shipped Orders as representative cases.
Inventory Modules, Overrides, Themes, and Custom Tables
Create an ownership ledger for modules, overrides, themes, custom controllers, custom tables, direct database changes, Webservice integrations, feeds, marketplaces, search, loyalty, payment, shipping, subscription, and ERP/PIM/WMS/CRM connections.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| Module | Name, version, status, purpose, configuration owner, tables/fields, hooks, and affected records | Module-owned data has a destination or retained owner. |
| Override or custom code | Class/controller override, modified behavior, database impact, and responsible developer | Business logic is documented separately from the old implementation. |
| Theme | Theme version, templates, module positions, embedded content, custom scripts, and route dependencies | Presentation is separated from portable content and records. |
| Custom table or column | Schema, keys, referenced core records, and consuming process | Custom records can be interpreted rather than copied blindly. |
| External system | Endpoint, authoritative entities, synchronization direction, IDs, and cutover owner | Competing systems of record are avoided. |
| Generated data | Cache, index, logs, sessions, temporary exports, and abandoned tables | Non-authoritative data is excluded deliberately. |
If the same feature exists in several shops, record whether the underlying module data is shared, duplicated, or context-specific.
Confirm PrestaShop Target implementation prerequisites
The intended installation must consume the agreed shop, catalog and commercial relationships. A Source Customer or Product ID does not settle whether the destination shares that record across shops, and a price amount does not settle its tax or conditional-price meaning. Confirm the intended representation and compatible consumers before execution, preserving historical shop context and values separately from future configuration.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended installation and access | Target technical owner | PrestaShop version/deployment, administration, compatible required modules/theme consumers, available hosting/storage access and recovery responsibilities | The intended installation and required components are available to their owners. |
| Prepare multistore and public context | Target commerce and site owners | Shops/groups, sharing controls, Product/Customer assignments, language/currency scope, domains/URIs and explicit consolidation or separation decisions | Shared and shop-specific relationships have a declared Target model; common identifiers alone do not establish sharing or route scope. |
| Prepare catalog, price and stock representation | Target catalog, pricing and inventory owners | Real combinations and defaults, attributes/features/customization inputs, pack/file relationships, specific-price qualifiers, Source and Target tax basis, quantity authority and shop context | Required sellable and commercial relationships have usable representations without rewriting historical prices or identities from current rules. |
| Confirm account, content and field consumers | Target identity, content and site owners | Customer/group/address and authentication decisions, CMS/navigation/routes, images/downloads, customization files, field definitions and consuming modules/themes | Required account, content, file and discovery relationships have compatible consumers and explicit access treatment. |
| Assign module and continuing-operation ownership | Target development, operations and integration owners | Module/override/custom-table consumers, external keys/authorities, future carrier/payment/tax/email/checkout behavior and historical/test containment decisions | Required custom data has a usable owner; historical imports cannot replay charges, messages, stock changes or fulfillment. |
Select Representative Migration Test Samples
Choose source records that expose the Store’s real complexity. Record original IDs and values, shop context, language, URLs, combination references, Customer groups, module dependencies, intended destination representation, agreed exclusions, and why each sample was selected. Preserve dated untouched exports and related files, with their coverage and recovery owner; keep approved normalization decisions in a separate source-to-intended ledger.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, tax basis, stock, Category, manufacturer/supplier, images, shop, and Order | Establishes the ordinary Product baseline and confirms whether Tax excluded or Tax included price interpretation produces the expected storefront result. |
| Combination-heavy Product | Attributes, combinations, references, stock, images, price/weight impacts, and default combination | Represents sellable variation structure. |
| Feature/customization Product | Features, Customer input fields/files, and matching Order lines | Separates descriptive data from buyer-entered values. |
| Multistore case | Product, Category, Customer or price with all-shops/group/shop context | Represents shared and shop-specific ownership. |
| Customer-group case | Customer, groups, specific price, Category access, and relevant Order | Represents segmented commerce. |
| Complex Order | Combination, customization, discount, tax, carrier, payment, invoice, return, and external IDs | Represents historical transaction evidence. |
| Module-owned record | Core entity, module tables/fields, hooks, and external key | Exposes non-core scope before execution. |
The PrestaShop sample package is ready when each selected record has a source expectation sheet, intended representation, shop and language scope, related files, agreed exclusions, and a named reviewer. These inputs prepare later verification rather than performing it.
Complete the Final PrestaShop Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Required actual Source access and owners, available backups or exports/files/media/downloads, recovery method, date, coverage, limits and owner are confirmed. Required evidence is recoverable under that method; intended Target administration and permitted infrastructure are separately assessed. |
| Multistore | Shops, groups, domains, shared-data settings, languages, currencies, and shop-specific values are documented. |
| Catalog | Products, combinations, attributes, features, customizations, Categories, suppliers, manufacturers, stock, prices, and identifiers are traceable. |
| Customers and Orders | Accounts, groups, addresses, carts, Orders, lines, totals, statuses, documents, messages, returns, and external IDs have evidence. |
| Content and URLs | CMS content, navigation, friendly URLs, metadata, internal links, and redirect decisions are documented. |
| Dependencies | Modules, overrides, themes, custom tables, Webservice integrations, and external systems have named owners. |
| Samples | Representative records cover every material Product, shop, Customer, Order, content, and module pattern. |
| Target prerequisites | The intended PrestaShop installation, shop/sharing model, catalog/price/stock representation, account/content/field consumers, access and continuing-operation owners are confirmed. |
The PrestaShop scope is ready when every material record can be traced to its shop context, source owner, related records, evidence artifact, and accepted destination or retained system. Required gaps must be resolved, excluded by agreement, or held before the affected scope proceeds. Naming an owner and a future deadline does not settle a critical missing relationship or destination prerequisite.
The final preparation decision requires recoverable actual Source evidence and an intended installation able to use the same agreed shop, catalog and account relationships. Missing sharing context, tax-basis evidence, combination identity or a required module consumer remains a gap. Resolve it, agree an explicit exclusion or hold the affected scope before execution; later validation tests the declared storefront and operating result.
Conclusion
PrestaShop preparation requires coordinated evidence across Products, combinations, attributes, features, customizations, multistore scope, Customer groups, Customers, Orders, CMS content, friendly URLs, modules, overrides, and external systems. The checklist should make those relationships explicit before execution rather than relying on exports from the default shop.
A complete readiness package preserves recoverable source evidence, resolves shared versus shop-specific records, separates historical commerce from live configuration, and gives every module or custom dependency a named owner.
Carry the evidence package, intended Target decisions and any held scope into PrestaShop Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first for a PrestaShop migration?
Identify the actual Source and collect the access, dated archives, media, field meanings, and recovery ownership needed to inspect it. For a PrestaShop Source, include its version, multistore tree, modules, and permitted database/filesystem evidence. Separately record the intended destination installation and enabled consumers before classifying the catalog.
Why must Products and combinations be prepared separately?
A Product holds shared catalog information, while combinations can own references, barcodes, price and weight impacts, stock, images, minimum quantities, and option values. Each real sellable combination needs independent traceability.
How are PrestaShop features different from attributes?
Attributes create Product combinations that customers can select. Features describe characteristics that remain stable across combinations. Mixing them can create false variants or remove information needed for filtering and comparison.
Why is multistore context essential?
Products, Categories, Customers, prices, languages, modules, and URLs can be shared or customized by all shops, a shop group, or one shop. The same source ID can therefore have different business meaning depending on context.
Which PrestaShop Orders should be selected as representative samples?
Include guest and registered Customers, combinations, customization text or files, Customer-group pricing, discounts, multiple taxes, invoices, returns, credit slips, payment and carrier references, and external-system IDs.
What belongs in the PrestaShop module and override ledger?
Record every module, override, custom table, theme dependency, Webservice integration, and external connector that creates or consumes business data. Each item needs an owner, affected records, evidence, and a destination or retained-system decision.
Does shared Customer identity prove that quantities and Orders are shared?
No. Customer, quantity, and Order sharing are separate shop-group settings, and Order sharing depends on Customer and quantity sharing. Record the actual controls and shop assignments. A common Customer ID alone does not establish stock ownership or the historical Order scope.
Is a price amount enough to prepare PrestaShop pricing?
No. Preserve whether the Source amount is Tax excluded or Tax included and the intended target basis. Specific prices also need their Product/combination, shop, currency, country, group or Customer, quantity, date, reduction type, and priority. Keep historical Order prices as snapshots rather than deriving them from current rules.