How to prepare a major update for your store
A major update often changes more than just the version number: database structure, module compatibility, the behaviour of certain PHP functions. Preparing it properly avoids discovering a blocker in production, at the worst possible moment.
The method before a major update
-
Back up in full
Database and files, stored away from the original server, before any manipulation. Without this step, no rollback is possible if something goes wrong.
-
Inventory the modules and plugins installed
Every third-party module or plugin needs to be checked individually: compatibility announced by its developer with the new version, date of its last published update, and whether an alternative exists if the developer no longer maintains it.
-
Check PHP compatibility
A major CMS version upgrade often comes with a requirement for a more recent PHP version. Checking that the hosting already offers that version, or planning the change ahead of time, avoids an unexpected blocker.
-
Test on a separate environment
A copy of the production store, updated on a test environment, makes it possible to spot incompatibilities before they affect real visitors and orders.
-
Read the release notes
Breaking changes (removed functions, altered database structure, changed behaviour) are generally documented by the CMS developer in the release notes accompanying each major release.
-
Schedule the update window
A period of low traffic limits the commercial impact if the update requires a momentary interruption of the site.
-
Prepare the rollback
Knowing exactly how to revert to the previous version, with the backup already verified as usable, reduces downtime if a blocking problem occurs.
Why a minor update isn't prepared the same way
A minor update or a security patch generally changes little at a deep level and stays backward-compatible with the existing setup, which justifies lighter preparation. A major update, on the other hand, can change the database structure, remove functions that have become obsolete, or fundamentally alter how certain core modules work.
It's this difference in risk that justifies a dedicated test environment for major version upgrades: a store with a catalogue of several thousand products and dozens of third-party modules is statistically more likely to run into an incompatibility than a simple store with little customisation.
Frequently asked questions
How much time should be planned for a major update?
Can the test environment be skipped for a small store?
What should be done if a module has no compatible version available?
Can a major update fail partway through on production?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.