How to transition to a new CMS ??♀?

A new what? CMS, Content Management System. Where you manage content. Where content is stored, edited, deleted, updated, enriched and more.

The CMS is almost never the end of the line for the content, but from a CMS the content is delivered to, for example, (marketing) websites, news sites, webshops, learning environments, online tools for anything and everything; basically, all content you find online 'lives' somewhere in a CMS.

With over a decade of experience as a business analyst, specifically in the field of content management, I've learned a thing or two (through trial and error, some bruises, and a whole lot of fun ??).

In this blog: 5 phases that will definitely need your attention when transitioning to a new CMS. Consecutively, the blog will cover content analysis, test content, workarounds, implementation, and parallel production.

1. Content analysis

The very first step should be thorough content analysis. What kind of content are you dealing with? What does this content need in terms of functionality? Then compare this to the new CMS. And, voila, then you'll know exactly what you need to change before transitioning to the new system.

(Of course, this is a bit more complex in real life; content analysis is a whole world on its own?where I might devote another blog to one day).

There are three possible outcomes of your content analysis:

a) The content fits the CMS perfectly and you can start moving house right away.

b) The content is not a perfect fit, and the CMS doesn't allow for any adjustments.

c) The content is not a perfect fit, and the CMS offers possibilities for adjustments, for example because it’s been developed in house.

Not to be a buzzkill, but it is almost never a). Possibly in cases where the content is not very complex, and the CMS is kind of directly in sync with the UI (use interface). This can be the case in WorkPress for blogs for example.

Option b) is a more realistic scenario; you are dealing with an "off the shelf" CMS and there is no room to customize anything. In that case, you will have to look critically at the complexity of your content.

What is the business value of storing 36 synonyms to a particular keyword, if the data shows that synonyms are never accessed? Or why should images and tables always refer to each other, when data shows that clients never navigate from an image to a table?

?? Hint: the argument "because that's the way we've always done it," is not valid.

Option c) is my personal favorite; because in this case, you may be able to have the CMS extended with certain functionality, so all your content can find a home in this new system.

This could be relatively simple things like "I want to be able to enter an alt-text to an image so that my text remains understandable, even if my customer is visually impaired". ?Or more complex features such as: "I want to be able to highlight certain parts of my text so that a read-speaker 'knows' in which language the text should be read aloud."

? An important note: just because you can adjust a CMS does not mean you have to. Just as in scenario b) you will always need to consider the business value first. If all your content is in one language, please do not develop a feature that enables you to highlight deviant languages. (Okay this is an obvious example, but I guarantee every CMS contains at least a few features that are not related to any business value at all.)

A major pitfall in the content analysis phase is drawing conclusions too quickly. Just because something applies to 50% of your content, doesn't mean it applies to everything. It is very important to involve your business colleagues in this phase; they know the content best and can also argue why those tables should refer to images, and vice versa.

The more time you invest in this phase, the more you will benefit from it in the rest of the process. And – by the way - while you are at it with content analysis, save all the representative examples, you will need them as test content.

2. Test Content

The biggest pitfall in testing whether a new CMS meets your requirements is testing with...test content. You need to use representative content.

If you are tempted to do some quick testing with the Lorum Ipsums and things like 'here comes a sub heading' and ‘placeholder for title’, you are guaranteed to get in trouble.

Because the real content apparently also 'suddenly' contained a complex table, with different cell widths, and merged cells. And, hey, apparently there are diacritics in this text, too. And what’s with the subheadings and subtitles?

You need to provide your testers with this content. They cannot know which content is representative or relevant, and you should hold them responsible. This is a business responsibility; they know their content (and their business value!) by heart. ?

3. Workarounds

About option b) “The content is not a perfect fit, and the CMS doesn't allow for any adjustments”. Of course, you need to carefully consider your requirements, which items hold value. But what happens when the CMS offers no room for adjustment, but you can not skip a certain part of your content because it contributes to the business value?

For example, your clients are accountants and formulas are a logical part of your product. The CMS just doesn't offer the ability to create or edit formulas. An example of a workaround is to create the formulas in another editor, save them as an image-type and then include the image in your CMS.

? Workarounds are not without risk. Firstly, a workaround generally remains the way it works forever (foreeeeeever). In this example, no business will ever revert funds to creating a formula-editor plug in. “Because it works now anyway".

A second risk is that you quickly tend to use one feature for two things. In this example: ‘images’ can contain either a traditional image, or a formula. This means that you cannot perform bulk actions (automated actions) on ‘images’ anymore. Suppose that for some reason all images in your product need to be resized. Say, they need to be halved. Then you would also halve all formulas, making them unreadable.

If you must use a workaround, document it thoroughly. (My least favorite part TBH ??). Which field or section or attribute do you use for what. And try to think of a way to make the workaround identifiable. In the example; give all formulas an additional keyword ‘formula’. In a bulk action to resize images, you can then exclude all images with keyword 'formula'.

4) Implementation

And then the big moment is there, the analysis has been completed, necessary adjustments have been made, workarounds have been designed - where necessary - and the testing phase is complete. The CMS can be put into use. On the technical side this is often a happy milestone ??, on the business side...somewhat less so.

Because the daily work continuous, and who even has any time at all to learn something new, and what we have now works well and why do we need something new anyway? ??

Well, why are you transitioning? It could be because the current set-up is outdated, no longer meets security requirements, is no longer supported. But also, because you want to connect to a new website that is now powered by another CMS. Because of a large-scale purchase of a CMS for an entire organization, because of standardization of work processes, because the current contract with the supplier ends...there can be countless reasons. You need to know why; you need to know it and feel it, live it and share it. Because you can not expect people to be happy with a move without being given a decent reason why.

Keep in mind that implementation is almost always phased. (And takes time). You can apply all sorts of marketing techniques in this implementation phase, because in effect you're going to be selling something. Who are your early adopters? Where do you expect resistance? What are the USPs? What perspective can you offer? What will the roadmap look like? What are the milestones? What’s in it for the customer.

It is important to know what and if anything is being driven from management/strategy. Is it enforced that everyone in the organization moves to the new system from point X? Are there exceptions or certain products that, for reason Y, don't transition now, or ever? Is there room for feedback, customer input? For everyone involved, this is very relevant to know. Everyone needs to know where they stand and what to expect. Make sure there is a shared message and that it is conveyed.

Then lastly, do not wait with implementation activities until the CMS has a 1.0 status. Using sketches, mock-ups, drawings, functional designs and all possible forms of visualizations, you can involve your users early on.

You can streamline this by, for example, setting up a user feedback group (preferably on a voluntary basis, by forcing participation you may start off on the wrong foot). You can also set up a standard channel where you share updates. (Intranet, a whiteboard in a common area, a newsletter).There are many possibilities, the important thing is to be intentional about this. The end users of a system should never be an "afterthought”.

It is always a matter of finding the balance between engaging people and tiring them with information, but you can only find this balance by trying. Possibly tiring your audience should not be an excuse not to inform people.

5. Parallel production

The content has been analyzed, the CMS tested, workarounds documented, there are early adopters acting as true ambassadors, the training materials are ready there is a migration plan and …the CMS can go live.

But hang on, there was one other thing. Because production just keeps going. And moving to a new CMS takes time. Content needs to migrate, people must be trained, the delivery to the platform has to take shape and much more. And time, we usually don't have. You can't just shut down a production for one or more weeks to quietly transition to a new CMS. Almost all content is of a daily, if not 24/7 nature.

So in many cases, you will be running parallel productions for a while. For example, for an online magazine, this might mean that you create one magazine in two systems at once. And as soon as your confident the new set-up is working, you can phase out the old system.

This parallel producing is not a bad thing, you just must factor it into your budget and schedule. It is actually a very safe way to transition. If things go wrong in the new CMS, you still have the old one.

Incidentally, this is not possible in all cases; there will also be situations where you have no choice but to make an instant switch. In that case, it is important to think carefully about backup systems and fallback scenarios. Either way, day-to-day business should not be hindered from this behind-the-scenes work.

Another ?? tip: if you do migrate through parallel productions, don't hold on to the old system for too long. If it works, it works. It helps to set up some guidelines in advance, for example ‘for every product successfully delivered 3 times from the new CMS we phase out the product from the old CMS’.

That’s it! Let me know if I forgot to mention any crucial tips. Finally, don't forget to celebrate when you’ve moved; happy new CMS! ??

#cms #contentmanagement #contentcreation #contentstrategy #content #implementation #testing #tipsandtricks #businessanalysis #contentanalysis #informationtechnology #content #blog?