What to expect when upgrading your Content Management System (CMS)

• Tuesday, April 30, 2024
• By 3chillies

Upgrading a Content Management System (CMS) or Digital Experience Platform (DXP) to the latest release is often approached with some trepidation by digital teams, wary of the time, effort and cost involved. It is true that some upgrades can be significant – particularly if you’re some way behind the latest version. However, in terms of the upgrade process, it’s usually quite straightforward with an agency doing most of the heavy lifting. There’s not actually so much time and effort required from the client.

Clients often ask us what is involved with upgrading their CMS. Previously we’ve looked at what happens when you onboard with a new agency. In this post we’re going to explore the normal process that we follow when we carry out a CMS upgrade involving a platform like Sitecore, Umbraco or Optimizely.

How significant is the upgrade?

CMS upgrades come in all shapes and sizes. There can be some very minor releases that might not warrant the full approach that we outline here. Many CMS providers have also worked to make their upgrades easier and less all-encompassing. However, some upgrades can be more significant, depending on a number of factors:

• There is a major release which is a fundamental change to the structure and coding of the CMS.
• When the gap between releases has been left too long.
• When a CMS has custom code, integrations and other complexities that will make the upgrade less straightforward.
• When there are multiple sites involved.

In some more extreme cases, it can be that the cost and effort involved in an upgrade means that it is actually cheaper and more practical to do a rebuild or re-platform. As part of our process, we always ensure that we identify if doing the upgrade is cost-effective and whether other options should be considered. Most of the time we – and the client – will usually know upfront because a site has been left lingering too long on an older CMS version.

Can an upgrade coincide with other changes?

Some digital marketing teams eye an upgrade as an opportunity to bring in additional changes such as new functionality or a content restructure. We advise against this and try to avoid it, as it adds risk and complexity to the upgrade process. For example, if you are testing an updated part of a site how do you know if it’s the upgrade, new coding or even new content added that is causing an issue? It starts to get very messy.

So we would always recommend that a new website project is delivered separately, probably after an upgrade, as the team can then usually leverage improved and new features.

However, an upgrade is a really good time to change hosting arrangements. For example, we’ve recently helped a client with a CMS upgrade and also simultaneously moved over to Azure hosting.

Upgrade process: the audit phase

An upgrade can bring uncertainty in knowing exactly what is going to be involved and how much needs to be budgeted. Digital marketing teams want a fixed cost and can’t sign a blank cheque.

At the same time, agency-side we need to make sure an upgrade is appropriately resourced, so we can deliver everything on time and still meet our commitments to other clients.

To ascertain exactly what will be involved in an upgrade we always carry out an audit phase. This is separately invoiced at a reasonable fixed cost and takes between five to ten working days, depending on the complexity of the upgrade and size of the website.

Here a developer takes a fresh cut of a current website onto a local machine and then does what is known as a “brute force upgrade” to install the latest version of the CMS. From this the developer can conduct a really deep dive to see what breaks, what will need fixing and any other issues that need to be ironed out.

Hopefully the results of this will show that the upgrade will be straightforward, but this is not always the case. For example, we’ve sometimes inherited sites from another agency or where the coding is quite old, which have issues which we would not have expected.

Delivering the results of the audit

We put the results from the audit into a document that will detail exactly what needs doing and then we also compile a backlog of tasks within our DevOps environment.

Based on this, we can then provide a fixed cost for the upgrade to the client, knowing what will be involved. This will also include some contingency just in case any additional minor issues come out of the woodwork during the upgrade.

As already mentioned, if the audit has come up with issues which make an upgrade of questionable value, then we will discuss options with you.

The audit provides everybody with reassurance on the costs and effort involved. We then issue a new Statement of Work based on its findings. Once this has been signed we can them move onto “phase two” and schedule the actual upgrade.

Upgrade process: carrying out the upgrade

Generally, the actual upgrade process follow these steps.

1. We pull down a copy of all the website live databases and create a parallel UAT environment. The existing UAT environment remains running as usual, as there may need to be continuing bug fixes for the existing website, although we advise not to carry out extensive changes.
2. In the parallel UAT environment we carry out the upgrade, all the testing and remediation of any issues. At this stage there is no involvement from the client, although of course we’ll let you know how it’s going. This can last between a few weeks and a few months.
3. Once we’ve completed our work, we will then ask you to carry out testing on the parallel UAT environment. This is not usually as involved as testing for a new website and is more to check everything is running as expected. This round of testing is usually the major involvement from the client.
4. Depending on the testing, there may be further changes required, until we reach client sign-off.
5. We now schedule the actual upgrade. First of all, we will merge any new changes with content added from the current environment so the new UAT environment is up to date. At this point there will be a content freeze, so the current site and new site have exactly the same content.
6. We then put the parallel UAT environment into production which becomes the new website.
7. Now we will swap the current website for the new one, usually working with your IT team to repoint the DNS. This is often scheduled or a weekend or out of hours.
8. We’ll carry out some tests to make sure the new site is working, and we’ll ask you to do the same.
9. Finally with the new upgraded website live we will carry out some housekeeping to tidy up the environment, creating a new UAT environment from scratch and decommissioning the old production site and old UAT site.
10. An upgrade is a good time to move your hosting, so there may be a few additional tasks involved if this is the case.

Going into an upgrade with your eyes open

CMS upgrades are an inevitable part of managing a website. They can be extensive (and expensive), but going in with your eyes open about what is involved and what the cost will be, makes the project more manageable and likely to run smoothly. If you’d like to discuss upgrading your CMS then get in touch!