How to choose a CMS

Which CMS should we choose

It is often the first question asked when starting a new web project - and that's not surprising.

You want to know what it costs, what you can do, how it looks and what it's like to work in. But starting a project by choosing a CMS is starting at the wrong end. After all, it's just a tool and in that respect there is no difference between a CMS and other types of tools.

• First decide what you want to do
• Then choose the right tool to do it
  
  

Trying to drive a nail with a screwdriver is hopeless. But anyone who for various reasons is stuck in the wrong CMS will surely recognise the analogy.

Project size

The expected size of the project can give us plenty of clues to determine what is an appropriate CMS. You want to choose a CMS that is neither too small nor too big for your needs. A project's size can be measured in a number of ways:

• Expected amount of traffic
• Number of websites/domains and languages
• The total amount of pages/information
• Number of integrations with other systems and their complexity
• Number of editors who will be working on the website
  
  

We can take two typical examples to illustrate what we mean

Company A operates in the service sector and expects a fairly simple website with a maximum of 150 pages. The site will be administered by one to two employees at the company's single office. The site's primary language will be Swedish, but they want a few pages in English. They need to connect two other systems: newsletter sign-ups stored in MailChimp and press releases that should be imported automatically from MyNewsdesk.

Company B is a B2B industrial company with several offices and a presence in all Scandinavian countries as well as Germany and Poland. Each country will have its own local website under its own domain name and information unique to that market. The company has a shared business system where, among other things, all products, their stock status and prices exist for each market. Detailed product descriptions and images are in a separate PIM system that is connected to the business system. Each country will have a responsible chief editor and two to three other staff members responsible for different parts of the site. They expect steady traffic volume driven primarily by the large number of products in their product catalogue - over 100,000 items. These should be orderable directly from the website.

There is quite a big difference between the needs of these two companies. That should be taken into account when choosing a CMS. Company A will probably manage with a relatively simple CMS and standard functionality. Company B will need a CMS that can handle multiple different websites within the same installation. It should have well-developed language support, be prepared for several heavy integrations and be able to handle a large volume of traffic continuously. In addition, they will likely want an e-commerce module around which all functionality related to products and orders is built.

It can be tempting to go all out and choose a CMS that contains far more functionality than you currently need just to avoid hitting a ceiling later on. Some room for growth is good, but not too much. Think roughly like choosing shoes for children: there should be plenty of room to wiggle the toes, but it shouldn't be like dressing up and borrowing mom's or dad's shoes.

Flexibility versus consistency

Do you want a lot of freedom and the ability to build pages as you please, or do you want a uniform look that doesn't put so much responsibility on the editor regarding page design? This is not only a property of the CMS itself but also a choice you make when developing the website. Still, different CMSs have different preconditions for either expanding or tightening the editing possibilities for editors.

Here too it can be tempting to leave everything open for editing - flexibility is generally a good quality. But if we look at Company A and Company B again, they will probably have somewhat different needs here as well.

Company A's website will be administered by at most two people. They sit in the same office and meet daily. In addition, both work in marketing and one has a background as a graphic designer. The prerequisites for handling a high degree of flexibility in the CMS are therefore very good. They will want to design the pages to a large extent themselves, so a more open and flexible administration interface is preferable.

Company B will have editors spread across northern Europe. Some, but not all, have prior experience of web editing. One is a salesperson, another a product manager. They will have several parallel websites for different markets in different languages. It is important that all customers, regardless of country, get the same feel for the brand and recognise the company's visual identity and tone in images and texts. For Company B's editors, too much flexibility is more of a burden. What should it actually look like? Therefore it is reassuring to know that page layouts follow the company's expression from the start and leave little room for uncertainty.

Features in the CMS that are relevant to consider when evaluating flexibility/consistency include, for example:

• Functionality for flexible layouts, e.g. the ability to build unique pages through a block structure
• Options for working with image editing
• The ability to automatically control how long texts may be
• The ability to control typography, e.g. heading sizes, text colours and different forms of lists and indents

The norm is that all of the above features are implemented when building the site in the CMS, but the degree of flexibility is balanced according to the needs.

Cost

How much does it cost? A very important question. To understand what a CMS costs you need to look at different types of costs. These can include:

• A one-time purchase cost
• An ongoing licensing fee
• Hosting costs
• Support costs

The biggest factor affecting the cost is the CMS's licensing model, i.e. whether it is a commercial CMS or licensed as open source. There are also hybrids where some core functionality is open source, but if you want certain specific modules you have to pay for them.

Commercial or open source?

CMSs based on open source will always be cheaper than commercial CMSs. It's impossible to be cheaper than free. But you should be aware that the license cost is only one of the costs you have when building and hosting a website. Again, it is the needs that determine and will decide what becomes expensive or cheap in the long run. Let's take a look at the conditions for the two alternatives.

Commercial CMSs have a company behind them that makes money by licensing its software. To be able to charge they must have a competitive product. That means they must both continuously further develop and refine their software to avoid going under, and keep their existing customers satisfied with well-functioning support, training, hosting and other services around the product. Optimizely is a good example of a CMS that falls into this category.

Open-source CMSs operate according to entirely different principles. They let anyone use the software for free, but at the same time cannot guarantee that it is constantly maintained, bug-free and competitive. It is to a large extent up to volunteers, often those who use the product, to fix bugs or contribute new functionality. The documentation that exists is also largely produced by the users themselves. Support is provided by other users, typically via forums.

There are, however, examples of hybrids, i.e. companies that have employees and a commercial business while their product is licensed as open source. Umbraco is a good example of this. The company Umbraco HQ is responsible for coordinating the development and marketing of Umbraco as a CMS and at the same time sells hosting, add-on services, training and support related to the CMS. In this way they can have a high degree of control over the CMS's development while users avoid paying license fees.

Where do the costs lie?

Regardless of which CMS you choose you will have costs. Generally they will be lower for CMSs based on open source, but you also take a greater risk without a commercial guarantor standing behind the product. Commercial CMSs also tend to be better prepared with ready and well-tested functionality for somewhat more advanced applications. What you pay via the license fee may then be something you avoid having to spend on consultant time that goes to fixing unstable code or developing functionality that simply isn't in the base product.

Hosting and support always cost money regardless of which solution you choose. Most CMSs today offer cloud-based hosting which is convenient because you get a hosting solution that is both scalable and proven. Support is almost always provided via the partner who built the website. Neither Umbraco nor Optimzely (formerly Episerver) offer support directly to end users. If you were to hire Limetta then it is we who receive all support cases. If we can solve them on our own we do so, otherwise we take it further with the CMS vendor in our capacity as their partner.

So: it is generally cheaper with open source, but there is a risk that it can still become expensive in the end if you need to develop a lot of functionality that isn't already finished or if the product isn't developed at the pace you should expect.

Poor interface - a hidden cost

There is also a cost that is hidden, but which can grow large over time without you even being aware of it. If the CMS works poorly — everything is very awkward and it takes a long time to do even basic things — editors will spend a disproportionate amount of time just trying to solve problems. Every extra hour spent on clumsy image handling, editors that misbehave and pages that don't look the way they should costs money.

Two extra hours every week as a result of glitches is not uncommon. Spread that over three years and you get about 300 hours. That corresponds to almost an entire annual salary for a junior employee!

User interface

There was a time when user interfaces differed radically from one CMS to another. That made it an important factor when choosing a CMS. Today it is not as big a factor because CMSs tend to resemble each other more and more in both appearance and functionality. You have a media library where you upload images and documents, you have a site tree where you create and move pages around, etc.

But exactly how you upload an image or move a page can still vary a great deal. Different features also tend to be more or less developed in different CMSs depending on what the developers have chosen to focus on. A few things to look at and consider are:

• Image editing Uploading, scaling, cropping, optimizing, automatic resizing, setting a focal point in the image, etc.
• Block-based layouts The ability to create content blocks and combine them to build pages. Also the ability to create blocks that can be reused on multiple pages.
• Drag and drop Is it available and does it work in a similar way regardless of whether you are moving pages, uploading images or moving blocks?
• Number of steps or clicks to perform routine tasks How long does it take to get to a state where you can do what you need to do, e.g. replace an image or change a text? Too many steps to even get where you want can become annoying in the long run.
• Navigation and menus Can you find the features? Are things called what you would expect them to be called? Are there context menus or keyboard shortcuts?
• Users and permissions Is it clear how to create users and assign them permissions in the CMS? Can it be connected to a central user management system, e.g. Microsoft Active Directory?
  
  

Are you already familiar with it?

If an editor has prior experience with a particular CMS and has learned all its tricks, that is a factor worth considering. Having to relearn can become a hurdle to overcome when switching CMSs. At the same time, it is a mistake to choose a CMS solely based on the editors' previous knowledge, but all else being equal it can be an advantage to choose a CMS you know how to use

Which CMS are the most common?

In the survey "How Sweden's websites are doing" they have, over several years, asked companies, government agencies, municipalities, county councils and organizations across Sweden which CMS they use. There you can clearly see that a handful of CMS recur year after year. These are (in order of size):

1. Optimizely (formerly Episerver)
2. SiteVision
3. WordPress
4. Drupal
5. Umbraco and SiteCore tied for fifth place

Optimizely (formerly Episerver), SiteVision and SiteCore are commercial CMSs while WordPress, Drupal and Umbraco are open source. By far the largest according to the survey is Optimizely, but this is partly because a limited number (around 500) stakeholders were surveyed. Had, for example, all Swedish companies been asked the list would probably have looked very different.

But it is still relevant. We recognize all the CMSs on the list, but most often come into contact with Optimizely and Umbraco, which is not surprising since they are the two primary CMSs we have chosen to focus on and market ourselves toward.

Technical basis for the different CMS

All CMSs are in turn developed in programming languages and development environments. Looking at our top list it appears as follows:

• Optimizely (formerly Episerver) - Microsoft .NET
• SiteVision - Java
• WordPress - PHP
• Drupal - PHP
• Umbraco and SiteCore - Microsoft .NET
  
  

The most commonly occurring development environments are all represented in the list above. This is a factor you will need to weigh when choosing a new CMS, especially if you want to integrate the CMS with other systems you already have or if you plan to use an existing hosting environment. In general it is easier to integrate different systems if they share the same technical development environment, particularly if the systems are poorly prepared for integrations with other systems. But it does not have to be a major issue if well-documented APIs for integrations already exist. Either way you should look at this and perform an analysis before choosing a CMS so you don't get stuck in an integration that becomes unnecessarily complicated.

Another far more important factor is the team's knowledge of the development environment that will build the website. Most developers specialize in one environment because it is difficult to maintain a high level of competence if you have too many different platforms to monitor and train in. Looking at Limetta as an example, we have chosen to focus on Microsoft .NET and the CMSs Optimizely and Umbraco for that reason. This means the choice of CMS and its technical base will always have a direct connection to the choice of partner for building the web presence.

The history of the CMS

Like many other product categories, CMSs have evolved in phases. The years and phases are of course not exact, but they give an approximate picture of how development has looked from the start up to today.

Custom-built (1995–2000)

From the very beginning, virtually all administration tools were developed specifically for the individual web project. Although you got exactly the administrative capabilities the project required, it was both time-consuming and expensive to build and maintain. On top of that came the lock-in effect — that as a client you became tied to the supplier who developed the system because it was considered too complex for anyone else to take over. If you still chose to turn to someone else, the recommendation nine times out of ten was to scrap everything and rebuild it from scratch.

Reused (2001–2005)

Gradually people discovered that administration needs were similar regardless of project. Many web agencies then took the in-house system they were most satisfied with and began reusing it across several projects for multiple clients.

Because the system was originally built for a specific client in a specific industry, you could often see traces of that in how the system was structured. If the original client, for example, was a newspaper, much of the CMS was built around an editorial mindset. If the client was a design studio or a premium brand, the focus lay more on finish and design. During this time the choice of CMS was truly decisive because the variation was so great.

At first it was more or less one-agency-one-CMS — everyone had their own CMS and tried to convince clients of its merits. But fairly soon the CMSs began to take on a life of their own.

Standalone products (2006–2018)

During this period the majority of custom-built CMSs slowly but surely disappear. Many die when the agency that developed them shuts down or is bought up. Others are simply phased out in favor of more standardized solutions.

Some, however, remain and are further developed either as open source or as commercial products. Several strong forces together contribute to this consolidation in the market:

• Agencies that grow tired of maintaining and further developing their own CMSs.
• Clients who don't want to pay for standard functionality or be tied to a specific supplier.
• A growing open-source movement.
• Ecosystems that grow up around the most successful CMSs with support, training, certifications, documentation and plugins
  
  

An increasingly standardized way of looking at web content management also emerges. The most dramatic differences between products are gradually smoothed out and over time CMSs come to resemble one another more and more in both functionality and user interface. The segmentation that still exists revolves more around the level of the installation (enterprise solution versus a simple blogging tool) and requirements for performance, integration possibilities and advanced add-on features in areas such as e‑commerce, internationalization or SEO.

Standard products (2019–present)

For many years the US consultancy Gartner published the "Magic Quadrant and Critical Capabilities Reports for Web Content Management systems," where it compared different CMSs and highlighted those it considered leaders in the industry. But as of the 2019 report that is over. Gartner bluntly states that the differences between CMSs are too small for it to be meaningful to compare them in the way it has done previously.

That does not mean the era of CMSs is over, only that the market has matured and a certain standard around CMSs has been established. The need to publish information remains. As more and more of a company's other systems gain some form of connection to the web, the role of the CMS is strengthened. Organizations want to offer their customers all their services in one place, whether it concerns information or functionality, and in that context the CMS often functions as a central hub.

Headless CMS

Headless CMS is a collective term for CMSs that, unlike traditional CMSs, do not generate any pages on their own. Instead they expose the information editors enter via an API which can in turn be used to create pages completely separate from the CMS. In other words, the tight coupling between the CMS and the pages that characterise traditional CMSs has been broken and the CMS is said to handle content — another system decides what the content should be used for and handles the views. Or in technical terms: the backend and the frontend are separated.

Headless is somewhat of a buzzword right now and you can therefore be tempted to adopt this architecture just to feel technically cutting-edge. But at its core it is simply a long-established architecture (APIs) applied to a CMS.

When it comes to headless CMS there are primarily two scenarios where this type of architecture can offer significant advantages:

• You have several different channels that need to be served with information from a single central CMS. You might have two different websites and an app that all need to be supplied with content from the same source. By setting up a headless CMS you get a single system in which you manage the content and all websites and apps then fetch their information from there. If you want to add another channel later that's perfectly fine as long as it can talk to the API the headless CMS exposes.
• You have a data-driven web app where CMS functionality is not central to the project. If you are going to build an application whose primary data source is not a CMS you should consider headless. It will most likely already be built from the start to fetch its information directly from APIs and to be able to generate views from that. Plugging in an API exposed by a headless CMS alongside other data APIs is relatively simple.

But if you only have a regular website there are no direct advantages to choosing headless.

Adopting this architecture also comes at a cost in the form of downsides. A major drawback is that you cannot preview the information you enter into the CMS because the CMS itself does not generate any pages. It also means that all the functionality built into traditional CMSs for generating pages must be built completely separately.

In conclusion

In this article we have spent a great deal of time and effort compiling our collective experience regarding the choice of CMS. Hopefully you have gained a little better understanding of what to look for when comparing different CMSs in order to find the one that best suits your needs.

Would you like to know more about CMS?

We can tell you more about the pros and cons based on your needs.

Contact us

Also read