Upgrades

Treat an upgrade as a deployment, not a file copy. The risk is not the new code; it is the database migration, the customizations and the rollback path.

Before you upgrade

• Read the changelog and confirm the new version supports your PHP and database versions.
• Back up the database and the full web root, including uploads and .env.
• Test on a staging copy with a recent database dump. Never test on live orders.
• Note every customization you have made, especially in views, routes and app code.

Upgrade order

1. Put the site in maintenance mode if your build supports it.
2. Replace application files, keeping .env, uploads and any custom assets.
3. Run the upgrade/installer or database migrations required by the release.
4. Clear config, view, route and application caches.
5. Restart queue workers and OPcache.
6. Test login, menu, cart, checkout, payment callback, vendor acceptance, rider flow and emails.
7. Remove maintenance mode and monitor logs for the first hour.

If something breaks

Restore the database and files from the backup, not just the code. A code rollback without a database rollback is usually worse than the failed upgrade. Keep the old release directory until the new one has processed real orders.

Customizations

If you have changed core files, an upgrade can overwrite them. Keep customizations in a patch series or a version-controlled fork, and re-apply them after the upgrade. The licence includes the source code; it does not include unlimited upgrade labour.