When to update the software to the latest available version

You should update your software as soon as your provider releases a version that fixes security vulnerabilities, and on a regular schedule for everything else. Routine updates can wait for a tested window, but they cannot wait forever. The longer the gap between your version and the current one, the more expensive, risky and disruptive the eventual jump becomes for the business.

Picture the Monday morning meeting of a regional insurance group. The chief financial officer asks why the online quoting platform needed an emergency weekend of work, and the chief technology officer explains that a vulnerability had been published for a version the company installed three years ago. Nobody had decided to skip updates. The upgrade simply kept slipping behind campaigns, audits and quarter closings until the gap was too wide to close in a single afternoon. This scenario is illustrative, but it will sound familiar to any executive who runs a commerce site, a portal or a content platform.

At this point, you may have an outdated version of software, whether it is Adobe, Magento, Liferay, WordPress or any other platform. Constantly, the providers of these platforms release new versions of their products that may not be installed in your systems. There are many factors that make it difficult to keep up with every release, and as new versions keep arriving they begin to accumulate, worsening the situation and widening the gap between the version you run and the latest one available.

Each case is different and requires its own evaluation. The questions below are the ones an executive team should be able to answer before approving, or postponing, any upgrade.

What will I gain from performing an update?

The first gain is security. Software updates often include security patches that fix vulnerabilities and protect your system against external threats. The ICX view is that these updates should be considered for immediate implementation, so it pays to be attentive whenever the provider releases a version that addresses security issues. That attention avoids problems and information leaks from your site and its users.

This position is consistent with how the discipline is described by public standards bodies. The US National Institute of Standards and Technology, in its enterprise patch management guide (NIST SP 800-40 Revision 4), says patching should be considered a standard cost of doing business, and it frames proactive patching as doing more work now to reduce the likelihood of incidents later. The same publication adds a useful nuance for executives. A routine patch does not necessarily require immediate installation, but at some point it must be installed, and the guide recommends enforcing a grace period. An emergency patch, meaning one for a severe or actively exploited vulnerability, follows the same approach on a highly accelerated schedule. So "as soon as possible" is the right instinct for security fixes, while ordinary releases deserve a planned and tested window.

The second gain is improved functionality. New software versions are designed to include improvements in functionality and error corrections. Errors or hard-to-use features in previous versions may be fixed in the new ones, and new capabilities that you had not yet identified as necessary may be included. In practice, a team that stays current spends less time building workarounds for problems the vendor has already solved.

>> Magento in the financial industry <<

Why does the cost of waiting grow every quarter?

Postponement feels free because nothing visibly breaks on the day the decision is made. The cost arrives later and in three forms. The first is exposure, because every unpatched release carries vulnerabilities that are, by definition, publicly known once the vendor has published the fix. The second is complexity, because each skipped release adds changes that must be absorbed together, so the final upgrade project grows in scope, in testing effort and in the number of extensions or integrations that might stop working. The third is support risk, because vendors do not maintain old versions indefinitely.

The Adobe Commerce lifecycle policy is a clear example of that third risk. According to Adobe's published lifecycle policy, each version receives a three-year standard support window from its general availability date, and that window includes security patches. Adobe also notes that it does not provide security or quality fixes for third-party dependencies, such as PHP and MySQL, that reach end of life during a support period. In plain terms, a store that stays on one version long enough will eventually run on software that neither the vendor nor the underlying components maintain. For a company that processes card payments and customer data, that is a governance problem and not only a technical one.

One closing idea deserves to be stated carefully. It is never too late to update, in the sense that a company can always decide to modernize. But each new version accumulates difficulty, and each version also accumulates improvements, which is why a late upgrade tends to be larger, more visible and more expensive than a series of small ones. The sooner the plan starts, the smaller the project.

What should I consider before performing an update?

Compatibility comes first. Make sure the new version is compatible with your operating system and with the other programs you use. Some updates require minimum hardware, or the update of other components of your infrastructure, such as the language runtime, the database or the search engine that sits behind the platform. A compatibility review done before the project starts is far cheaper than one done during a failed deployment.

Data migration is the second consideration. Depending on the update and the type of your system, data may need to be migrated separately, so it is necessary to confirm that all your information can be used in the new version and that no important data will be lost. Executives should ask for a rehearsal on a copy of production data, with a written rollback plan, before any production date is confirmed.

The third consideration is the ecosystem around the platform. Custom modules, payment connectors, ERP and CRM integrations and marketing tools all depend on the version underneath them. A store that sells through a custom integration, for example a distributor whose pricing comes from an ERP, needs to test that flow end to end, since a small interface change can silently alter an order total. The NIST guide recommends starting with a small group of canary assets to surface problems before wider deployment, and the same logic applies to a commerce platform. Update a staging environment first, run the critical business journeys, and only then move to production.

How do I evaluate a new update before installing it?

Start with user reviews. Before performing the update, it is important to research the opinions and experiences of other users about the new version. Check whether it has good ratings and whether new errors were introduced, because it can happen that a new version generates problems with the application. If that is the case, it is advisable to wait for a stable and well-endorsed version. This advice applies to feature releases. For a security fix on a platform that is exposed to the internet, waiting is a decision that should be made deliberately, with a documented mitigation, and not by default.

It is also important to understand how the identifier of a new update is structured, because the number tells you how much change to expect. Normally, a new update is identified by a number that increases with each version, and there are two main ways to generate that identifier.

Consecutive identifiers

In this case, one of the values in the identifier increases, for example 7.2.1. The first number (7) represents the major software version. Increasing it indicates important updates that include significant changes to the application, such as visual enhancements, functionality improvements and changes in the way it is used. The second number (2) usually indicates a minor version, or a smaller update, with additional improvements, bug fixes and optimizations but without major changes compared to the previous version. The third number (1) is often used to indicate a revision, which usually includes bug fixes, security patches or minor changes without adding major new features.

Once a value on the left increases, the counters on the right reset. If a major release occurs, the new version would become 8.0.0. This convention is formalized in the Semantic Versioning specification, which says the major number increases for backward-incompatible changes, the minor number increases for backward-compatible functionality, and the patch number increases for backward-compatible bug fixes. Not every vendor follows it strictly, so executives should confirm with their provider how a given number should be read, but as a rule of thumb a jump in the first number deserves a project, while a change in the last one deserves a quick, well-tested deployment.

Date identifiers

Some providers also identify their versions with the year and month of release. For example, if this blog were versioned, it would be labeled "Blog 2023-05", indicating the year 2023 and the month of May. This style is easy to read from a governance standpoint, because the age of any installed version is visible at a glance, and it makes it simple to set a rule such as never running anything older than twelve months.

>> How to create a simple web API <<

How do different industries experience the update problem?

In retail and consumer goods, the pressure is seasonal. Teams avoid changes before peak sales periods, and the freeze windows add up until a full year has passed without an upgrade. The practical answer is to schedule the update in the quietest weeks and to treat the freeze calendar as an input to the upgrade roadmap instead of an excuse. A security fix, however, should be able to travel through an expedited path even during a freeze.

In financial services, regulators and auditors expect evidence that known vulnerabilities are remediated within a defined time. A documented patch policy, with named owners and target dates by severity, turns a technical task into an auditable control. In healthcare and education, where portals hold personal data, the same logic applies and the cost of an information leak includes notification duties and loss of trust. In manufacturing and distribution, the main obstacle is usually integration, since ERP and warehouse connectors were built against a specific version and nobody wants to touch them. Those are precisely the cases where small, frequent updates beat a rare and heavy one.

What does this mean for the C-level?

For the chief executive, software currency is a risk and reputation matter. A breach caused by a known and unpatched vulnerability is difficult to defend publicly, because the fix existed. The board should expect a simple report each quarter showing which business-critical platforms are on a supported version, how far behind each one is, and what the plan is to close the gap.

For the chief financial officer, the key insight is that updates are a recurring operating cost, comparable to maintenance on a fleet or a building. NIST describes patching as a standard cost of doing business, and budgets that treat upgrades as occasional projects usually end up paying a premium in emergency work. A modest annual line for updates and regression testing is cheaper than a rushed rebuild when support ends.

For the chief technology and information security officers, the priority is a maintenance policy with clear severity levels. Security fixes follow an accelerated track with a canary test, routine releases follow a planned window, and major versions follow a roadmap that is reviewed every year. For the chief marketing and commercial officers, the point is continuity. A current platform is the one that supports new payment methods, new analytics requirements and new customer experiences without a rebuild, and a stale one quietly limits what the commercial team can launch.

What can I do on Monday morning?

Begin by asking your technology team for an inventory of every platform that touches customers or sensitive data, together with the installed version, the date that version was released and the current version available. Even a simple spreadsheet will reveal where the largest gaps are. Next, check each vendor's lifecycle page to find out when support ends for the versions you run, and mark any that end within the next twelve months as priorities.

Then agree on a severity rule that everyone understands, for example that security fixes for internet-facing systems are installed within days and routine updates within a quarter, and assign an owner to each platform. Ask for a staging environment and a short list of critical business journeys, such as search, cart, checkout, quote request and login, that must pass before every deployment. Finally, decide which gaps are small enough to close with routine work and which need a funded project, so that the largest risks get a date and a budget instead of waiting for the next incident.

If you would like a neutral starting point to compare keep, upgrade and replace options for the platforms in your inventory, the ICX Technology Selection Toolkit offers evaluation criteria and a decision matrix that executive teams can adapt to their own context.

How does ICX help?

ICX works with companies that run commerce and digital platforms and need to keep them current without disrupting the business. For Adobe Commerce and Magento environments, the team behind our Adobe Commerce practice plans and executes version upgrades, extension reviews and regression testing. Our enterprise application services cover the integrations that usually make upgrades hard, and our cybersecurity consulting helps define patch policies, severity levels and evidence for audits. For a store-specific view of the risks, you can also read our article on essential cybersecurity for your store in Adobe Commerce.

Frequently asked questions

Should I always install the newest version the day it is released? Not necessarily. Security fixes deserve a fast track, while feature releases benefit from a short observation period, a review of user feedback and a staging test. The aim is a predictable cadence, not a race.

What if the update breaks something? That is why the process includes a staging environment, a rehearsal with copied data and a written rollback plan. With those controls in place, a problem is found before customers see it.

How do I know if my version is still supported? Check the vendor's published lifecycle or support policy and compare its dates with the version you run. For Adobe Commerce, that information is in the lifecycle policy page referenced above.

Is it too late if I am several versions behind? No. A larger gap means a larger project, and it may call for a phased approach, but modernizing is always possible and each step reduces risk.

Who should own the decision? The business owner of the platform should own the risk decision, with the technology and security teams responsible for the plan and the evidence.

Final words. Software updates are a habit that protects revenue, customers and reputation, and the best moment to build that habit is before the next vulnerability is announced. If you have doubts about how and when to update your software, we offer a free 15-minute session where we can advise you and put you on the right track. Contact us through our contact page and we will schedule a conversation about your platforms.