Choosing Your CMS: A Complete Guide

Share:

    Launching a publication?

    Try Pico

    Over the years, we’ve helped dozens of customers moving from one CMS to another. Though this guide is framed for those switching, most of the content that follows is equally useful to those launching from scratch.

    Jump to the end of this article for a side by side comparison of some of the more popular CMS options on the market.


    Things to Keep

    When considering a move to a new CMS, teams frequently start by detailing pain points with their current setup—all the things that could be better that you want to change. It’s often useful, though, to think through what’s working as well. As you look to improve the lives of your team of designers, marketers, editors, or other content creators, what’s already working for you that you wouldn’t want to lose?

    Considering what your team likes is crucial to ensuring your new CMS doesn’t inadvertently complicate your workflow or add additional problems into the mix. You’ll want to have full buy-in from the team that needs to make use of the system every day. Most present-day CMSs have a variety of customizable options, so it’s important to note any custom features you want in advance so that you choose a CMS whose customizability matches your needs or so you can appropriately weigh the trade-offs between getting exactly what you want and benefiting from any compensatory advantages.

    Considerations

    What’s easy: What is the easiest and quickest thing to do right now in the CMS? Writing a basic post or article with a rich-text editor is similar across many CMSs, for instance. Maybe your current CMS, such as Brightspot, makes it easy to crop images. You will want to be sure the new CMS you choose has robust options for these features that achieve parity with what you have.

    What should stay the same: What should you do your best to make sure stays the same or similar in your workflow? If no prior art exists for your specific needs in a new CMS you’re looking at, make note of this—a development team may be able to create a custom plugin, add-on, API, or other feature for your CMS. If you’re moving to WordPress’ new Gutenberg block editor, for instance, a development team may be able to reproduce—and improve upon—your workflow in the form of highly customizable blocks that make your workflow more modular.

    Collaboration support: Are there any ways that the current CMS supports collaboration that you would want to be sure you keep? Publishing workflows, in particular, can be tricky to reproduce in a new system. Consider whether there are plugins, such as Edit Flow in WordPress, that can bring your ideal workflow for editing content and collaboration into your CMS’s next iteration.

    Pain Points

    Of course, when we’re looking to move to a new CMS, it’s important to consider what’s not working about the current system. What might users of a new system aspire to achieve if their hands weren’t tied by a current CMS’s implementation? As organizations grow, their CMS needs to grow with them—and sometimes it’s just time to make a change.

    We’ve migrated data from a wide range of CMSs over the years, each with its own quirks. In show-and-tell sessions, content creators have shared with us their long-term pain points with clunky CMSs. To be successful, these customers needed to alleviate the pain of a CMS not optimized for their team’s needs. Many hours are lost to tedious workarounds.

    Considerations

    General pain points: What are the pain points in your current workflow for publishing to the web? Are there areas of the CMS, fields, or settings that are extraneous or get in the way, that you tell new users on your team to ignore? One common pain point is simply input areas with too many items or confusing options that tend to be avoided or glossed over. Alternately, are there features that would make your team’s use of the CMS far more effective (e.g., basic social-media embeds in posts) that are currently impossible? Look for a CMS (such as WordPress) that includes embeds by default.

    Top pain point: What pain point do you most hope that the new CMS will alleviate? We will often do a “how might we” exercise to pinpoint the most important needs for a new system. Teams list goals they have for their work: How might we more efficiently post to the web and an app? How might we most easily create feeds that can be ingested by other services? Then we will often work together to sort these goals into affinity groups and determine which are most important. Questions like this can help define the most important needs for a CMS and narrow the field.

    Saving time: Which part of your workflow currently takes the most time? What do you spend the most time double-checking? What would you improve? This can be recast in a positive way as you discuss it as a team: What do you hope will save you the most time each day as you begin to use a new CMS? A CMS that dramatically simplifies and streamlines your workflow, like Metro Publisher, can be a good choice for teams overwhelmed by options.

    Curation improvements: What is currently difficult about curating your homepage, section landing pages, and other featured content modules? What do you wish you could do more easily? These are often areas where teams can make significant gains in productivity with the right interface, even using something lightweight like WordPress’ Zoninator plugin to define drag-and-drop curation zones, or using WordPress’ Customizer to create a visual interface.

    Production Cycle: Integrations

    For many teams publishing on the web, the CMS isn’t the only place where work occurs. Some editorial teams still need to connect their practices on the web to a print workflow, for instance. And increasingly many teams are using chat such as Slack to collaborate. It’s critical to think through the team’s needs and desires for integrations with systems such as these.

    Considerations

    Print workflow: Where does your editorial workflow connect to a print workflow, if at all? How do you envision this might be streamlined? Many publishers, for instance, will use EidosMedia’s Méthode or vjoon K4 to manage their production workflow for print. If you are among their ranks, consider what ways you might need to connect and integrate that with your web CMS. These are fairly common integrations, but still need to be accounted for when choosing a CMS.

    Chat and voice: Do you use Slack or any other chat system as part of your workflow? Is Alexa integration important to your users? There may be ways you wish the CMS could integrate with these systems, e.g., for notifications that posts have been assigned for review or are ready to move on to another stage. You’ll also want to consider whether voice or chat interaction are desired for users on the front end, and how well your CMS and/or its plugins support this.

    Production Cycle: Planning and Collaboration

    The ability to collaborate on planning and editing documents is key to many publishing teams’ workflows. Even teams that don’t view themselves as traditional publishers need to be able to give and receive reviews and approvals of their work. The choice of a CMS can significantly help or hinder efforts to plan and collaborate, depending upon its offerings in these areas. Some CMSs give users the ability to do all planning and assigning within the CMS.

    Considerations

    Encouraging collaboration: How do you prefer to collaborate on articles or other in-progress content items? Consider options such as Google Docs, Microsoft Word documents, InCopy or InDesign, Sketch files. Does the CMS give you ways to bridge the gap between your initial planning and collaboration and getting items reviewed and posted on the site? How easy is it to embed content, such as videos, images, or social-media posts, created elsewhere?

    Document collaboration and import: Do you need the ability to import work from Google Docs or Microsoft Word? Some CMSs offer more full support for this than others, such as WordPress plugins to import Google Docs or copy-and-paste options for the Gutenberg block editor that preserve formatting. Chorus offers Google-Docs-like collaborative editing directly in the CMS.

    Collaboration difficulties: Are there any ways that your current CMS discourages collaboration that you would want to improve? As CMSs get more robust, creating, editing, reviewing, and posting content in the same CMS, in a digital-first way, has become increasingly viable for many teams. If it’s important for your team to be able to create work on the fly on mobile, for instance, a CMS that can facilitate this sort of contribution and collaboration would be a great choice.

    Production Cycle: Editorial Specifics

    Editorial teams often have specific needs for the CMS, such as creating a shared story budget, editorial assignments, and editorial workflow. The following are some items to think through if your editorial team is considering a move to a new CMS.

    Considerations

    Assignments and story budget: How do you currently track assignments or your story budget for articles? What do you wish could be improved about this? The Washington Post’s Arc Publishing system, for instance, offers a WebSked service where scheduling out articles can take place alongside other editorial functions.

    Editorial planning: Are there ways the CMS could do a better job of supporting your editorial planning process and story-idea generation? For some clients, for instance, Alley has built out custom post types in WordPress for creating article planners. These can then remain linked to the resulting story, to provide accountability to the planning process within the CMS.

    Copy-editing: Compile details of your current copy-editing and proofreading workflow. How might this sort of collaborative editing ideally work in the new CMS? Each CMS has different plugins and options available to handle this. A site’s taxonomy can be leveraged here, too—a custom post type for assignments can provide a way to replicate the workflow of a copy desk.

    Site search and planning: As an editor or writer, do you ever make use of site search in the CMS as part of your workflow (e.g., to see what previous articles have been written on a topic or verify previously published information)? If so, are there any pain points with that use case for search? Do you search on the front end or in the back end? Additionally, when you’re gathering story ideas to pitch, how often do you use the CMS in your research to see prior art on a topic? You’ll want to be sure your CMS meets your needs for being able to quickly find, consult, and reuse content on the site in your editorial process.

    Search facets: Would readers or staffers make use of additional search facets, e.g., being able to narrow down articles by date or date range, section, etc.? For specialized audiences, search facets can make or break their ability to use your site effectively. And for writers and editors, the ability to quickly find past content on a topic is important to avoiding duplication—as well as being able to effectively associate past content with new posts in recirculation modules and curation zones.

    Publication specifics: For teams that produce more than one publication, website, or app, are there ways that your editorial workflow differs across publications? If you had the opportunity, are there ways you would streamline or consolidate any portions of that? With customizations, many CMSs offer the option to power multiple websites and apps from one place.

    Posting Workflow: Content Groupings and Automation

    As you consider your CMS options, it can be useful to think through how you need to populate, group, and relate content on the front end of your site. Even if you go with a headless CMS to power a separate front end, your development team will most likely need to set up some custom fields and taxonomies to power the display.

    Considerations

    Content groupings, series, and pagination: Are there any special groupings or presentations of content you wish you could create? For instance, if you ever publish series or packages that have specific needs in terms of connecting articles to one another, or otherwise indicating how they fit together (e.g., in a timeline module), this will be an important consideration. It can be useful to gather examples from your current site or editorial planning to conceptualize needs for specific ways to connection content. If you publish articles long enough to require pagination, think through how your current CMS handles this. Bring your ideal solution to the table.

    Automation options: If you could automate anything about your current workflow, what would it be? A number of options are often automated (or that have custom automation built out) in the CMS. These might include automatically populating related and recommended recirculation modules, using algorithms to select content to place in featured or promotional spots on the site, adding SEO keywords, and cross-linking content.

    Annotation or profiles: Would there ever be cases where you’d like to annotate articles or otherwise provide additional information about specific types of people, organizations, events, or places? Some publications use their CMS to power a set of article cards or other ways of surfacing and associating this sort of information with posts that mention these entities.

    Footnotes: This is especially a consideration for publishers of more academic content. Do you use footnotes or citations in your articles, and if so, are you satisfied with your workflow for adding and editing them? Think through ways the experience of adding and curating footnotes could be improved or even automated, perhaps through an integration with a citation generator.

    Short headlines and summaries: Are there ever cases where you would want to use a different headline (e.g., a short headline) or summary in various places on the site? This is frequently the case for areas such as landing pages and recirc modules. Gather specific needs for this.

    Posting Workflow: Users and Authors

    In addition to grouping and arranging content within the CMS, you may also need custom options for your most basic publishing processes, such as adding bylines to posts and setting up users with access to work on your site. Here are some things to think through.

    Considerations

    Bylines: Are there any edge cases or nuances to bylines for your content that should be considered in the new CMS? For example, would you ever have a byline that includes multiple names with differing attribution, e.g., “Carol Anton, special to Your Publication,” or “Ann Becker, reporting from Geneva, with Brad Johnson and Joel Shoemaker”?) Think through any specific types of bylines you wish the CMS would support. It may be possible to add options within the CMS to populate common pieces of a byline and associate them with writer profiles in an automated way.

    Author management: What data need to be able to be associated with authors for your site or publication? Sometimes the data displayed for a given author differ between an author profile and an article. What level of customization will you need in this regard?

    Freelance management: What level of access, if any, do freelancers (writers, photographers, or other content producers) need to have to the CMS? Consider whether there are ways the CMS could better support working with freelancers’ content.

    User roles: What user roles do you envision being necessary in the new CMS, e.g., administrator, editor, writer, guest author, etc.? Do the same staffers work on multiple publications, sites, or apps? There may be some special considerations for how access might need to be handled (e.g., different roles across various publications for a single user). Setting up a user roles and permissions matrix can be a good way to plan for your needs in this regard.

    Email Newsletters and Syndication

    Sometimes overlooked in discussions of basic publishing workflow are the ways that the CMS can power email-newsletter memberships and syndication of content among publications and wire services. You’ll want to ensure that your CMS makes curating and moving content into these types of feeds easier.

    Considerations

    Email newsletter pain points: What is currently difficult about your email newsletter workflow? How might this be improved? Frequently, publishers find that they need better options for selecting content for their newsletters, reviewing newsletter content, and automating and packaging the flow of content into newsletters. (See our related article in this issue.)

    Cross-publication, wire, and journal syndication: How often do you share or syndicate content among publications? Do you ever syndicate or reprint content from other sources, such as wires or journal article excerpts? If so, you may have needs specific to this workflow (e.g., being able to specify a canonical source for articles, being able to add guest authors, being able to specify the source in a tag line, etc.).

    Redirects: Do you ever have specific needs regarding redirecting URLs. Some typical use cases can include when a promotional URL is used in a newsletter, ad placements and tracking, and when content is relocated or includes a misspelled URL that needs correction.

    Media Needs

    You’ll want to be sure that the CMS you choose can handle your needs for adding images, video, and more to your site. These features are often taken for granted, but the CMS you choose can either vastly simplify or vastly complicate your workflow in these areas.

    Considerations

    Inline and featured photos and video: What do you wish you could improve about your workflow for including photos and videos in articles? Images and video can become pain points when the workflow makes it difficult to add them to posts, edit them, or associate metadata with them such as credits and captions.

    Infographics and data visualization: Does your current CMS support the types of infographics or data visualizations your team prefers to use in articles? If not, what are your specific data visualization needs for the new CMS? Are there external services you use to create embeds that the new CMS will need to support? Think through all the ways you use data and infographics.

    Image reuse: Do you ever reuse images on the site, and if so, are you usually able to stick with the same caption and credit data? Or are different captions and credits needed for various article or module contexts? This will inform the level of complexity needed in your custom fields.

    Rights management: Are there any rights management needs for images that might be shared among publications or reused? Some publications have used taxonomies to power options in the CMS to associate the correct rights or licenses with various types of media in the CMS.

    Other Data Needs

    In addition to other types of custom data fields in the CMS, some of the following options may become necessary to represent in your CMS. Think about the types of data you may need to be able to associate with posts or pages on your site.

    Considerations

    Location data: There are a number of reasons you might want to include specific location data in your articles, or target alerts by area, such as using designated market areas. Are there ways that this needs to be accounted for in the CMS, e.g., geotagging of any sort?

    Timeline and event data: Consider whether your publication ever reports on events with specific timeline or calendar data that would need to be supported in the new CMS. Are there ways that entering this data could be streamlined or customized in the CMSs you’re considering?

    Analytics and Engagement

    Every site needs a way to measure how well its content is performing. The CMS can assist your team in seeing how well it’s doing and areas where the team might be falling short.

    Considerations

    Metrics: What metrics do you currently use to measure engagement with the site? Are there any metrics for which you wish you could gather better data? Think through how this information might ideally be gathered and surfaced to the publishing team within the CMS, such as through an analytics dashboard.

    A/B testing: Is there a use case for A/B testing content on the site, e.g., headline variations, call-to-action language, etc? Depending on the CMS you choose, you may find it easier or more difficult to integrate testing options into the site.

    Audience needs: Are there any needs for the user experience or CMS that are specific to your audience or your staff, that the development team might not otherwise anticipate?

    Audience feedback: Are there needs for gathering feedback regularly from your audiences? This can be built into some CMSs, either in an automated or custom way. Think through what info you might want to gather, how often you want to get it, and how it will feed back into improving the site.

    Comparing Popular CMSs

    We've compiled a quick table detailing features of some of the most common CMS choices for publishers, to jump-start your evaluation process. This is not meant to be an exhaustive list of CMS options and features, but it should provide a good place to begin your research.

    Ready to put all this advice into action? See how Pico can help you build your audience business – from high-converting email popups to fully featured membership landing pages.

    Learn more about Pico

    Other Articles from This Issue

    All issues

    Subscribe to The Byline

    Get our weekly newsletter! Actionable guides and advice for running your news and media business.

    Thank you for subscribing.