Shopware Major Upgrade: Plannable Onto the Current 6.x Line
A version jump is not an update, it is a project: extensions, templates, database and server environment have to move together. We plan the route, rehearse it twice on staging and run the cutover with a defined way back — fixed price after a free system analysis.
5
phases in the upgrade project
2
rehearsals before the cutover
48 h
rollback window after go-live
24/7
monitoring during stabilization
As long as a shop stays within its main version, updating is routine: read the changelog, test on staging, deploy in a maintenance window. A jump to a new main version changes the statics. Interfaces that extensions build on are replaced; the template system gets new rules; the database is restructured by migrations; and the server environment has to provide the PHP and database version the target release requires. Attempting this during live operation puts exactly the order path at risk that carries your revenue. This page describes how we set up a major upgrade of Shopware Community Edition as a project of its own — and how it relates to ongoing Shopware maintenance.
The Route of a Major Upgrade
Minor or Major: Why the Difference Matters
Within a main version one promise holds: interfaces stay stable, extensions keep working, the template system behaves as before. That is why minor and patch releases fit into a normal maintenance cycle — with backup, staging test and rollback point, as described on the Shopware maintenance page. A major upgrade deliberately suspends that promise, because it changes exactly the places that previously had to stay untouched.
In practice this means: an extension using a removed interface stops working after the jump — it has to be updated, replaced or retired. A template override that copied a changed template will afterwards show either outdated content or nothing at all. And a database migration that aborts halfway leaves a state from which only a backup leads back. None of this is unusual or dramatic — it is the reason a major upgrade needs its own planning instead of a maintenance window.
| Aspect | Minor / patch release | Major upgrade |
|---|---|---|
| Interfaces | Stay stable within the main version | Are extended, replaced or removed |
| Extensions | Usually keep working unchanged | Every extension is assessed individually |
| Theme and templates | Overrides mostly remain valid | Overrides are matched against new templates |
| Database | Small, fast migrations | Extensive migrations with runtime and ordering |
| Server environment | Unchanged | PHP and database versions often need raising |
| Approach | Maintenance window under the ongoing contract | A project with analysis, rehearsal and cutover |
| Way back | Rollback point from the maintenance cycle | Planned way back with a defined window |
When a Major Upgrade Is Actually Due
No more security updates
Once the main version in use no longer receives security updates, known flaws stay open permanently. From that point the upgrade is the only robust answer — background on the security updates page.
The PHP version runs out
When the PHP version in use reaches the end of its support, it pulls the shop with it. The correct order — runtime first, application second — is described in our article PHP EOL Management.
Extensions fade out
Vendors stop maintaining old main versions and publish new features only for the current line. Staying put gradually reduces your choices.
Audits and evidence
Auditors, insurers and payment providers ask about supported software levels. A discontinued main version regularly turns up as a finding in such reviews.
Performance ceiling reached
When caching, database tuning and server scaling are exhausted, the next noticeable step often lies in the newer platform generation rather than in further optimization.
Planned development
New sales channels, interfaces or payment methods often require a current base. The upgrade then becomes the prerequisite for the project rather than the project itself.
The most expensive route is postponing
The Upgrade Route in Five Phases
From Analysis to Stabilization
- 1
System analysis and inventory
We record the complete current state: starting version, extension inventory with origin and maintenance status, theme and template overrides, custom developments, connected systems, data volumes and the server environment. The result is a report with target version, risks and the effort per area. This analysis is free of charge.
- 2
Compatibility matrix and decisions
Every extension receives one of three classifications: compatible with the target version, replacement needed or dropped without replacement. For custom developments the adaptation effort is estimated. On that basis you decide what comes along — and where the upgrade is the chance to shed ballast.
- 3
Target environment and first rehearsal
We provision the target environment with the required PHP and database version, run the upgrade with a copy of the live data and log where migrations abort, how long they run and which extensions behave differently than expected. The first run exists to find problems, not to succeed.
- 4
Second rehearsal and acceptance
After corrections we repeat the complete run with fresh data and measure the real duration of each step. Order path, payment, shipping, search, customer account and connected systems are checked systematically. The measured times become the cutover schedule with a realistic window.
- 5
Cutover and stabilization
The switch follows a written schedule in a window with low visitor activity, including abort criteria and a way back. After release we watch error rates, response times and completed orders closely, keep the rollback point available for 48 hours and work off the remaining details.
The Extension Matrix Determines the Effort
The core of a major upgrade rarely lies in the core itself but in the extension inventory. A grown shop often carries twenty to forty of them: payment methods, shipping services, pricing and discount logic, search additions, interfaces to the ERP, plus customizations that were once built for a specific occasion and have been running along ever since. Each of these components needs an answer as to whether it exists in the target version, can be replaced or is dropped without replacement.
We do this assessment before the first technical step, because it determines the effort of the entire project. In our experience a noticeable share of the inventory is simply superfluous — extensions that have served no function for years, disabled remnants of earlier projects or two solutions for the same problem. An upgrade is a good moment to clean that up, because every component is being touched individually anyway.
Every component gets a decision
Instead of a list of unknowns, a matrix emerges with three possible outcomes per extension. Whatever has no route into the target version is replaced or retired before the cutover — not afterwards under time pressure.
- Compatible: a maintained version for the target release exists
- Replacement needed: the function stays, the implementation changes
- Dropped: the function is no longer needed or is part of the core
- Custom: adaptation effort is estimated per development
Theme, Templates and Custom Developments
Theme overrides are the second large item. They work as long as the underlying template stays unchanged — and that is exactly what a version jump no longer guarantees. We therefore match every override against the target version's template and decide case by case whether it is carried over, rebuilt or dropped. It often turns out that a customization is now part of the standard and can be removed entirely.
- Complete inventory of all theme and template overrides with their original purpose
- Matching against the target version templates, including renamed blocks and variables
- Check of which customization is already covered by the target version standard
- Porting custom developments to the new interfaces, with a test per function
- Verification of accessibility and consent components in the frontend after porting
- Review of structured data, redirects and URL structure before release
Data Migration and Cutover
The database migration is the part that cannot be shortened. Its duration depends on the number of items, order history, customer records and media archive, and it cannot be estimated, only measured. That is precisely what the two rehearsals are for: the first shows where migrations abort or encounter unexpected data states; the second delivers reliable runtimes for the schedule. Only then is it clear whether the cutover fits into a night-time window or whether some steps have to be pulled forward.
The cutover itself follows a written schedule with times, responsibilities, checkpoints and abort criteria. Before it starts, a complete backup is created from which the way back leads; after each section there is a short check before the next one begins. Release is given only once order path, payment, shipping calculation, search and customer account have been verified. How such a window can be placed without losing revenue is described in our article Maintenance Windows: Shop Updates Without Downtime.
The way back is planned, not improvised
A cutover without a defined way back is a bet. Before the start we define at which points we abort, how long the way back takes and who triggers it. The rollback point stays available for 48 hours after release.
- Complete backup immediately before the first step
- Abort criteria agreed in writing per section
- Measured rollback duration from the second rehearsal
- Rollback point available 48 hours after go-live
After Go-live: The Stabilization Phase
An upgrade does not end with the release. In the first days, effects appear that never show on staging: real visitor behaviour, genuine payment transactions, search queries with unexpected terms, interfaces receiving records from daily business. We watch this phase closely and work through anomalies one by one instead of collecting them.
Error rates and response times
Error logs and response times are compared against the values from before the upgrade. Deviations surface on the day they arise, not weeks later — based on our monitoring.
Completed orders in view
The number of completed orders is the most honest indicator after an upgrade. A silent break in the order path shows up here first.
Catching up on performance
Caching, indexes and image delivery are tuned to the new version. Details on the approach are on the performance maintenance page.
Search and visibility
Redirects, URL structure and structured data are verified so the version jump does not end as a loss of visibility in search results.
Hardening on the new level
Security headers, file permissions and access protection are transferred to the new version and verified rather than inherited from the old configuration.
Return to regular operations
After stabilization we hand over into the normal maintenance cycle with fixed update windows — described on the Shopware maintenance page.
Is a version jump coming up for you?
We look at your starting version, extension inventory and server environment and tell you how big the jump really is — before you set a budget for it.
What a Major Upgrade Costs
Naming a flat price for version jumps would not be serious: the effort depends on the starting version, the number and quality of extensions, the extent of custom development and the data volume. That is why the free system analysis comes first. From it a fixed-price offer emerges with scope, schedule and the points deliberately not included. Only then do you decide. An overview of all other terms — ongoing maintenance, immediate help, cleanup — is on the pricing page.
Analyze first, then calculate
- System analysis with compatibility matrix: free and non-binding
- Upgrade project: fixed price after analysis, with scope and schedule
- Operations afterwards: SLA maintenance from €199 per month net
- Accompanying individual work without a contract: €95 per hour in 15-minute units
All prices net plus VAT. The upgrade project is quoted separately from the maintenance contract; ongoing operations afterwards run on the SLA tiers.
Upgrade In-House, Postpone or Have It Guided?
Three Ways to Handle a Pending Version Jump
All three occur in practice. The difference lies in who carries the risk and when it becomes visible.
Upgrade with your own team
- Included: The team knows its own customizations first-hand
- Included: No external coordination overhead
- Not included: A version jump is a one-off event — routine is missing
- Not included: Rehearsals need an environment that has to be built first
- Not included: If something breaks on cutover night, there is no cover
Stay on the old version
- Included: No project cost in the current year
- Included: The shop keeps running unchanged for now
- Not included: Without security updates, known flaws stay open permanently
- Not included: The eventual jump grows larger and more expensive every year
- Not included: New payment methods and interfaces stop being available
Guided upgrade project
- Included: Free analysis with a compatibility matrix before any commitment
- Included: Two rehearsals with live data before the cutover is scheduled
- Included: Written schedule with abort criteria and a way back
- Included: Stabilization phase with monitoring and follow-up checks
- Not included: Needs lead time — short-notice dates are rarely sensible
Three Typical Starting Points Before an Upgrade
Illustrative, anonymized project histories from our practice (project experience) — concrete figures and references are shared in a personal conversation.
How a normal update within the main version runs is described in Shopware Updates: Safe Deployment. Why rehearsals need an environment of their own is explained in Staging Environments for Safe Shop Updates, and which tests make sense after a version jump is covered in Update Testing: Avoid Regressions After Shop Updates. Whether the new environment carries the expected load is clarified in advance by a load test for peak traffic. If a system is already compromised, the upgrade is not the first step — the WordPress hacked page or emergency support is.
Key Takeaways
- A major upgrade is not a maintenance window but a project with analysis, rehearsals, cutover and stabilization
- The extension inventory determines the effort — which is why the compatibility matrix comes before the first technical step
- Two rehearsals with a copy of live data deliver the real runtimes for the cutover schedule
- The way back is defined in advance: abort criteria per section, rollback point 48 hours after go-live
- System analysis free of charge, then a fixed price; operations afterwards run on SLA maintenance from €199 per month net