Migrating away from Sylius to a custom Solidus store

What Sylius is, and why this is the fairest article in the series

Sylius is an open source ecommerce framework built on Symfony, the PHP application framework, and released under the permissive MIT licence.¹ You install it on your own server, point it at a MySQL, MariaDB or PostgreSQL database, and the code and the data are yours to read, change and keep.² There is no vendor who can switch it off, no revenue share, and no plan tier that unlocks your own checkout. If you are on Sylius and it is serving you well, the honest headline of this article is short: you should probably stay. There is no rescue to perform here.

I say that plainly because it is true, and because it is the only reason the rest of this article is worth reading. Most of the migration series is about leaving a platform that holds something back from you: a hosted system that gives you only the exports it chooses, a theme you cannot take with you, a checkout you are not allowed to touch. Sylius is none of those things. It is a framework you own, exactly as the thing I build on, Solidus, is a framework you own. The difference between them is not ownership. It is language and ecosystem. So this is the one article in the series where I am not comparing a landlord with a house. I am comparing two houses that are both yours, built by two different trades.

That makes the decision to move off Sylius a deliberate engineering choice rather than an escape, and the whole article is written in that spirit. I will be scrupulous about what Sylius does well, honest about the one or two things that are genuinely tied, and clear about who should not move at all.

Sylius and Solidus are peers, not winner and loser

Here is the frame I want you to hold onto, because the marketing around every migration tends to blur it. Sylius and Solidus are the same kind of thing. Both are open source commerce frameworks that a developer assembles into a shop and that you then own outright. Sylius is written in PHP on Symfony. Solidus is written in Ruby on Rails. Neither is a product you install and click through to a finished store, and both give you orders, products, variants, stock, promotions, payments, shipping and tax as building blocks with an admin on top.²

So the real decision when someone asks me about leaving Sylius is never "which framework is better", because that question has no honest answer. It is a set of much more practical questions:

Which language and ecosystem does the rest of your business already live in? If your internal tools, your customer portal and your team are Ruby and Rails, a Rails shop shares code, conventions, hiring pool and deployment with all of it. If they are PHP and Symfony, the same argument runs the other way, and it runs towards staying on Sylius.
Who is going to be accountable for the shop, and can you hire for them? A shop is a long relationship with whoever maintains it. The deciding factor is often simply which ecosystem you can find and keep a developer in, near you and at a price that works.
Does the surrounding stack pull one way? A business standardising on Rails across everything it runs has a real reason to want its shop there too, so there is one toolchain, one set of tests, one way of deploying, rather than a PHP island maintained separately.

Notice that none of those is "Sylius is bad". Sylius is a serious, actively developed project. Version 2.0 landed in November 2024, the first major release since 2017, with a rewritten Bootstrap admin, Symfony UX in the storefront and a modern API.³ The latest stable release at the time of writing is 2.3, which adds support for Symfony 8, and point releases ship steadily.⁴ The project is also well backed: in a deal agreed in December 2025 and completed in early 2026, the group behind Sylius, together with BitBag, took over PrestaShop as part of a larger European open source commerce group.⁵ That is a sign of health, not a reason to flee. I mention it only so you know the project is not going anywhere, and so that nobody sells you a move on a false story about Sylius being abandoned.

If after all that the answer is still Rails, read on. If it is not, close the tab with my blessing.

What you own, and the little that is actually tied

Because Sylius is self hosted and open source, the single most important fact about leaving it is entirely in your favour: there is nothing to rescue. The database is yours, the application code is yours, and a developer can read every table and every line without anyone's permission. Compared with a hosted platform, where the hard part of a migration is getting the data out at all, a Sylius move has no data problem to solve. The work is re building the behaviour in a new language, not prising information loose.

So the honest table for Sylius looks different from the one I draw for a hosted platform. Almost everything is in the "you own it" column. Only a short list is tied, and even that is tied loosely.

What	On Sylius	Where it goes on Solidus
Products, variants, options, prices, taxons, images, stock	Yours, in your own database, read directly	The Solidus product model, see products and catalogue data
Customer accounts and addresses	Yours, but passwords are hashed and cannot be reused	Rebuilt with a reset or a verify at first login, see customer accounts
Order and purchase history	Yours, in full	A read only history in the new shop
SEO slugs and URLs	Yours, in your own tables	A redirect table in the new shop
Payment configuration and saved cards	Tied to the gateway through Payum, not to Sylius	Rebuilt around your own gateway account, see payment tokens
Sylius Plus modules, if you licence them	Commercial features you would re implement	Built as owned, tested code
Custom plugins, theme and business logic	Yours in PHP, but do not run on Rails	Re implemented and tested in Ruby

The two rows worth dwelling on are the last two, and the payment one, because they are the only places a Sylius shop carries anything that could be called a lock in, and in each case it is mild.

The export and API reality: there is no export problem

This is the section that is long and tense on a hosted platform, and short and calm on Sylius. You own the database, so the strongest route out is simply a database dump. Everything the shop knows lives in Doctrine managed tables that a developer can read directly, and for a large catalogue or a complex order table that is the route I actually use, because nothing is hidden and nothing is summarised away.

Sylius also ships a genuine API, and here it is worth being precise, because it is a real strength rather than a grudging one. Since version 2.0 the admin and the storefront are served by a single API built on API Platform, the Symfony API framework.³ The paths sit under a version prefix and a context, so administrative operations live under /api/v2/admin/ and storefront operations under /api/v2/shop/, and the API publishes its own OpenAPI specification generated from the live configuration, so the documentation tracks the code rather than drifting from it.⁶ In other words, unlike a hosted platform where you reverse engineer an export format, on Sylius you have a documented, first party interface over your own data whenever you want one.

Two honest notes. First, Sylius imposes no platform rate limit on that API, because there is no platform between you and it: any ceiling you hit is your own server's, which you control. That is the open source dividend. Second, and precisely because the database is right there, I rarely migrate a Sylius shop through the API at all. For a one off move, a direct read of the tables is faster and more complete than paging an API. The API matters more for what comes after: a Solidus shop ships with its own REST API too, so if the reason you are on a framework is that you feed a mobile app, a marketplace or a second storefront, you keep that capability on the other side, and I wrote about why that is the real prerequisite for an app in headless and API first Solidus.

The conclusion for Sylius is unusual for this series: the move is not a data extraction project. It is a re implementation project. The data comes across cleanly almost by definition. What takes the time is rebuilding, in Rails, the behaviour that currently lives in PHP.

Passwords never move, and that is fine

No password comes across in readable form, from Sylius or from any competent platform, because Sylius never stores the password itself. Authentication runs through Symfony's security component, which hashes every password with a modern one way algorithm such as bcrypt or argon2id and writes only the hash, never the password.⁷ A hash cannot be turned back into the password that made it, so there is nothing to carry over that a customer could log in with, and that is a feature of a shop built properly, not a loss.

The plan around it is the ordinary one, set out in full in the customer accounts guide. Every account, with its name, addresses and order history, is created in the new Solidus shop. On the first visit the customer either sets a new password through a one time link, or, if you choose to carry the old hashes across, has the old hash verified once and then silently replaced with the new shop's format, so they never notice. Either way nobody ever sees a password in the clear, and the account the customer returns to is attached to all of their history.

Where the small lock ins actually are

Because the data is free, the only things that genuinely tie a Sylius shop are the pieces of behaviour and the commercial features sitting on top of it. There are three, and it is worth naming each one honestly.

The first is Sylius Plus. The framework itself is free and MIT licensed, but Sylius sells a commercial edition, Sylius Plus, as a set of modules you licence on top: a B2B suite, a marketplace suite, advanced multi store, returns management, multi source inventory, loyalty, role based admin access, partial shipments, request for quotation, a product configurator and subscriptions.⁸ It is a modular commercial licence, listed from around 800 euros a year and scaled to your online turnover, with each module bought separately as you need it.⁸ If your shop depends on one of these modules, that specific capability is the thing you re implement rather than copy, because it is proprietary code you licence rather than own. The good news is that these are exactly the kind of features a Solidus build treats as first class application code: a trade price list, a returns flow, inventory across several warehouses. They become part of the shop you own, with tests, rather than a licence you keep renewing.

The second is the plugins and the custom logic. A real Sylius shop of any ambition is core Sylius plus a stack of plugins and bundles, some public, some written for you, that hold the actual rules of your business: the way trade customers are priced, the odd rounding your accountant insists on, the extra field on an order, the way a particular courier's label is produced. That logic is PHP, and PHP does not run on Rails. It has to be read, understood and rebuilt. On a well kept Sylius shop this is pleasant work, because the logic is in version control and often has tests, which is the opposite of the archaeology a hosted or legacy platform forces on you. But it is still the bulk of the project, and it is the honest reason a framework to framework move costs real money even though the data is free.

The third is payments, which I will take on its own because it is the one trap that behaves the same on every platform.

Payments and saved cards

Sylius handles payments through Payum, a PHP payment abstraction, with a gateway behind it such as Stripe, PayPal, Adyen or a local acquirer.³ What matters for a migration is not how Sylius talks to the gateway, but who holds the card. The answer is never Sylius: it is your payment provider. Sylius stores a reference, the gateway stores the card.

That single fact decides whether returning customers keep their saved cards or have to enter them again. If your shop already charges cards through its own Stripe or equivalent account, the saved cards belong to that account, and the new Solidus shop connects to the same account so the cards simply stay where they are and nothing is lost. If instead the cards sit inside a provider you reached only through a particular Sylius integration, moving them means a provider to provider transfer that the receiving processor will accept only from another holder certified to the top level of the card security standard, and that transfer never includes the subscriptions or the payment history alongside the cards.

This is the single most important thing to settle first, not last, and the payment tokens guide walks through every case. Decide your payment provider before a line of the new shop is written, because that one decision determines whether the move is invisible to your customers or asks them all to re enter a card. If the subject makes you uneasy, the hidden dangers of switching payment gateways is the cautionary version. If your Sylius shop sells on a recurring basis, treat the subscription mandates as the hardest part of all and raise them on day one, because a live mandate lives with the gateway and often needs the gateway's cooperation to move.

SEO slugs and the redirect map

Every product, taxon and content page on a Sylius shop has a URL, and some of them carry years of links and rankings. The good news, again, is that those slugs live in tables you can read directly, so the first draft of a redirect map is a database query rather than a crawl of the live site.

The discipline after that is the same on every platform, and it is where most migrations quietly lose money. Every address that received a visit or a link in the last year has to be mapped to its new home with a permanent redirect, pointing straight at the final page rather than through a chain, and kept in place for at least a year. The full method, and why the ranking loss people blame on a move is almost always missed redirects rather than the move itself, is in the products and catalogue guide. On the shops I build the redirects live in the application itself as an editable table, so they survive every future deploy and your own staff can add one when they spot a stray in search results.

A worked example

Let me make this concrete with an invented shop. Pennine Brew Supply (penninebrewsupply.example) is a Leeds business selling home brewing kits, grains and equipment, with a healthy trade side supplying microbreweries and taprooms on account. It turns over about £1.6 million online, carries roughly 4,000 products once sizes and pack quantities are counted, and has run on Sylius for four years. The shop is not broken. It works, the data is clean, and the owner likes that she owns it.

What has changed is the rest of her business. Over those four years her team built a warehouse app, a trade portal and a stock forecasting tool, and all three are Ruby on Rails, because that is what the developer she hired and trusts works in. The shop is now the only PHP system she runs. Every change to it means a second toolchain, a second deployment pipeline and, in practice, a second contractor she keeps on retainer purely for the shop. Her Sylius install also leans on two Plus modules, the B2B suite for trade pricing and the subscription module for a monthly grain club, so part of her shop is commercial code she licences rather than owns. She has decided she would rather have one stack, one accountable developer and one owned application.

Here is how the move goes, and notice how much of it is calm. The clean part comes first and reassures everyone. A full database dump, and from it the 4,000 products with their variants, prices, stock and images map onto the Solidus catalogue over a couple of weeks of careful matching. The customer records, including the trade accounts, come across with their addresses and order history, passwords excepted. The order history is brought in as read only reference, three years deep, with the older records kept in the archived export. The SEO slugs are read straight from the database into the first draft of the redirect map, about 5,000 rows that one person then checks.

Then the parts that take the real work, which were raised in week one, not week ten. The trade pricing that lived in the Plus B2B suite becomes a tested feature of the new shop, written in Rails, sharing its pricing logic with the trade portal her team already built. The grain club, which depended on the Plus subscription module and a Payum gateway, is the question flagged first: because the shop already charges through its own Stripe account, the new Solidus store connects to that same account, the saved cards and the active mandates stay valid, and what could have been the scariest part becomes manageable. The custom plugin that produced her courier's labels is read, understood and rebuilt. Twelve weeks after the first workshop, Pennine Brew cuts over on a quiet Tuesday morning, keeps the old Sylius install running untouched for thirty days as a fallback, and only then retires it. A year on, the shop is one maintained Rails application alongside the warehouse app and the trade portal, with one developer who knows all of it, and no commercial module licences to renew.

That example is invented, but the shape is the real one: a Sylius move succeeds or fails on the re implementation and the payment decision, never on getting the data out.

The honest move plan

Stripped to its bones, leaving Sylius for a custom Solidus store runs like this. First, discovery: list the plugins and bundles and write down what each one really does, note which Sylius Plus modules you depend on, pick the payment provider, and name the one person inside the business who owns the data. Second, the build: stand up the Solidus shop, write the import scripts, and run them again and again against a copy of the real database until the import is boring. Third, map the catalogue and the customers, which on Sylius is the easy part, and re implement the plugin and Plus module logic as tested Rails features, which is the real work. Fourth, build the redirect map from the slug tables and check every row. Fifth, a parallel run of a few weeks with the catalogue frozen, rehearsing the final import twice. Sixth, cut over on a quiet weekday morning, place a real test order on every payment method, check the top redirects by hand, and keep the old shop as a fallback for thirty days before retiring anything.

Through all of it the principle is the one in the pillar, what moves and what does not: move the shop as it is, make it stable, and only then improve it. Turning a migration into a redesign at the same time doubles the risk and makes it impossible to tell which change caused a dip.

Who should stay on Sylius

I would rather lose the work than sell you a move you do not need, and on Sylius that warning carries more weight than anywhere else in this series, because Sylius is a good framework that you already own. So here is when to stay, and I mean it.

Stay on Sylius if your team is invested in and happy with PHP and Symfony. A framework move is worth it when it unifies your stack, and it is a waste when it splits it: dragging a happy Symfony team onto Rails, or hiring a Rails developer to sit alone beside a PHP team, is the mistake this article is most keen to prevent. Stay if the rest of your business is PHP, because then Sylius is the system that shares a language with everything else. Stay if your shop leans hard on a Sylius Plus module that does exactly what you need and you are content to licence it. Stay if nothing is actually blocking you and the only itch is that Rails looks interesting, because interest is not a business case.

Move to a custom Solidus store when the pull is real: when the rest of your stack is Ruby and Rails and the shop is the lonely PHP island, when you want one accountable developer and one toolchain rather than two, when the shop needs to share code with Rails systems you already run, or when you would rather own your B2B, returns and subscription features outright than licence them. For the money side of that decision, the five year cost of moving to Solidus works the numbers, the platform comparison sets the options side by side, and who actually owns your business data is the principle underneath it all. If you are weighing other self hosted shops in the same breath, I have written the same honest guide for leaving PrestaShop, which is now, as it happens, part of the same group as Sylius. Solidus itself is open source under the BSD licence, so the shop I build for you carries no licence fee and no lock in of its own.⁹

The workshop

If you run a Sylius shop and you are genuinely weighing whether to move, bring it to a free workshop and the first two weeks of work are on me. Bring your plugin list, your Sylius Plus licences if you have them, and whatever you know about the custom logic. Together we will work out what moves cleanly, which is most of it, what has to be re implemented in Rails, which is the real cost, and whether a move actually serves your business or just your curiosity. Because Sylius and Solidus are peers, I can give you the straightest answer in the whole series, and quite often that answer is to stay exactly where you are.

Sylius source repository, the Sylius ecommerce framework on top of Symfony, released under the MIT License, copyright Sylius Sp. z o.o., GitHub, checked 14 November 2026, https://github.com/Sylius/Sylius ↩
Sylius documentation, Before You Begin and system requirements (self hosted, PHP 8.2 or higher with the gd, exif, fileinfo, intl and sodium extensions, one of MySQL 8.0, MariaDB 10.4.10 or PostgreSQL 13.9, built on Symfony with Doctrine ORM), checked 14 November 2026, https://docs.sylius.com/public/getting-started/before-you-begin.md ↩ ↩²
Sylius, Sylius 2.0 is live (the first major release since 2017, a rewritten Bootstrap admin, Symfony UX in the storefront, a unified API on API Platform 4, and payments through existing Payum gateways), 12 November 2024, https://sylius.com/blog/sylius-2-is-live/ ↩ ↩² ↩³
Sylius releases, including v2.3.2 as the latest stable release and the 2.3 line adding Symfony 8 support, GitHub, checked 14 November 2026, https://github.com/Sylius/Sylius/releases ↩
cyber_Folks, completion of the acquisition of PrestaShop together with Sylius and BitBag, forming a European open source commerce group of more than 700,000 clients, investor relations, checked 14 November 2026, https://investors.cyberfolks.pl/en/?p=3794 ↩
Sylius documentation, customizing the API (one unified API built on API Platform, administrative operations under /api/v2/admin/ and storefront operations under /api/v2/shop/, with an OpenAPI specification generated from the live configuration), checked 14 November 2026, https://docs.sylius.com/the-customization-guide/customizing-api ↩
Symfony documentation, Hashing and verifying passwords (passwords hashed with a modern one way algorithm such as bcrypt or argon2id through the auto hasher, never stored in readable form), checked 14 November 2026, https://symfony.com/doc/current/security/passwords.html ↩
Sylius Plus, the commercial edition (a modular commercial licence listed from around 800 euros a year and scaled to online turnover, with modules including a B2B suite, marketplace suite, advanced multi store, returns management, multi source inventory, loyalty, role based access, partial shipment, request for quotation, a product configurator and subscriptions), checked 14 November 2026, https://sylius.com/plus/ ↩ ↩²
Solidus source repository, the Solidus ecommerce framework on Ruby on Rails under the BSD 3 clause licence, GitHub, checked 14 November 2026, https://github.com/solidusio/solidus ↩