Sylius products, variants, taxons: importing data
The Sylius official documentation on products, variants, taxons and orders describes the target model, not an import process: to import data from PrestaShop, you write a Symfony command that creates these objects through Sylius factories and repositories. Fixtures are mainly for testing, and the API helps for ongoing synchronisation. The hard work is mapping your PrestaShop data onto the model, then rerunning the import until it comes out clean.
I build and take over Sylius shops, so I have an interest in the subject. I should also be clear that I present this as a method and not as a track record of PrestaShop migrations.
The Sylius model in four objects
A product needs a name, a code and a slug, and cannot be bought until it has at least one variant. This is the first shift for a PrestaShop team: in Sylius the sellable thing is always the variant, even for a product with no choices. The First Product guide distinguishes simple products with one purchasable version from configurable products with options, and warns that the type cannot be changed after creation. Its example, a t-shirt in four sizes and three colours, gives 12 variants, each with its own price, stock and weight.
Prices are set per channel, and a product not assigned to a channel stays hidden from customers on it. Forgetting this is a classic reason for an import that looks successful with an empty shop.
Taxons are Sylius's categories, organised as a tree. Each product can also have a main taxon, which Sylius uses for breadcrumbs. Orders go from cart to new, then fulfilled or cancelled, with payment and shipping states tracked separately.
Mapping PrestaShop data to Sylius
This table is the core of the specification. The left column comes from the PrestaShop database structure file, and a companion article covers that schema in detail.
| PrestaShop | Sylius | What to watch |
|---|---|---|
product, product_lang | Product and its translations | Codes and slugs must be unique and stable |
product_attribute and combination link | Product variant with option values | Create a variant for products with no combination too |
attribute_group, attribute | Product option, option value | Features are a separate concept from options |
product_shop, product_attribute_shop | Channel pricing | Price impact on a combination must become a final price |
category_product | Product taxon, main taxon | Choose the main taxon from id_category_default |
stock_available | Variant inventory | Freeze stock during the final run |
orders, order_detail | Order and items | Copy totals, never recalculate them |
Fixtures, API or custom command: how to import data
People searching for this usually come across fixtures first. The documentation describes them as predefined data used mainly for testing, with sylius:fixtures:load as the entry point. They are good for demo data or for seeding reference data in a staging environment, but they are the wrong tool for a real catalog with thousands of lines and historical IDs to keep track of.
The API, built on API Platform with separate shop and admin operations, goes through the application's logic, which is safer but slower for a bulk import. I find it better suited to continuous synchronisation with an ERP than to a one-time transfer.
The option I prefer is a Symfony console command, which reads from a copy of the PrestaShop database. The product documentation shows the pattern: create the object with its factory, set its fields, save it with its repository, and let the variant generator create combinations from options if you want it to. Keep a table of old identifier to new code, so that each run can resume and so that redirects can be built from it later.
The trap with orders
Historical orders are not new orders. If you push them through the normal checkout or apply transitions in bulk, callbacks can fire, with risk of stock movements or emails sent to customers. The documentation notes that order processors only work on orders in the cart state by default, so an order imported with a final state should not get its totals recalculated, and that is what you want: the amounts in your history must match the amounts on the invoices.
Before deciding, ask whether you need these orders in Sylius at all. Migration specialists at Monsieur Biz, writing about Magento, argue that order history is often not worth migrating and that a read-only archive with a basic history in the customer account can be cheaper. The reasoning applies to PrestaShop as well.
When this project is not worth starting
If your PrestaShop shop works, has a standard catalog and no business rules that block you, moving to Sylius may buy you little. It is a framework for shops with specific logic and a recurring development budget. Keeping PrestaShop and fixing what hurts can be the better decision, and a PrestaShop specialist will serve you better for it.
If you do go ahead, ask any provider how often they will rehearse the import, how they will verify totals against the source, what freezes during the final run, and how URLs will be redirected. My closest reference is the takeover of Coucouroucoucou, where about 15,000 orders were carried over with customers and invoices without interrupting sales. It was a Sylius takeover and not a PrestaShop migration, though the discipline over data is similar.
The next step is easy: describe your catalog through my Sylius developer page and I will reply within 24 working hours with what needs a closer look.