written by
Phill Duffy

The Secret Life Of Content Management System Migrations

Insight 6 min read, April 14, 2020

In this article, we are going to talk about the steps needed, the things you need to consider, and how you can define what success looks like for Content Management System Migrations. There is a lot going on behind the scenes in your business, the CMS shouldn’t have a secret life of its own, it should be out there for all to see.

A directional sign that I liked whilst in Southampton.  Sometimes it is the simple things that catch our eye.
Photographer: Nick Fewings | Source: Unsplash

Changing a CMS should be driven by a Business Need or Digital Transformation, not just for technology sake. Instead of re-writing the definition of a CMS, I will quote from Wikipedia

A content management system is a software application that can be used to manage the creation and modification of digital content. CMSs are typically used for enterprise content management and web content management. Wikipedia

The undertaking of a CMS migration is no mean feat, so why are you doing it? Some of the reasons could be: A different Software Architecture

  • Moving away from, or to, a particular vendor
  • Reducing Cost
  • Consolidating different platforms
  • Avoiding Legacy issues and complications
  • Better integration for your business needs
  • New requirements for building Products
  • Existing CMS might not work with a new Design
  • Team / Departmental changes

These are all pretty valid reasons, if you have other reasons, I would love to hear in the comments. It is also not just a technology project; it’s a people project. This journey can not, and will not be a success unless your stakeholders are front and centre of everything.

Design meeting
Photographer: Charles Deluvio | Source: Unsplash

Complication

Once you have decided to move Content Management Systems, you need to work out the steps required to get this done. Again, this is not a trivial process, but one which needs careful planning and expertise. There should be lots of Stakeholder meetings upfront to get a shared understanding for things like the desired state, terminology or expectations.

I am a firm believer that you should always be reviewing what you are doing and refining how you do it. The ‘5 Monkeys Ladder Experiment’ comes to mind - in summary - just because “it’s the way it is done” doesn’t mean it is the way it should be done. Business changes, customer/client expectations change and also technology changes, even some people hold on to some weird work practices, let’s sort it out now. Content Management System Migrations are an excellent time to review, reflect and choose your direction for the future

Lift Yourself
Photographer: Ricardo Cruz | Source: Unsplash

There are various techniques to understand and tease the information out. Post It notes and a wall are always a great start, grouping common tasks/issues and highlighting the outliers. Asking “5 why’s” is useful to get to the root of some of the working patterns. I am also a fan of the Agile Boat - https://beingagile.co.uk/sailboat-retrospective-step-by-step-guide-workshop-video-and-examples-gallery-being-agile/You should be considering the End User of the Content/Data, not just those creating it. Developing Personas, if they don’t exist already, help you frame some User Stories for those who consume your Data.

Consider the following:

As a Content Creator,
I want to Create A Contact,
So that .....err... that’s what I do

is not as useful as

As an Existing Product User
I want to Find the Phone Number of my Account Manager
So that I can contact them about queries

A different framing of the scenario means that there are lots of possibilities for solving this User Story to benefit our dear User. There will be questions raised, which might change how you want to shape your data.

If a platform has been used for a long time, they are likely going to have tailored it to meet their requirements either through configurations, custom code or integrations to other systems. It might even be that teams within an organisation could be using the same CMS functionality in different ways - either through lack of training, working around an issue or pushing the CMS to meet their needs in novel ways. These types of usage are incredibly hard to identify, as it can fall into an understanding that it was ‘how the system was designed and how the new one will work’ - assumptions are project killers and where the work of Business Analysts make them worth every penny!

Photographer: Riccardo Annandale | Source: Unsplash

The above comes in to play when you begin to look to understand the Data that the CMS is creating, as it might not be the same as you will want to use in your new CMS. We could ‘lift and shift’ from one system to another, but you’re more than likely moving problems around and redundant data. Rubbish in, Rubbish out is the saying (or some variation). It also means just because a bucket of data in the CMS is called ‘Public Documents’ you can’t be precisely sure that some other collateral has been added which should remain Top Secret.

When you build your Content Model, you only want one Source of Truth for your data, asking questions such as:

  • Do we need our Contact Information in our CMS if it already exists in another system, can we pull that data through to where it is required on a website?
  • Do we need to write different Content for different Channels (i.e. App, Website, LinkedIn) or should we follow the Create Once Publish Everywhere (COPE) idea? Probably.

Once you have a consensus of what the ‘New World’ CMS should look, then you can work on understanding which new CMS best fits those needs. There is a large number of Content Management Systems out there. Unless you are incredibly niche, you probably shouldn’t be looking to create your own, to steal from the Agile Manifest - maximise work not done. When selecting a CMS, there is a lot to consider, such as User Experience (UX), performance, security and things like Headless vs Decoupled vs Monolith. I am only going to focus on the data aspect for now. The concerns should be, can you create the data in a better way than you could do before, do you have more opportunities to use the data effectively and, one of my favourites, if you had to do the same process again in 3-5 years, which pitfalls can you avoid.

Architecting a maintainable, sustainable, extensible, securable (and all the other, *ibles and *ables) is incredibly important.

Writing it all down

This very point is where we came to build Storism. Designing Content Models is tricky, especially if you are using Spreadsheets. Relationships between all components need to be understood by everyone, and this is where Spreadsheets fall.

Wonderspaces
Photographer: israel palacio | Source: Unsplash

The structure is not flat. An Article may have a Title and a Body, but the Contact should be selecting an existing one. You shouldn’t be Typing in anyone’s name manually. The reason is simple, if that Person changes their name then you’re going to have lots of places to go and manually update - just don’t do it, please. Visualising all of these relationships are going to help with your Stakeholder conversations.

The end of the Project is the Beginning for Content Management System Migrations

The final go-live of a Content Management System is the start. There is a massive difference from when you have all of the eyes on the Project, all the focus, Management. The challenge is what happens a day, month, a year later when some team wants a new Content Model, a change to how it works - the test is - have you put in place the governance, the support, the processes to manage this? Are you going to take a beautifully crafted system and drive it into the ground because teams are being rushed, KPIs are not being measured, tracked and adapted or Quality Gates are being skipped to push “features” no-one actually needed?

Step up
Photographer: Jukan Tateisi | Source: Unsplash