December 7, 2020
Choosing a CMS is one of the most important decisions you’ll make with your marketing tech stack. There are literally hundreds of options, but we think for most marketing teams – at companies up to, let’s say, 200 employees – it boils down to just a few.
Before we get into a typology of content management systems, there is one cardinal rule that we use with everyone we talk to.
Innovate with your product, not with your CMS. You want a standard, popular, good-enough solution that lets you go fast.
- Yes, fast means that the website itself is fast – though this is achievable with most standard CMSes.
- More importantly, fast means that your CMS isn’t an obstacle for your content marketing team. A common outcome of CMS decisions is that content marketing teams end up having to use a system that they don’t feel comfortable with, that has lots of unexpected quirks, or that otherwise trips them up and reduces the speed of adding and updating content. Avoid this if you can.
Types of CMSes
Here’s how we divide them up:
Vanilla CMS. Really, this is Wordpress, though there are lots of others that follow this model (Drupal, for example, in most of its configurations. But most small companies should just use Wordpress if they’re going down the Vanilla CMS route.)
This type of CMS is a combination of an application that lets you edit – and display – content, with a database, which stores content. Each page is generated for a website visitor on demand. For example, if you visit /blog/legal-process-management, Wordpress will do a bunch of work to retrieve the blog template, populate it with the correct text from the database for that page, and show it to the user.
Wordpress is a little slow and not cutting-edge, but the software is well-understood, easy to host, easy to find help with, and has quite a lot of flexibility.
Static site generator. Think Jekyll, or Hugo. This is technically a CMS in that you use it to manage content, but it works very differently from a vanilla CMS.
All content is stored in special types of text files. These are edited to make updates, usually using a plain text editor. When changes have been made and a new edition of the site is ready to launch, the static site generator application is run either on the web or on someone’s computer. That application combs through all the text files and pre-generates a copy of every possible page someone might see, and those copies are stored on a web server.
Static site generator sites are really fast for site visitors. If you’re a developer, they also offer infinite flexibility, and are very low-maintenance. If you’re not a developer, though, static site generators make your life more complicated – you can put a graphical interface on top of them, but they’re not really designed for that workflow.
Website builder. Think Webflow. Your entire site is hosted through a SaaS app, completely managed by a third-party vendor. The mechanics might follow the CMS or static site generator models, but it really doesn’t matter because the only thing that an editor or developer sees is the ability to edit all the files and templates on the site through a web-based editor.
A high-quality website builder will work well for most marketing teams. It can be a little scary that you’re trusting your website to a SaaS somewhere, but in practice we haven’t seen problems. Some website builders severely limit your design options – you want something pretty fully-featured.
Custom or advanced solution. There’s an infinite set of these, and most agencies will try to sell these because they result in more billable hours, and they’re more interesting to build. (HubSpot’s CMS – a tempting choice for HubSpot users – also falls into this category because it works in a lot of ways that are weirdly proprietary.)
For most companies, we advise against these. They tend to have odd quirks and bugs, which violate our “go fast” rules above. They tend to be ultimately harder to migrate from, harder to maintain, and less secure. There are definitely companies that need – and should use – custom solutions. You’ll know if you’re a company like that!
What types of companies should use what kinds of CMS?
Companies with intense developer cultures are served well by static site generators. This is also true for companies where there is lots of interest in staffing marketing with engineering help (rare).
If you’ve got pretty sophisticated design help, that’s an argument in favor of a website builder – Webflow is really your best bet here. Otherwise, you may want to consider Wordpress.
Most types of CMS will work fine for most types of companies, with various pros and cons. If something is working for you, even if it’s not working perfectly, that’s solid evidence in favor of sticking with what you have.
Should I migrate to another type of CMS if I already have one in place?
If you’re asking this question – generally, no.
CMSes all come with tradeoffs. If you’ve already got the organizational structure and resources in place to support Wordpress, and you’re using Wordpress, stick with Wordpress. And rarely should you switch between CMSes in a particular category – don’t migrate from Wordpress to Drupal without very compelling reasons for doing so.
There are a few exceptions to this rule. These all assume you’re feeling significant pain from your current solution and have specific reasons for wanting to switch.
- You’re in the wrong category altogether. You’re a company with an intense developer culture that would really respond to using a static site generator, but you’re using Wordpress.
- You’re using an unpopular or custom solution and have the resources to migrate to something more popular. You’re using ObscureCMS or HubSpot CMS, and you have budget to move to Webflow. (Or Wordpress, for that matter.)
- A significant marketing resource shift is taking place. You used to have 2 front-end developers in marketing who maintained your Jekyll (static site generator) site, but they left, you need the open slots for demand gen managers, and an agency will build and maintain a site based on something standard for you.
- You have 2 (or more) CMSes. The reasoning behind having 2 CMSes is generally that you want a different workflow for more static pages like the homepage, as opposed to templated pages like blog posts. But it’s hard to keep design and other important aspects of 2 CMSes in sync, so you usually end up looking like you have 2 slightly different sites, which causes a visitor experience that reflects poorly on your brand.
There’s no magic in any of these choices. Generally, you should use something conventional and well-supported. Innovate in your product, not your marketing stack.