# 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.

- Source canonique : [https://allaux.fr/en/guides/preparer-mise-a-jour-majeure](https://allaux.fr/en/guides/preparer-mise-a-jour-majeure)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Back up the store in full, test the update on a separate environment identical to production, check the compatibility of every module or plugin with the new version, and only then schedule the production update with a rollback plan ready.

## The method before a major update

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **Schedule the update window** — A period of low traffic limits the commercial impact if the update requires a momentary interruption of the site.
7. **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.

## Get ahead of the maintenance window rather than react to it

> Letting visitors or customers know in advance about a planned interruption, even a short one, limits worried messages at the moment of the switch. A simple temporary maintenance page, rather than a raw error, also avoids giving the impression of an uncontrolled outage during the operation.

## FAQ

### How much time should be planned for a major update?

This depends heavily on the number of third-party modules and the level of customisation. Serious preparation and testing generally takes anywhere from several days to a few weeks before the production switch itself.

### Can the test environment be skipped for a small store?

That's possible on a very simple store with few modules, but the risk remains real: even a simple installation can run into an incompatible module or a theme that visually breaks after the update.

### What should be done if a module has no compatible version available?

In that case, you need to choose between postponing the update, looking for an equivalent compatible alternative, or having the module adapted by a developer if its source code is accessible and modifiable.

### Can a major update fail partway through on production?

Yes, that's precisely the scenario preparation aims to avoid: an incompatible module can interrupt the update process itself, leaving the store in an intermediate state. That's why the rollback plan needs to be ready before starting, not improvised afterwards.
