Upgrade/update policy e-commerce platforms

7 January 2024

Why update and upgrade?

Regular updating and upgrading is important for keeping software "healthy." The vendor is constantly coming up with improvements; consider:

  • Bugs/issues
  • Increasing performance
  • Improving security.

Software uses various libraries of code, which in turn have their own updates and upgrades. An e-commerce environment is live connected to the Internet, publicly accessible; so it is important to keep the environment stable, reliable and secure. Another important reason to update regularly is the maintainability of the system. Newer versions are easier to maintain and have support from the vendor (e.g. Shopware, Magento, Bigcommerce). Also new (custom / customer specific) features are easier to develop against a recent version of the software.

Version designations

To indicate the scope and impact of an update, (semantic) version numbers are usually used. These have the following standard structure:

[Marketing Version] [Major Version] [Minor Version] [Patch Version]
For example, Shopware 6.5.2.1 or Adobe Commerce 2.4.6-p3

  • A Marketing version is a commercial designation for the software generation and is outside of updates/upgrades. When a software generation moves up a version it usually means re-implementation.
  • A Major version means a big step, which is almost always accompanied by systematic changes, requiring parts of the implementation to be revised and extensive testing. We refer to this as an "upgrade.
  • A Minor Version means a smaller step, which in principle should not contain any systematic changes. An implementation is supposed to keep working without too many changes. We refer to this as an 'update'.
  • A Patch version is an even smaller step and brings no new functionality. It usually only fixes security and performance issues.

How often do you update and/or upgrade?

The update and upgrade policy may vary from organization to organization. XSARUS stands for quality, reliability and security, it is therefore important to maintain at least one supported minor version. When there is regular development of the platform, it is desirable to keep up with at least all major versions. This then usually leads to a major upgrade once every 2 years. When high-frequency changes are made to the platform, our recommendation is to install minors as well. In a low rhythm, updates usually have much more impact than in a high rhythm, because the steps are smaller and experience is gained with the process. We use the following strategies:

  • Baseline: platform runs at least on a supported minor version, so that any security issues can be resolved with a patch. Advice: perform review and impact analysis with a possible update.
  • Always-major: platform is running on the most recent major version or there is a concrete plan to get to this version within a maximum of 6 months. When updated, the most recent minor within this major is the goal. Approach: annually and with each upcoming major start an analysis in development flow with the goal of upgrading
  • Latest-and-greatest: platform runs on the most recent major and within it the most recent minor. It is not necessarily always necessary to install patches; this can be determined on the basis of an impact analysis for upcoming patches. Approach: once per quarter and in case of an upcoming minor start an analysis in development flow with the aim of updating

Occasionally it may be necessary to deviate from the chosen update policy, for example due to a planned development or an apparent dependence on third-party software.

The update process

The implementation of an updates and upgrades has the following process:

  1. (XSARUS) Initiation in accordance with the chosen update policy and 1st impact analysis
  2. (Customer) Agreement on schedule and expected hours to be spent
  3. (XSARUS) Detailed impact analysis and indication of what needs to be tested
  4. XSARUS) Perform updates on development and test environment:
    - Platform
    - If required: Dependent modules and plugins
    - If required: Underlying systems (server software).
  5. (XSARUS) Check for and resolve any errors (basic testing)
  6. (Customer) Perform functional tests on test environment
  7. (XSARUS) Resolve reported errors and issues
  8. (Customer and XSARUS) Planning rollout to production environment
  9. (Customer) Final verification of production environment upon delivery

Resources

Vendors keep overviews of their versions and planned support for them and indicate what changes are made to the software with each version.