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.
Secure Back Office, Hosting, Database, Files, and Backups
Confirm access to the PrestaShop back office, hosting, database, filesystem, image directories, downloadable files, cron jobs, Webservice settings, module management, and connected services. Record the PrestaShop version, PHP and database environment, database prefix, active theme, languages, currencies, shops, modules, overrides, and custom code.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administrative access | PrestaShop administrator | Working account and permission summary | Products, combinations, Customers, Orders, shops, modules, and configuration can be inspected. |
| Create recoverable backups | Infrastructure owner | Database dump, filesystem/image archive, downloadable-file archive, and restoration owner | The source Store can be recovered without depending on the live environment. |
| Record the technical environment | Technical owner | PrestaShop, PHP, database, theme, module, override, and deployment inventory | Version-dependent data and customizations are documented. |
| Capture Webservice and integration access | Integration owners | Webservice keys, allowed resources, external endpoints, and identifier maps | Continuing systems and available source interfaces are known. |
| Preserve source identifiers | Data owner | IDs for shops, Products, combinations, Customers, Orders, addresses, Categories, modules, and external systems | Cross-table and cross-system relationships can be reconciled. |
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. Shops may share Customers or Orders depending on group configuration, while Products, Categories, prices, languages, carriers, modules, and URLs can 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, prices, weights, 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. Specific prices can depend on Product, combination, shop, currency, country, customer group, Customer, quantity, and date range. Stock can belong to a Product or combination and may be shared across shops.
| 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. |
| 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, reserved state where available, 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.
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. 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.
| 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.
Select Representative Migration Test Samples
Choose source records that expose the Store’s real complexity. Record IDs, shop context, language, URLs, combination references, Customer groups, module dependencies, and the reason each sample was selected.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, tax, stock, Category, manufacturer/supplier, images, shop, and Order | Establishes the ordinary Product baseline. |
| 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, shop and language scope, related files, and a named reviewer.
Complete the Final PrestaShop Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Back office, hosting, database, files, images, downloads, credentials, backups, and restoration ownership are confirmed. |
| 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. |
The PrestaShop scope is ready when every material record can be traced to its shop context, source owner, related records, evidence artifact, and intended destination or retained system.
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.
Common Questions
What should be prepared first for a PrestaShop migration?
Confirm back-office, hosting, database, filesystem, image, and module access; create recoverable backups; and document the PrestaShop version and multistore tree. Catalog preparation should not begin until the source can be inspected and restored reliably.
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.