How to Choose a CMS

I was working on writing this for the upstatement.com blog when I was laid off, so it is unfinished - it would have gotten at least 1 more editing pass and had some images added to break up the text more. But I'm still proud of the actual content and want to share it, even unfinished.

Upstatement engineers pride ourselves on being tech agnostic. For us, this means we aren’t zealots about using a “standard” one-size-fits-all solution, and we keep our minds open when assessing the best content management solution for each client. There are situations where we recommend WordPress, or Craft CMS, or Contentful, or Netlify CMS, or something completely different. Here are some of the factors we consider when choosing which CMS to recommend when that question arises.

Initial Considerations

1. Existing Infrastructure

The first thing we determine is what the client is using currently - if anything. What’s their experience been like with their existing system? Have they been using many plugins? Do they have biases towards or against any particular options? What have they encountered for pain points?

For instance, if a key stakeholder hates WordPress and we don’t feel like we can alleviate that friction with plugins or training, that might be reason enough to eliminate it from the list of options early. Some things can be worked through, but it’s good to know early if there’s anything that can’t be. We want to present them with useful tools that make their jobs easier.

2. Content Needs

Once we understand the current infrastructure, we can get into the quantity of content and how it is going to be moved over to the new site. We usually favor the Block-driven approach put forth by WordPress’s “Gutenberg” editor - essentially, any type of content is a “block” of a different type: You might have a block of text (as a paragraph), or a block that’s an image, or a quote.

We often take this further, offering each block different settings that are appropriate to it. Things like alignment (is the image full width? does it float to the left or right of the text?) or whether the text has a dropcap, and so on and so forth.

The amount of block types and different options within each allows content to be much more dynamic than simply a wall of text - but this also means that there isn’t typically a single-click import for moving over content. If we wanted to just import the text and treat it all as text blocks, it would still feel flat compared to what we could do with our blocks.

Asking the question “How much data is being migrated and whose responsibility is it” early is important, especially because data migration can be very time consuming. If the timeline is short and there’s a ton of content, that alone can be an encouragement to stay with the existing (or an equally familiar / safe) CMS.

I once ported The Trace from an old version of WordPress to a newer one and even staying within the same CMS, migration was more difficult than anticipated. Partially because there were a bunch of plugins that had changed or been abandoned, and partially because the old site was created before the Gutenberg editor was widely used. The entire migration process took longer than 3 weeks, with a lot of manual repairs and re-checking needing to take place across their thousands of articles.

If we’re setting up a brand-new site, then the question becomes more about what kind of content there will be - if there are intended to be a lot of different types with a plan to have a lot of recirculation and relationships between different content types, that can be a good case for Craft, because those connections are part of where it excels. If it’s more of a single page or simple site, you might look at something like WordPress or even Gridsome or Gatsby. If the desire is headless to support mobile apps as well, we might lean towards Contentful (though WordPress and Craft do also have headless capabilities, so then it is also a matter of priority for when they want to go headless). We want to play to our CMS’s strengths where it helps to push content further.

3. Editor Experience

Many editors are already versed in WordPress, since it has dominated the web for a long time. But that doesn’t mean that all of your specific editors are - how many people will be working on this and how familiar / comfortable they are with the CMS can make a huge difference.

This also isn’t just about levels of comfort and familiarity - though that can help. As in our first question, we want to know where their points of friction are, and what kinds of things they might need.

Is SEO control important to them? Do they need an approval process for content changes before things go live? Do they need content to expire? Are there user subscriptions that affect content access? Do they need to limit which editors can make changes to which content type? How often do they post? Are there things that they want to do now with their content that they can’t? There’s a lot to dive into here.

The most important thing to remember as we go through these steps is that when it comes to editorial sites, the content is the product. You want users to be able to get to it and you want editors to have an easy time creating it. Everything should be, in some way or another, in service to the content.

4. Support

Clients are ideally going to stick with what you build for 3-5 years before exploring another re-platforming or redesign. But that doesn’t mean that nothing happens in that time - it’s still going to grow and change from its initial conception - it’s supposed to. But even in those times when it doesn’t, there will still be bugs to fix, tweaks to make, software updates to facilitate, and there needs to be someone who can do those things.

If they have a team, is that team ready to be on board with our recommendations? Do they have specific needs or wants? If they do not have someone already, how hard will it be for them to hire help - either as a single contractor or a maintenance partner?

This is another area where Craft and WordPress really shine, is they have large communities. Going with a more unknown CMS is something we generally only recommend if the client has an engineering team already who is on board with that.

I had a client once who was initially resistant to the idea of using Craft CMS because their engineering team was talented but lacked anyone with PHP expertise - but the size of the community, sheer number of plugins, and Craft’s wonderful support and stability helped convince them it was the right choice - and they’ve been very happy with the decision.

5. Price

Is what we’re offering within their budget? WordPress is “free” but there are still some plugins that cost money. Contentful has come down in price but used to be well outside of what a lot of clients could justify. And it’s not just the up-front cost - sometimes plugins have annual subscriptions, there’s options around caching which can be costly, and of course there’s hosting - it can all add up quite quickly.

Hosting itself can be tricky because there isn’t a strong correlation between monthly users and actual needs and how that maps to a plan. Say you have 10,000 users in a month, when those users hit the site makes a big difference. You could have 28 days of 100 views each and then get hit hard for more than 7,000 views on a particular day. We ran into this situation on the Boston Symphony Orchestra website - days when tickets go on sale have massive spikes in traffic. We have to account not only for the cost of hosting there, but also that our proposed solution can support the influx, and also not give them outrageous billing costs for when the traffic is (relatively speaking) much lower.

Because of situations like this, we often recommend hosting solutions that are easy to scale up and back down as needed. But there’s a fine line with the cost and user experience where you don’t want either to suffer. Can we help cut the traffic weight down a bit with caching? How “to the minute” vs “within the hour” does the data need to be up to date? Making a site for a venture capitalist firm, it’s unlikely that having the data slightly behind would be a problem - but they’re also unlikely to have a ton of traffic anyway. But for a news site, having the breaking news available is a lot more important. It’s about finding that balance and keeping it affordable.

6. Internal Value

Most of the other criteria are on equal footing, but this is the absolute last consideration for a reason. It is not itself a reason to recommend one CMS option over the other, but is instead something to think about in the context of a new project, which is “would using this technology increase our capabilities?”

I had a project once where the client was emphatic that they wanted to use Google Docs as their CMS , which I do not recommend ever, but was a hell of a learning experience (possibly a future blog post coming about that?), and you know what, I (surprisingly enough) did use the learnings from that on another project.

It doesn’t have to be a huge departure like that, though - It can be exploring a different hosting provider, or having public-facing user accounts with Craft CMS and tapping more into its API side. It can be something like leaning more into i18n translation support than we’ve done before, or trying something other than Storybook for building a React component library. I recently took a gamble and tried out Servd as a Craft CMS host, even though I’ve had consistently positive experiences with Arcustech , just to see what it was like and how it compared.

At Upstatement we are always looking to broaden our knowledge and experience because it makes us better prepared for new projects. This is part of tech agnosticism - We do not simply build the same thing over and over. I myself have worked on more than 8 projects made with Craft CMS, and they’ve all been different and I’ve learned something new on each one.

Consider this more of a “cherry on top” / added bonus, rather than a reason to choose one CMS over another.

Evaluating

Sometimes the optimal solution is quite clear, but when that isn’t the case, what I will typically do is outline more specific considerations for this project, which is essentially just organizing my findings from the questions above.

I make this into a table and break things into categories. As an example, these are just a few real considerations outlined for a project. There were many more, this is just meant to be an example snippet.

If there isn’t a standout solution at this point, the next thing is to make another table, because we love tables. In this case, we evaluate where exactly each CMS being considered falls.

Again, here is an abridged real example (which also may be somewhat out of date):

🟢 = Comes out of the box or is very easy to implement
🟡 = Limited support or time consuming to implement
🔴 = Not supported by the platform or very difficult to implement

And so on, typically evaluating them across ~20 different categories. It’s likely that you have a strong feeling by this point - but even if you don’t, that can be okay, because the next step is the same in either case.

Sharing

It sounds silly to say, but our recommendations are just that - recommendations.

I can present data and reasoning and say that WordPress is what we feel is the best solution for this project because of x, and y, and z - but if the client wants Contentful, at the end of the day this is their site and we want them to have the tools they feel are best.

This isn’t to say that the “customer is always right” - sometimes the fear of something new can cloud their judgment, and we have to evaluate when those moments are happening. It’s okay to say, “We strongly feel x” or “Can you tell us what swayed you to want y?”, and to try and make the case in a different way or to quell fears, especially when we think they’re leaning towards a solution that doesn’t actually meet their needs.

In any case, this is the part of the process where we share that recommendation. And sometimes our recommendation isn’t strong, it could be a 6 of one, half-dozen of the other kind of situation, and we may ask the client if they have a particular leaning on it, but generally we still pose one as the recommendation.

But what I like to do here is give just a ton of information. I share all of the data we’ve accumulated so far - what we’ve identified as considerations, how we rank the comparisons across CMSs in these areas, and when I do give the final recommendation, I outline exactly why, highlight other projects we’ve done with that technology, and I also explain why another option may not be optimal.

Generalization

At a certain point, knowing which CMS is right will become second nature. You’ll have done enough on multiple of them to have an innate sense of what their strengths and weaknesses are, how much they do or don’t fit the client needs, and what compromises can be lived with.

With that said, even with a solid gut recommendation, it is still useful to go through the steps above, because even if it doesn’t change your recommendation, there can be things that you miss. You don’t want to get several weeks into production and then realize that you never considered a caching strategy and you now need to re-evaluate hosting. It is about considering the full scope of the project.