Sylius installation: where a self-managed launch breaks
A Sylius installation ends with a "green" storefront, and that is usually where a self-managed launch is declared successful.
The cart opens, a product can be added to it, a test payment goes through — but this is exactly where data diverges: the storefront, warehouse, and payment live in different storage systems and do not agree with each other instantly. It is too late to check this on live orders.
The most expensive mistake when launching ecommerce is a discrepancy in warehouse stock. A customer places an order, the item is effectively sold, but no reservation is set: the catalog stock keeps showing availability.
Then come either cancellations with apologies or negative stock that managers correct by hand. The cause is almost always the same — the order confirmation handler is not started, not running as a long-lived process, or crashes on the first exception and silently loses the task.
The second group of failures is payments and queues. The payment service confirms the transaction with a separate notification, and if the handler receiving it is unavailable or the notification is not verified by signature, orders hang in the “awaiting payment” status.
Some of the money has already been charged. Add the scheduler to this: without it, reservations are not released, emails are not sent, and expired carts are not closed.
Separately about the catalog. Editing a price or description without correct reindexing and cache reset triggers a full storefront rebuild — pages serve the old price for minutes, and the update waits for the run to finish.
We look at how ecommerce deployment is built around data consistency from day one, rather than after the first lost orders.
The effect of proper configuration: speed, failures, load
Installing Sylius is not unpacking an archive but configuring store behavior: caching rules for the catalog and cart, warm-up after a version rollout, indexes for real queries, queues for emails and calls to external systems.
On a demo catalog the difference is unnoticeable; on a live one, checkout time is reduced by 2-3 times, because the customer stops waiting for the page to respond at every step.
The second effect is the failure rate. While the cache is not warmed up and the queue is not limited, the first traffic after an update goes into errors, and some orders are lost at payment confirmation.
Retry handlers and careful limits remove this class of failures: the share of unsuccessful checkouts falls from single-digit percentages to tenths of a percent.
Under peak load, resilience comes not from spare resources but from the application profile: the storefront is served from cache, heavy queries and notifications move to background processing, and the cart and checkout run in a separate environment.
A sale or mass mailing then does not turn into database failure and maintains the previous response time.
We verify this with the same metrics before and after: cart and checkout response, share of error responses, number of successfully completed orders at peak, behavior under a test burst. This shows what the configuration actually delivered, not just a lucky day.
Deployment options: comparison of approaches and limitations
The choice of deployment option determines how much catalog and order logic will have to be written from scratch and how much can be reused out of the box.
Sylius on Symfony already has product variants, a cart, taxes, and promotion rules — they do not need to be designed anew, but bypassing the built-in model without core modifications is not always possible.
The trade-off across all options is the same in essence: the closer to ready-made, the more the template dictates catalog structure and pricing logic; the closer to a from-scratch build, the more custom code there is in payments, orders, and exports — and the more effort it takes to maintain.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made build | Catalog up to several thousand items, standard prices and delivery, launch within tight deadlines | Catalog structure is set by the template; non-standard discounts and calculations require core modifications |
| Customizing a standard solution for the task | You have your own pricing, warehouse, or role rules, but the basic catalog model fits | Some scenarios run into platform limitations: attribute set, category nesting |
| From-scratch build | Non-standard order logic, exchange with accounting systems, strict load requirements | Longer time to market; cart, payment, and notifications are developed and tested separately |
| Product catalog migration | The store is already running, and page URLs, stock, and order history need to be preserved | Requires attribute mapping and reindexing; old pricing rules are transferred manually |
During the task review, we compare your catalog and calculation rules with the limitations of each option and propose the one with fewer modifications.
Sylius installation and catalog configuration: work stages
Installing Sylius is not a single console command but a sequence of steps where each next one relies on the previous. A catalog with tens of thousands of items, several warehouses, and an external accounting system create discrepancies that surface on live orders. That is why we go from data audit to acceptance runs, not the other way around.
- Catalog and integration audit. We reconcile structure, stock, and prices with the accounting system and warehouse, and record duplicates, broken links, and discrepancies before migration.
- Environment deployment. We install the application in the target environment, configure cache, queues, scheduler, and access rights, and check behavior under peak load.
- Catalog model. We agree on taxonomy, attributes, variants, price and tax rules before import — edits after loading take more effort.
- Payment and delivery. We connect payment methods with confirmations, cancellations, and partial refunds, and configure delivery zones, rates, and restrictions.
- Migration and synchronization. We load the catalog and configure idempotent exchange of stock, order statuses, and customers so that a retry does not create duplicates.
- Order acceptance testing. We run end-to-end scenarios: guest and account purchases, promo code, delivery to different zones, cancellation, and return.
- Handover and procedures. We hand over access, configuration documentation, instructions for managers, and incident response procedures.
This order provides predictable acceptance: by launch there are tested scenarios, and the business has a working storefront without surprises on the first day of sales.
What the client receives: configurations and procedures
We hand over not only a working store but also everything needed to operate it independently. Below is the set of artifacts at handover: we conduct acceptance for each item together with your engineers so that the system does not remain a “black box.”
- Data schema and catalog model: description of entities — products, variants, attributes, categories, discount rules — and relationships between them, so that new enhancements do not break already configured logic.
- Role and access rights matrix: which roles exist (administrator, content manager, order operator, accounting), what each can see and change, and where bulk operations are prohibited. The catalog editor does not get access to payment settings.
- Environment configurations: parameter sets for test and production environments — database connections, queues, mail services, external service keys — with an explanation of what exactly changes during migration.
- Store documentation: how to add a product, set up a promotion, edit an email template, change texts and translations, and which operations are safe during business hours.
- Backup procedure: what is copied and at what frequency, where copies are stored, retention period, and who launches restoration and how.
- Update procedure: the order of rolling out changes to the Sylius core, modules, and dependencies, verification in the test environment, and rollback to the previous release.
- Integration diagram: exchange points with payments, delivery, warehouse, and accounting system, exchange formats, and store behavior when an external service is unavailable.
The handover of the configured system is formalized by an acceptance act: access, environments, and documentation are transferred to your team, and we remain on support according to the agreed procedure.
Case study: migrating a catalog to a new store without stopping sales
A store came to us with a catalog of 14,000 items: the storefront responded in 2.5 seconds at peak, and stock discrepancies surfaced in 7% of orders. An operator published a new item manually in about half an hour — card, images, properties, linking to warehouses. Any mass catalog publishing stopped sales for the night.
The migration was done without downtime: Sylius was deployed as a separate environment next to the running store.
The catalog, prices, and stock were loaded with migration packages, then synchronization via a queue was enabled — the warehouse wrote to the new database, while the old one continued to accept orders.
Traffic was switched in shares on the load balancer — 5%, 25%, 100% — with the ability to roll the flow back within a minute.
Metrics after migration
Peak storefront response — 0.4 seconds, share of orders with stock discrepancies — 0.3%, publishing a new item — about two minutes via price list import. The number of support requests about stock decreased by about twenty times.
Night windows for catalog updates are no longer needed; products are published during business hours.
After the switch, the old environment ran in read-only mode for a month — in case of order reconciliation and rollbacks. Now the stability of publishing relies on queue monitoring and a procedure for checking stock before peak sales.
How does a ready-made build differ from customization for a business task?
The difference between a ready-made build and customization for a business task is not in the amount of code but in where the boundary lies between changing parameters and changing the data model. As long as the sales process fits a standard scenario, configuration covers it.
As soon as a rule appears that is not in the core, custom development begins — and that is already a different commitment in timelines and support.
A standard Sylius installation provides a catalog with product variants, a cart, checkout, promotion rules, and a basic admin panel.
Store customization here goes through settings, template overrides, and discount rules: the core remains untouched, and updates are installed on top without conflicts. This is sufficient if the assortment, prices, and logistics are described by standard entities.
Then comes the fork: custom configuration is needed when a price is assembled from several conditions at once, an order goes through internal approval, a product is reserved from a partner, or non-standard roles appear in the account area.
Then custom entities, event handlers, and overridden checkout are added — this is already an extension of the core, not its configuration.
| Option | When it fits | Limitations |
|---|---|---|
| Standard build without changes | The sales process is standard: simple discounts, one warehouse | A rule outside the core has to be covered by manual operations |
| Build with template and rule adaptation | You need custom design, promo mechanics, additional attributes | Pricing and checkout logic remains standard |
| Custom development | Prices and orders are calculated according to company procedures, with approvals and partner schemes | Requires a described data model and a set of checks for each order scenario |
Data portability is the second selection criterion. A standard build is exported with built-in tools: the catalog, orders, and customers are exported as a schema.
A custom solution is transferred only together with the description of its model — without it, related entities and status history are lost during migration.
In support and development, the fork is visible by effort: a standard build is updated as a whole; for a custom one, enhancements are ported to the current branch and order scenarios are rerun.
That is why we first describe the client's processes on paper and only then say where configuration is enough and where custom code is needed. Describe the task — we will come back with an estimate and a plan.
Technical concerns: updates, load, data migration
Before work starts, technical leaders usually raise the same objections: how to release updates without stopping sales, what will happen to accumulated order history, whether the store can withstand peak traffic, and whether we can develop it on our own. We address each one based on how it is set up in a Sylius project.
How to update the store without stopping sales?
A new release is built in a separate environment, schema migrations are run on a copy of the production database, and traffic is switched only after checking key scenarios — catalog, checkout, payment, customer account.
We move carts and sessions to shared storage, so a visitor does not lose a filled cart at the moment of switching. Rollback is returning traffic to the previous environment; data is not rolled back in this case.
What will happen to order and customer history?
History is transferred in full: orders, payments, statuses, customer links, stock. We migrate at the data structure level, not by exporting to flat tables — links between an order, line items, and payment are preserved, and reports and repeat purchases work on the old data. After migration, we reconcile order counts and totals using control samples.
Will the store withstand a sale and traffic growth?
Before launch, we take a profile close to peak: catalog, search, checkout, promo code application.
We address bottlenecks — heavy catalog queries and synchronous payment calls — with caching and moving background operations to a queue, so that peak load does not turn into checkout failures.
Will we be able to enhance the project on our own?
Yes. We do not modify the core: logic lives in separate modules and event subscribers, and settings live in the project configuration.
After launch, we hand over the module diagram, migrations, and the procedure for deploying the local environment so that your team can add fields, statuses, and sections without us.
If you need a review specifically for your case on any point — describe the task, and we will come back with an estimate and work plan.Let's discuss the task: what is needed to come back with an estimate
To come back with an estimate of implementation timelines and a configuration work plan, we need not a ready list of requirements but an understanding of your situation.
Initial data on the catalog, orders, and exchange with external systems is enough — we will clarify the rest in conversation and put it in writing so that you can see what the estimate is based on.
- Assortment and catalog model: how many products, whether there are variants of one product, attributes, separate prices for different sales channels.
- Order scenarios: guest checkout or registration only, which payment and delivery methods must work from day one.
- Data exchange: accounting system, warehouse, delivery services — what already exists, in what form it provides data, and who is responsible for access to it.
- Design: mockup, link to the current site or a storefront you like — to estimate the scope of interface work.
- Employee roles: who works daily with prices, discounts, orders, and returns, and what rights they need.
- Planned volumes: expected catalog size and number of visitors, so that we can build in load headroom rather than catch up after launch.
- The date by which the store must accept orders: we build the schedule from it and outline launch preparation by week.
Describe the store task in free form and attach what you already have — correspondence with the contractor, the old database, drafts of the catalog structure.
On this basis, we will propose a Sylius installation option and come back with an estimate of implementation timelines, a configuration work plan, and a list of what will be needed from you at the start. Then we move through the agreed stages.
