How long does a Magento to Sylius migration take?

It depends on custom features and integrations more than on catalog size. One published case took under six months of development. Yours needs a scoping review to give a real figure.

I do not publish prices, and I will not guess at a market range I cannot source for such a specific job. The budget depends on integrations and custom logic, so ask for a written quote after a review.

Will my rankings drop?

Nobody can honestly guarantee they will not. A complete URL mapping, 301 redirects and close monitoring limit the risk, and they are not optional.

Can I keep Magento running during the project?

Yes, and that is the normal way to do it. The old shop keeps selling until cutover, with a final data sync done during a short freeze.

The open source edition has no licence fee. The real cost lies in development, hosting and upkeep, which is why it does not suit a simple catalog with no recurring budget.

Magento to Sylius migration guide for ecommerce

A Magento to Sylius migration is a rebuild with data migration, not an upgrade: no ready-made migration plugin turned up in my research, so customers, catalog and URLs move through custom scripts. Customers and the catalog usually transfer well, order history often is not worth it, and integrations are what get underestimated. Published experience suggests months rather than weeks, and for some ecommerce shops staying on Magento is the better choice.

I am a Sylius developer, so I have an interest in you choosing it, and I have no Magento migration of my own to show you. That is why this guide leans on published sources, including from a Sylius agency that competes with me.

Should you migrate at all? Check the Magento dates first

Support deadlines rarely force a rushed decision. Adobe's released versions page gives regular support for 2.4.8 until 31 May 2028, and for 2.4.7 until 31 May 2027, with extended support to 31 May 2028. Magento 1 is another matter, and that is the classic case: the EasyMonneret case study published by Sylius describes a French motorcycle school leaving a four-year-old customised Magento 1 site over security concerns, in less than six months of development by the agency Monsieur Biz. It is a vendor's case study of one project, so read it as an example, not a benchmark.

The good reasons for moving are specific business logic that fights the platform, or running costs you can no longer justify. A version running out of support can more often be fixed by upgrading.

Magento to Sylius data migration: what moves and how

The most useful practical source I found is Monsieur Biz's guide to leaving Magento. Its findings, combined with what the Magento schema shows, give this working table.

Data	Typical verdict	Main difficulty
Customers, addresses	Migrates well	Passwords, consent, duplicates across websites
Catalog, categories, images	Usually quick	Custom attributes built up over the years
Order history	Often not worth it	Keep accessible for customers and accounting
Discount rules	Rebuild	Conditions tied to old attributes
URLs	Must be mapped	One to one redirects, not to the homepage
ERP, payment, shipping, PIM	Rebuild the connections	The most underestimated part

The source tables are public in Magento's code. Products use attribute value tables such as catalog_product_entity_varchar, which is why a flat export tends to lose information. Customers sit in customer_entity, orders in sales_order and sales_order_item, and URLs in url_rewrite, which gives you the starting point for the redirect plan. I go through the catalog mapping in a separate article on variants, channels and promotions.

For order history, Monsieur Biz's position is pragmatic: keep the old database read-only and show a basic history in the customer account, which is usually cheaper than a full import. Check this with your accountant, because invoices must remain available regardless of what the shop displays.

Passwords: avoid a mass reset if you can

Whether passwords can be carried over depends on the hashing used by your Magento version and the target. Monsieur Biz points out that a mass reset means an email campaign and a spike in customer service requests on cutover day. On the Sylius side, the Symfony documentation offers a route: keep the legacy hasher through migrate_from or a custom hasher, and rehash at next login. Verify against a sample of your real data before you promise this to anyone. The password_hash column is there in the schema, but the format has changed across Magento versions.

The phases of the project

The order I recommend follows the published advice. First, a foundation: the platform, tests, a production server and staging. Sylius 2.3 needs PHP 8.3 and accepts Symfony 6.4, 7.4 and 8, and it is a sensible target given the support dates. Next, design early, since walking through a user journey settles a feature faster than a specification. Migrate essential data in parallel, starting with customers and addresses, using a script you can rerun. Then integrations and custom features, once the design is agreed. Your own team has to be available throughout, with a few calls a week by Monsieur Biz's reckoning.

Cutover deserves its own rehearsal: freeze the catalog, run the final data sync, switch, test a real order and payment, and keep a way back until you are confident.

SEO: the part you cannot fix afterwards

Work on it throughout the project, not the night before. The guide advises crawling the old site, mapping each old URL to a new one with 301 redirects, cross-checking against 16 months of Search Console data, and avoiding redirect chains or sending everything to the homepage. Record clicks, impressions, indexed pages and rankings as a baseline before cutover, watch for 404 errors daily for the first month, and stay able to add redirects for about three months. This limits risk, and no one can honestly promise you will keep every ranking. My site redesign page covers the same discipline.

When Sylius is the wrong destination

By the Monsieur Biz guide's own account, Sylius is not the right choice for a simple catalog with no recurring development budget, and I agree. It is a framework: you get freedom and no licence fee, in exchange for needing developers over time. A hosted platform will serve a standard shop better, and if your Magento 2 runs fine, a good Magento specialist may be your most economical option. If your project is large, a partner from the Sylius partner directory with a team behind it can make more sense than an independent like me.

Ask any provider what they would refuse to migrate, who owns the redirect plan, how many rehearsals they will run, and who your contact is on cutover day. With me, you speak directly to the person writing the code. My closest reference is Coucouroucoucou, a Sylius takeover with about 15,000 orders carried over without interrupting sales, not a Magento migration.

For a first opinion on your case, send your Magento version and integrations through my Sylius developer page. I reply within 24 working hours, and the price comes as a quote after I understand the job.