Stop estimating your Sylius 1 to 2 migration in the dark. We've spent over a decade engineering the core. Now we're releasing a comprehensive technical roadmap and toolkit to help your team upgrade to Sylius 2 with confidence.
Here's where teams get stuck:
The estimation trap. The changelog looks manageable until you audit how deeply your team customized state machines, UI templates, or API endpoints. Internal complexity is invisible until you start the upgrade process.
The plugin gap. Most of the ~520 Sylius plugins on Packagist already support Sylius 2. But do you know if yours is on that list?
The deadline. Sylius 2.0 has been out for over a year and is approaching the end of life quickly. Version 2.2 is where you want to land. The longer you wait, the wider the gap between your codebase and the current standard.
| Version | Sylius 1.14 | Sylius 2.0 |
|---|---|---|
| PHP | 8.1+ | 8.2+ |
| Symfony | 5.4/6.4 | 6.4/7.x |
| Node.js | 18/20 | 20/22 |
| MySQL | 8.0+ | 8.0+ |
| MariaDB | 10.4.10+ | 10.4.10+ |
| PostgreSQL | 13.9+ | 13.9+ |
| Frontend | Semantic UI + jQuery | Bootstrap 5 + Symfony UX |
| State machine | Winzou (default) | Symfony Workflow (default) |
We've been working with Sylius continuously for over a decade – not as integrators looking at docs, but as engineers who understand the "why" behind every architectural decision. Now we're translating that deep expertise into free, practical migration resources for the community.
We're building a set of practical resources to reduce surprises during your migration. Join the list to get each one as it ships.
A structured checklist to score your codebase's upgrade complexity. Covers: state machine customizations, plugin dependencies, frontend changes, payment readiness and API surface area. Helps you identify blockers before they reach production.
Status: Ready
We're compiling a compatibility tracker for popular Sylius community plugins – covering vendors like BitBag, Setono, MonsieurBiz, Synolia, and others. One place to check what's ready, what's in progress, and what's been deprecated.
Status: Ready
A structured checklist to score your codebase's upgrade complexity. Covers: state machine customizations, plugin dependencies, frontend changes, payment readiness and API surface area. Helps you identify blockers before they reach production.
Status: Coming soon
Input your project parameters: number of plugins, custom entities, integrations, frontend approach and get an estimated complexity score with an effort range.
Status: Coming soon
Paste your composer.json. We parse every dependency against a snapshot of the Sylius plugin ecosystem, so you stop reading constraint strings one by one to scope a migration.
Nothing leaves your browser.
Parsing happens client-side.
Sylius 1 is tied to older versions of Symfony and API Platform. One is approaching the end-of-maintenance, while the latter reached end-of-life some time ago. Migrating to Sylius 2 allows you to upgrade to Symfony 7 and API Platform 4, which means long-term security support, better developer experience with modern PHP conventions, and access to the latest platform features. Staying on 1 doesn't just mean missing new features; it means accumulating technical debt as the gap between your codebase and the current ecosystem widens. The longer you wait, the more expensive the eventual migration becomes.
For complex stores, we strongly advise against Big Bang. A phased migration approach, for example, migrating backend logic and API first while keeping parts of your legacy frontend minimises downtime and lets you test incrementally. The right sequencing depends on your specific setup, which is exactly what a readiness audit helps you figure out.
The shift from Winzou state machine to Symfony Workflow. Many 1.x projects have deeply nested custom logic tied to state machine callbacks – things like order payment notifications, inventory reservations, or custom fulfilment flows. These patterns don't translate directly. You need to audit how your business events are triggered to avoid silent failures in order processing or payments.
This is not a common bottleneck anymore. Most official and major vendor plugins (MonsieurBiz, Synolia, BitBag) are ready. For the rest, the most reliable check is looking at composer.json for a "sylius/sylius": "^2.0" requirement. For mission-critical plugins that aren't ready, you have three options: wait for the maintainer, contribute a fix upstream, or fork it and replace the plugin with your custom Sylius 2 version.
It works in two ways. First, it accelerates repetitive mechanical refactoring – migrating service definitions to attribute-based configuration, updating state machine configs, flagging deprecated patterns. Second, we use it to generate project-specific tooling: automated migration scripts, codebase analyzers, and validation checks crafted for your exact setup. The result is faster, more predictable execution. Your senior developers stay focused on architecture and business logic instead of grep-and-replace work.
Frame it around velocity and risk. A store on Sylius 1.x will eventually hit a point where adding new features takes twice as long due to legacy constraints. Core bugs in 1.x won't be fixed, and security support has a deadline. Sylius 2.x with its modern API-first approach, newest Symfony version, Twig Hooks and Bootstrap increases developer velocity. Staying on 1.x also means staying on an ageing Symfony track, which creates security compliance exposure – something boards understand immediately.
