In short: If your store only shows the maintenance page after an update, the update usually did not finish. Simply switching off maintenance mode is risky because code and database may not match. Finish the update cleanly first, then check the store, and only then end maintenance mode.
Why the store is stuck in maintenance mode
During an update, Shopware puts the sales channels into maintenance mode so customers do not land on a half-updated store. At the end of the update, maintenance mode is switched off again. If the update aborts before that, for example because of a timeout, too little memory or an error in a plugin, maintenance mode stays on.
Shopware describes the order of an update on the server in its guide to performing updates:
bin/console sales-channel:maintenance:enable --allbin/console system:update:preparebin/console system:update:finishbin/console sales-channel:maintenance:disable --all
If the store is stuck in maintenance mode, the update usually stopped somewhere before step 4.
Step 1: Do not switch it off right away
The obvious reflex is to switch maintenance mode off. You can do that in the administration in the sales channel's "Status" section or on the console with bin/console sales-channel:maintenance:disable --all. But if the update is not finished, you will often see an error 500 instead of the maintenance page, or worse: the store seems to work, but checkout or order emails do not.
Better: leave maintenance mode on and still look at the store yourself. The sales channel has an IP whitelist for this. Add your own IP and you can see the store while customers still get the maintenance page. The Shopware documentation on sales channels explains how it works.
Step 2: Check how far the update got
- Which version is installed? The administration or the
composer.lockfile shows which Shopware version the code now has. - What does the log say? The error message of the aborted update is in the Shopware log under
var/log. If Shopware no longer starts at all, check the PHP or web server log at your hosting provider. - Did the update run through the administration or the console? Updates through the administration abort more easily because of hosting time limits. The console usually does not have that limit.
Step 3: Finish the update
Make a backup of the database and files first if you do not have one from right before the update.
If the new code is already fully in place, run the missing steps on the console: bin/console system:update:finish runs the database migrations and other update tasks. Shopware explicitly points out that the migrations must match the version of the deployed code. If system:update:finish completes without errors, clear the cache with bin/console cache:clear.
If system:update:finish stops with an error, the message usually names a plugin or a migration. Then the plugin is the real issue: either the vendor has a newer version, or the plugin has to be deactivated temporarily and adapted later.
Step 4: Check, then go live
Using your whitelisted IP, test at least:
- home page, category and product page
- search
- cart and checkout through to an order, with a test payment method
- customer account and login
- the administration, especially orders and plugins
If styles or scripts are missing in the storefront, bin/console theme:compile often helps. Only when everything works, switch maintenance mode off with bin/console sales-channel:maintenance:disable --all or in the administration.
When rolling back is the better option
If the update fails because of a plugin that cannot be fixed quickly and the store urgently needs to be online, going back to the state before the update is often the better choice. For that you need code and database from the same point in time. Restoring only the old code is not enough once migrations have run. Also keep in mind that orders placed since the backup are lost when you restore the database. In a store that was only briefly in maintenance mode, there are usually none.
How to avoid it next time
- Test on a copy first. A test update on staging or a local copy reveals plugin problems before customers see them.
- Run larger updates on the console, not through the administration, if your hosting has short time limits.
- Check plugins beforehand. Is there a version of every plugin for the new Shopware version? Abandoned plugins are the most common reason for aborted updates.
- Back up right before the update, not the day before.
If you do not want to do this yourself every time: with the Update package I test updates on a copy before applying them. If a major version jump depends on individual plugins, the compatibility check shows which of them need adapting.
Frequently asked questions
How long should a Shopware update take?
A normal patch update usually finishes on the console within a few minutes. Major version jumps with many migrations take longer. If nothing happens for half an hour, the update has most likely aborted.
Can I just switch off maintenance mode in the database?
Technically yes, but it does not solve the actual problem. If the update is not finished, the store will run with errors afterwards. Use the IP whitelist to check the store instead, and switch off maintenance mode only when everything works.
What if I have no console access?
Many hosting providers offer SSH access, sometimes it has to be enabled in the customer area first. Without a console, an aborted update is hard to finish cleanly. That is when emergency help is worth it, before further attempts through the administration make things worse.