Which Sylius version should a new project start on today?

Sylius 2.3 is the newest minor release and the longest runway. Check first that your server can run PHP 8.3 and that every plugin you depend on already supports it.

Is my shop in danger on 31 December 2026 if it still runs 1.14?

It will not stop working that day. It simply stops receiving security fixes from the project, so any flaw found afterwards stays open unless someone patches it for you.

Can I jump straight from 1.14 to 2.3?

The major change is documented in the 2.0 upgrade guide, and each later minor release has its own notes. Plan to read all of them in order, even if the code ends up moving in one project.

Do I need a developer to install Sylius?

To try it locally, a technical person can follow the guide in an afternoon. A real shop needs payment, tax, mail, background workers and a production server, which is developer work.

Sylius docs: install, upgrade, supported versions

The Sylius official documentation covers installation and upgrades, but the supported versions and the Symfony and PHP requirements are spread over several pages. As of 1 November 2026, the versions still receiving security fixes are 2.3, 2.2 until 31 March 2027, and 1.14 until 31 December 2026. Sylius 2.3 requires PHP 8.3 and accepts Symfony 6.4, 7.4 and 8.

This article is the reading map I wish a shop owner had before asking for a quote. I am an independent Sylius developer, so I have an interest in the subject: I sell this kind of work. The facts below link to their source so you can check them without me.

Supported versions of Sylius in 2026

The date that should worry a shop owner is the end of security support, not the end of bug fixes. After it, a published flaw stays open on your site unless someone backports the fix. endoflife.date, updated in October 2026, gives the following picture, and the project's own release cycle page describes the same two phases: maintenance, then security fixes only.

Version	Released	Security support ends	What it means today
2.3	28 September 2026	Not yet announced	The target for new work
2.2	17 December 2025	31 March 2027	Fine for now, plan the move to 2.3
2.1	4 June 2025	30 September 2026	Out of support, act now
2.0	12 November 2024	28 February 2026	Out of support, act now
1.14 LTS	12 November 2024	31 December 2026	Two months left

Patches matter as much as the minor version. The October 2026 security release shipped 1.14.21, 2.1.17, 2.2.12 and 2.3.2. A shop on 2.2.3 is on a supported branch and still exposed. To find your exact version, look at the sylius/sylius entry in the composer.lock file of your project.

PHP and Symfony requirements: where the pages disagree

Here is a trap for anyone reading quickly. The Before You Begin page says PHP 8.2 or higher, with the gd, exif, fileinfo, intl and sodium extensions, Node.js 20 or 22, and MySQL 8.0, MariaDB 10.4.10 or PostgreSQL 13.9 or higher. It is written for the 2.x line in general. The Sylius 2.3 release announcement is more specific: PHP 8.3 or newer. For a project on 2.3, the announcement is the one to follow.

On the Symfony side, 2.3 accepts 6.4, 7.4 and 8, and API Platform 4.3 or 5. There is a dependency hidden in that sentence: the announcement states that API Platform 5 needs Symfony 7.4 or 8, so a project staying on Symfony 6.4 also stays on API Platform 4. You can therefore upgrade Sylius before you touch Symfony, which is good news when a shop has many custom bundles.

What the Sylius installation really involves

The installation guide is short: create the project with composer create-project sylius/sylius-standard, build the front-end assets, set DATABASE_URL in .env.local, run bin/console sylius:install, configure MAILER_DSN, then start the server. If you do not want English and US dollars, set the locale and sylius_installer_currency parameters in config/services.yaml before the installer runs, because that is cheaper than changing them later.

One line in that guide is easy to skip. It calls the background worker, messenger:consume main, optional, while noting it is needed for features such as catalog promotions. In production it has to run under a process manager like Supervisor. A shop owner who sees a discount that never applies is often looking at a worker that is not running, not at a bug.

Installing proves the software starts. It does not give you a shop: payment, shipping, tax, invoices and your own design remain to be done.

How to read the upgrade documentation

There are two different kinds of upgrade, and they do not cost the same. Moving within 2.x usually means reading each minor release's notes. The 2.3 announcement mentions, for instance, that the default of sylius_core.order_by_identifier becomes false, that some interfaces gain methods, and that YAML grids keep working through a legacy setting so you can migrate them one at a time.

Moving from 1.14 to 2.x is a different project. The official 2.0 upgrade guide lists, among much else, the default state machine moving from Winzou to Symfony Workflow, the removal of PayPal Express Checkout and Stripe packages from the main composer.json, renamed API firewalls, and the removal of Swiftmailer. Each of these can touch code written specifically for your shop, and that custom code is what sets the size of the job. Nobody can price it honestly without reading your repository.

The patch notes deserve attention too. The 2.3 upgrade notes describe a high severity host header issue on channels with no hostname set, where password reset emails could point to a hostile domain. The fix on your side is configuration: a hostname on each channel, or a strict trusted_hosts pattern.

When upgrading now is not the right call

If your shop is on 1.14 and you already plan to replace it within a few months, spending heavily on a move to 2.x makes little sense. Patch to 1.14.21, tighten access and put the money into the replacement, knowing you accept a risk after 31 December 2026. Equally, if your shop has a small catalog, no specific business logic and no development budget, Sylius may not be the right tool at all. A hosted platform can serve you better, and I would rather say so than sell you an upgrade.

When the work goes the other way, you need a developer who reads the code before quoting. Ask any provider three things: which plugins block the upgrade, how they will test checkout and payment before go-live, and what happens to your orders during the switch. One reference to weigh: I took over Coucouroucoucou, a Belgian Sylius shop, with about 15,000 orders carried over along with customers and invoices, without interrupting sales. That was a takeover and not a 1.x to 2.x migration, so judge it for what it is.

If you want a straight reading of your own situation, see my Sylius developer page and send me your version and deadline. I reply within 24 working hours, and you will speak directly to the person who writes the code.