Sylius 1.14 end of support: what happens in 2027
Sylius 1.14 reaches its end of support on 31 December 2026, the date on which security support ends according to endoflife.date. Active maintenance had already ended on 31 December 2025. Your shop will keep working on 1 January 2027, but you should not count on new security releases for that version. With two months left, the useful question is no longer whether to act, but which option you can realistically complete.
The Sylius 1.14 end of support date and policy
When Sylius 2.0 was launched in November 2024, the project described 1.14 as an LTS version with an extended maintenance period of up to two years. LTS means long term support: a version kept alive longer so that shops have time to move. The table shows where the releases stand on 1 November 2026.
| Version | Active support ended | Security support ends |
|---|---|---|
| 1.14 | 31 December 2025 | 31 December 2026 |
| 2.1 | 31 March 2026 | Ended 30 September 2026 |
| 2.2 | 30 November 2026 | 31 March 2027 |
| 2.3 | Ongoing | Ongoing |
These dates matter because security fixes are still being issued: the October 2026 security release covered 1.14.21 alongside the 2.x branches. So the first action costs little and has nothing to do with migration: check that you are actually on that latest patch. A shop stuck on an older 1.14 release is exposed to already published problems today.
What really changes after 31 December
The risk comes gradually. Once a new vulnerability is published for a supported branch, an attacker can examine the fix and check whether older code has the same flaw, while your version may not get an official patch. An online shop handles customer accounts, addresses and order histories, so this is not an abstract concern.
The same calendar applies lower in the stack. PHP 8.2 also ends security support on 31 December 2026, and PHP 8.1 is no longer on the list of supported branches. Since the 1.14 composer file allows PHP 8.1 and up, check what your server is actually running. A later PHP version on the same Sylius may be a smaller and quicker gain than people expect, provided your code and plugins accept it.
There is a legal angle too. Article 32 of the GDPR asks for security measures suited to the risk, and regular testing of their effectiveness. An unsupported component does not automatically mean a breach of that text, but you should be able to explain the measures you took. I am a developer, not a lawyer, so take that question to your adviser.
Your four options, compared
| Option | Suits you if | Main drawback |
|---|---|---|
| Upgrade to Sylius 2.x | The shop has years ahead of it | A real project, probably not finished by the deadline if not already started |
| Stay on 1.14 for a limited time, under watch | A migration is scheduled and funded | You take responsibility for security in the meantime |
| Move to another platform | Your needs are simple, or custom code no longer pays for itself | Data migration, and a new way of working |
| Do nothing | Never a reasoned plan | Risk grows silently with each new vulnerability |
The second option is the one that most shops will realistically use, and it is acceptable only if it has an end date. In concrete terms, it means applying the last patch, updating PHP where possible, restricting access to the back office, enforcing strong passwords, keeping tested backups, watching vulnerability announcements, and having someone able to respond to them. Those measures reduce the risk without removing it.
What to ask your current provider this week
Ask four simple questions and request written answers. Which exact Sylius and PHP versions run in production? Who tracks security announcements for us after 31 December? Which of our plugins have a version compatible with Sylius 2? When did someone last restore a backup to confirm that it works? The answers tell you quickly whether the shop is being looked after. If they do not arrive, that is your most urgent finding, and the code, database and hosting access should be secured next.
When moving fast is the wrong call
A rushed migration can do more harm than a few controlled months on 1.14, especially just after the end of year sales period. If your provider is competent and engaged, stay with them and set a date. If your shop is simple and has no specific logic, Sylius may no longer be the right tool, and a hosted platform deserves consideration. I have an interest in this subject since I offer Sylius maintenance and takeovers, so weigh my advice accordingly.
What I can do
I took over the Belgian shop Coucouroucoucou, with about 15,000 orders, its customers and invoices, without any interruption in sales. That was a takeover and not a version migration, but the method is similar: inventory first, protect sales, and then change things. The steps of a 2.x move are set out in my Sylius 2 upgrade guide. To review your own situation, get in touch through my Sylius developer page. I reply within 24 business hours.