The right choice of content management system (CMS) still has far-reaching consequences for the success of web projects, but it no longer has the same degree of influence on implementation. Instead of defining all the technical boundaries and guidelines, the focus has changed to dealing with the editorial tools of the CMS, because most services and functions are now distributed across different systems. In this way, monolithic constructions are avoided and updating or exchanging subsystems is made possible.

CMS in Context

Today, content management systems hardly stand alone, but are supplemented by a multitude of subsystems depending on the system complexity. For example, an external search engine supplements the internal index for an onsite search, a media management system replaces the internal image database, video or podcast hosters stream media content and SaaS-based shop software brings products online. The CMS »only« takes care of the processing and provision of content.

Even the frontend of a website can be developed and maintained completely separately from the CMS, so that either one or the other can be replaced without having to relaunch the entire website (headless approach). This approach also allows freelance developers, for example, to edit and further develop the frontend without having to know the CMS.

Furthermore, the fragmentation of services not only allows for easy exchange, but also gives the system itself room to build up new complexity. In the case of a shop, a proprietary system can offer much more depth when it comes to payment options, user management and security than a CMS could - and then only with considerable additional effort.

Selection

For most web projects, a variety of CMSs can be used, each of which has certain advantages and disadvantages. The right choice is often decided by details that only become apparent in the course of the project. The choice of CMS should therefore not be made too early in order to avoid that one of the decisions can only be reversed later with increased effort. 

Drupal

Drupal is a widely used open source CMS with a broad developer community. It is suitable for medium to large web projects and impresses with its completely free configurability, which, however, also places great demands on the development.

A use of Drupal is characterised by the following advantages: 

• Complete REST API for the integration of third-party services
• Extensive developer community and numerous plug-ins available
• Multilingualism is part of the core
• free licence model
• external frontend setup possible
• Connection of MAM possible

Potential disadvantages of this CMS, on the other hand, are as follows: 

• as an open source CMS, exploits are very likely and require regular updates
• the need for configurations can affect costs
• the implementation of custom code solutions through plug-ins and individual programming increases maintenance costs
  

Magnolia

Magnolia is an enterprise CMS from Switzerland that has attracted a lot of international attention. Among others, they have clients like the New York Times or BMW on their customer list. The CMS is based on a hybrid approach consisting of a fixed core CMS for which a fee is charged, a very reduced free version, and a broad partner programme consisting of development and integration partners.

The system is characterised by the following features: 

• Very good multi-site and multi language setup
• WYSIWYG editor
• slim, tidy backend
• full API 
• encapsulated authoring system (problems on one system do not affect the other = more stability for the live system)
• Source code not publicly accessible, therefore fewer exploits
• international support 
• Update guarantee and longevity through robust company
• Numerous plug-ins and extensions available
• Very good price-performance ratio

Potential disadvantages of this CMS, on the other hand, are as follows: 

• There are fixed licence fees each year
• Smaller developer community
  

Paid vs. free CMS

The idea of preferring a free CMS to a paid one is often obvious, but it ignores the subsequent costs. The open source CMS are initially free of charge, but must be maintained and updated at much shorter intervals, also to avoid security gaps. In addition, extensions from the community are often created without any guarantee of longevity. (Just because programmers have a great module today does not mean that they will still maintain it tomorrow). All this drives up the follow-up costs. Paid systems are more stable in terms of maintenance, require fewer updates, are more secure and the failure of competences is less likely.

Appearance and quality assurance 

A well-known problem is the loss of quality in the frontend due to use that does not correspond to the concept. One measure to counteract this loss is well-trained staff and clear documentation. If every editor always knows how to fill a page, quality is maintained. 

Another measure is to restrict the corresponding options in the backend so that pages may only be filled in a certain way. These rules can then not be disregarded. 

Both actions have advantages and disadvantages:

• Very restrictive templates guarantee a uniform layout, but cost editors a lot of flexibility when it comes to putting new content into a template that does not know it. Even small adjustments then have to be made by the agency or result in a very confusing template catalogue.
• Good documentation is useful and can allow free templates, but is not bound by fixed rules. Nevertheless, in order to ensure consistent quality, a final edit is needed to ensure the consistency of the website. 
  

We have had the best experience with a mixed form. Templates should restrict as much as necessary and allow as much as possible. The rest must be achieved through a trained editorial team, a well-commented backend and comprehensive documentation. The exact ratio must be determined in the project. 

Documentation and knowledge transfer

Websites have long ceased to be projects, but processes that can last for years laufen .

During this time, a lot can happen on the part of both the client and the service provider. Especially the loss of knowledge due to the loss of employees or due to a lack of practice and experience in the project is an ever-present danger. 

Both points can be countered with good and, above all, ongoing documentation for both technology and editorial staff. 

The technical documentation is part of our quality management and ensures on the one hand that we still understand our own systems tomorrow and on the other hand that we can also hand over projects to other service providers in the case of the end of a collaboration. This documentation takes place in parallel to the development process in the form of tickets that document both the conceptual consideration, the design and the technical implementation and provide the corresponding references to the repository. 

Editorial documentation is a separate service and can take many forms from a training course, to a handout, to a dedicated website. 

We have had the best experience with a combination of training and small tutorial websites. The direct Q&A situation allows the deepest transfer on a specific topic. These trainings can take place online and can also be repeated after the launch. An online documentation complements the trainings and gives instructions on the most important production processes and additionally secures the appearance of a website. We deliberately choose not to use PDFs or videos here, as both formats are too hermetic to be adapted afterwards. If something changes on the website, a new file has to be created, which can lead to high follow-up costs and version conflicts.