Export PrestaShop data: the complete guide

Exporting data from PrestaShop seems like it should be the easy part of a migration. In practice, it is often where projects encounter their first serious problems. The built-in export tools cover basic use cases but miss critical fields. Module-based exporters vary wildly in quality. And if you go directly to the database, you face a schema that has evolved across multiple major versions with minimal documentation.

This guide covers every major export path — what each one gives you, where it falls short, and what you actually need to produce a migration-ready dataset.

Understanding the PrestaShop data model before you export

Before touching any export tool, you need to understand how PrestaShop stores its data. The schema is spread across dozens of tables, and the ones that matter most have non-obvious relationships.

Products live in ps_product (core fields) and ps_product_lang (translated fields like name, description, meta tags). Variants are in ps_product_attribute, with attribute values in ps_attribute and ps_attribute_lang. Product images are referenced in ps_image, with the physical files living in /img/p/ with a path structure derived from the image ID. If your store has ps_product IDs with 6-digit image IDs, those images are stored at paths like /img/p/1/2/3/4/5/6/123456.jpg.

Customers are in ps_customer, with addresses in ps_address. The relationship is one-to-many: a customer can have multiple saved addresses. The id_address_invoice and id_address_delivery on ps_orders reference specific address records, not the customer directly.

Orders are in ps_orders, line items in ps_order_detail, and payment records in ps_order_payment. Cart rules (discounts) applied to an order are in ps_order_cart_rule.

Categories use a nested set model in ps_category, with translated names and descriptions in ps_category_lang. The parent-child relationship is expressed via id_parent, and each product's category membership is in ps_category_product.

Understanding this before you export means you know what joins you need and what you will be missing if you use a simplified export tool.

Method 1: PrestaShop back-office CSV export

The Admin panel (Catalog > Products > Export) produces a CSV. For small catalogs — under a few hundred products — this is fast and workable. For anything larger or more complex, it hits immediate limits.

What you get: product name, reference, EAN, price, quantity, category (as a string path, not an ID), active status. For simple products, this covers the minimum. For products with variants, the back-office exporter produces one row per product, not one row per variant — which means all variant-level pricing, stock, and attribute data is missing.

What you do not get: product images (only image URLs if you configure it, not the files themselves), SEO meta fields, multi-language values if you have a multilingual store, supplier references, wholesale prices, or any custom fields added by modules.

The customer export (Customers > Customers > Export) gives you email, first name, last name, date of birth, newsletter status, and registration date. Addresses are a separate export under Customers > Addresses. The two files share id_customer as a join key, but nothing enforces consistency if you export them at different times.

For orders, PrestaShop offers date-range filtered exports under Orders > Orders. These CSVs are genuinely useful for accounting purposes but poorly structured for migration. Line items are not exported at all — just order headers with total amounts.

Verdict: Useful for quick validation and small data sets. Not sufficient for a complete migration.

Method 2: phpMyAdmin or direct SQL

If you have database access — either through a hosting control panel or directly — SQL exports give you complete, accurate data. This is the method most technical teams use for serious migrations.

The key queries you need:

For products with variants and images:

SELECT
  p.id_product,
  pl.name,
  pl.description,
  pl.description_short,
  pl.meta_title,
  pl.meta_description,
  p.reference,
  p.ean13,
  p.price,
  p.wholesale_price,
  p.active,
  p.weight,
  sa.quantity
FROM ps_product p
JOIN ps_product_lang pl ON p.id_product = pl.id_product AND pl.id_lang = 1
LEFT JOIN ps_stock_available sa ON p.id_product = sa.id_product AND sa.id_product_attribute = 0

For product variants:

SELECT
  pa.id_product_attribute,
  pa.id_product,
  pa.reference AS variant_reference,
  pa.price AS price_impact,
  pa.weight AS weight_impact,
  sa.quantity,
  GROUP_CONCAT(al.name ORDER BY a.id_attribute_group SEPARATOR ' / ') AS variant_label
FROM ps_product_attribute pa
JOIN ps_product_attribute_combination pac ON pa.id_product_attribute = pac.id_product_attribute
JOIN ps_attribute a ON pac.id_attribute = a.id_attribute
JOIN ps_attribute_lang al ON a.id_attribute = al.id_attribute AND al.id_lang = 1
LEFT JOIN ps_stock_available sa ON pa.id_product_attribute = sa.id_product_attribute
GROUP BY pa.id_product_attribute

One encoding issue to watch for: if your database collation is latin1_swedish_ci (common on older PrestaShop installs), your exports will contain character corruption for any product with accented characters, special quotes, or diacritics. Before exporting, either convert the connection charset to UTF-8 in your query client or run a post-export conversion. The iconv tool handles this: iconv -f latin1 -t utf-8 export.csv > export_utf8.csv.

Verdict: Most complete option. Requires database access and SQL knowledge. Manual joins for images and categories.

Method 3: module-based exporters

Several PrestaShop modules exist specifically for data export. The most commonly referenced are Knowband's Store Manager and various "CSV Advanced Export" modules on the marketplace. Quality varies considerably.

What to look for in a module exporter: it should handle multilingual fields, export variants as separate rows (not collapsed), support image URL export with correct base URL configuration, and let you define which fields appear in the output.

What to avoid: modules that require a live environment to function (as opposed to working from a database backup), modules with hardcoded UTF-8 assumptions that break on latin1 databases, and anything that pulls data through the PrestaShop object model rather than direct SQL — object model exports are 10 to 50 times slower on large catalogs.

If your catalog has more than 5,000 products or your customer base exceeds 20,000 records, time the export before relying on it. A module export that takes four hours on a shared hosting environment during business hours creates risks for your live store.

Exporting images

Images are the most frequently underestimated part of PrestaShop data export. You have three options:

Download from the live site: Use wget or a recursive download tool on the /img/p/ directory. This works but is slow for large image sets and generates significant server load.

Archive the upload directory: If you have SFTP or SSH access, archive the /img/ directory directly. This is the fastest and most complete option. A 10,000-product catalog with multiple images per product typically produces between 5 GB and 30 GB of images.

Use image URLs in the export: If you export product data with image URLs pointing to your live PrestaShop domain, an import tool can fetch images during the migration. This spreads the bandwidth load over time but introduces a dependency on your PrestaShop instance remaining live during import.

What WarpForge does differently

All of the methods above require manual assembly. You need to produce multiple export files, handle joins between products and variants, manage character encoding, and coordinate image extraction — then feed the result into a separate import process.

WarpForge connects directly to your PrestaShop database and reads all of this in a single operation. Products, variants, categories, customers, orders, and images are extracted and transformed to a normalized format, then imported into Shopify via the GraphQL Admin API. There are no intermediate CSV files to manage, no encoding conversion step, and no manual join logic. The system handles ps_product_lang, ps_product_attribute, and ps_stock_available natively, including multilingual setups and multi-warehouse stock.

If you want to run an export manually — to validate data before committing to a full migration, or because your situation requires custom transformation logic — the SQL queries above give you a solid starting point. But if your goal is to get a complete, accurate Shopify store as fast as possible with minimal operational risk, automating the full pipeline is the more reliable path.

Common mistakes to avoid

Exporting at different times. If you export products on Monday and customers on Wednesday, your data is no longer consistent. Order history that references customers exported two days later will have ID mismatches. Always snapshot the full dataset in a single operation.

Ignoring soft-deleted records. PrestaShop uses active = 0 and deleted = 1 flags rather than hard-deleting rows. Your export queries need explicit filters unless you want to import discontinued products or deactivated customers.

Missing the id_lang filter. Multilingual PrestaShop installations store one row per language in _lang tables. Always filter by id_lang to avoid importing duplicate rows.

Exporting prices exclusive of tax without noting it. PrestaShop stores prices as tax-exclusive in ps_product.price. Shopify's product price field is also tax-exclusive by default, but your tax configuration in Shopify determines what customers see at checkout. Document your tax setup on both sides before import.