The half-life of knowledge refers to the time it takes for half of all facts in a certain subject area to become obsolete. We can’t predict which facts will be disproved, but we know that some of the facts will eventually get replaced by new, more advanced knowledge in the future. Physics and mathematics are relatively slow moving in this respect, with half-life of 13 and 9 years respectively, whereas half of medical facts expire in 2 years.
Those of us who work in software development know from personal experience that technology is a fast paced industry. Web developers and digital marketing professionals have to learn new things every day just to stay relevant, and software vendors release product updates at a mind boggling frequency. Applying software upgrades is not optional because they often contain security and bug fixes essential for the smooth running of the system. However the process of implementing upgrades in a large, complex organisation is not always as straightforward and risk-free as software vendors lead you to believe.
There is a subtle difference between the terms upgrade and update. Upgrade is a major release featuring new or significantly improved functionality. Update is a smaller release usually limited to security and bug fixes. At a high level planning stage these terms are often used interchangeably.
Web content management vendors release product upgrades and/or updates multiple times a year. Here is the number of releases issued by some of the well-known web content management vendors in the last year (2020).
- Optimizely (previously known as Episerver): 95 releases;
- WordPress: 28 releases;
- Adobe Experience Manager (Cloud Service): 11 releases.
Does this mean that organisations using these systems need to upgrade dozens of times a year? The answer is, it depends.
To determine the optimal frequency of upgrading web content management systems in your organisation, explore the following areas:
- Technical complexity
- Testing
- Security and compliance
Technical complexity of the upgrade
Determine complexity of the upgrade by investigating the different flavours of custom code that your organisation added to the out-of-the-box CMS product.
- Core CMS customisations
Number and complexity of customisations of the core CMS product. These will be overwritten by the upgrade and will need to be re-implemented. - Custom plugins, widgets, and extensions
Code that interacts with CMS features which will be updated in the release, as well as code that relies on features that have become deprecated. This code may break after upgrade. - Rich-text editor customisations
Some web content management systems have their own bespoke rich-text editors, others integrate third party rich-text products such as TinyMCE or CKEditor. Any rich-text editor customisations will be at risk of breaking after the rich-text editor upgrade has taken place.
Testing of the upgrade
Consider steps required to perform a thorough testing of the upgraded system and affected websites. The testing plan should include:
- Regression testing of all the websites impacted by the upgrade;
- Testing of the web CMS functionality such as creating a new webpage, new widget, workflow approvals, uploading images and so on;
- A back-out plan of how the upgrade can be reversed should unexpected problems arise.
Security and compliance
A major security issue can quickly move the upgrade from the business as usual maintenance task to an urgent top-priority job. Whilst scheduled upgrades are generally the best way to keep on top of modern technology trends, it’s worth keeping an eye on vendor release notes for security vulnerability fixes, and re-prioritising the importance of the upgrade if needed.
Is cloud the answer?
Many cloud-based content management systems are marketed as products requiring minimum upkeep. There is some truth in this, because the core system may be set up to upgrade automatically, alleviating the need for manual intervention. Nonetheless, the main contributing factor to difficult upgrades remains to be the level of customisation. Upgrading and out-of-the-box, vanilla web content management system is as simple as clicking a button, but the more customisations you have (whether they’re in the cloud, or not) the more issues and bugs may surface after each upgrade. It is a good idea to review and challenge customisations regularly – some of them may prove to be nothing more than old habits.
How often to upgrade?
There is no hard and fast rule for how frequently organisations should upgrade their web content management systems. From vendor’s standpoint, applying every update and every patch that’s been released is ideal. It would mean that the system is constantly up-to-date and as secure as possible. Unfortunately system upgrades take time and cost money. The cost of the upgrades and the risk of breaking existing functionality prevent organisations from implementing upgrades as often as vendors would like. Many large organisations upgrade their systems once or twice a year, sometimes less frequently, depending on their attitude to risk and appetite for innovation.
Conclusion
At best, an outdated web content management system makes it harder for an organisation to achieve its business goals. At worst, it can break websites due to compatibility issues with modern browsers and code, as well as open up an organisation to a website security attack.
To determine the frequency of software upgrades for your organisation, regularly review vendor release notes and your own custom code. This technical audit will help you to create a maintenance schedule that keeps the websites in good working order for years to come.