5 signs that it may be time to ditch your CMS

Bill Beardslee is the CEO of Magnolia Americas, where he is responsible for Magnolia’s business in the Americas, tending to clients, sales, lead generation and infrastructure.

At times, organizations find themselves making excuses for delays in publishing, re-configuration or heavy customization of their CMS. Fueling such excuses are a series of product-level issues that separately could be annoying. Collectively, these issues can defuse a company’s ability to use their site as a weapon in their marketplace.

Here are a few telltale indicators that it may be time to change your CMS.

1. You need two separate tools for publishing to desktop and mobile

Why log in to a desktop CMS, update content/data, logout and log in to your mobile CMS? Errors between two channels are bound to happen. A contemporary CMS should be able to manage multiple publishing channels from the same instance: enter content once, publish the same content to intended channels.

A consolidated authoring environment assures that your desktop and mobile content will be in sync, pulling your organization closer to the omnichannel promise.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

2. You need to create 6 variations of the same image

Let’s say you have a source image, and it is used in 23 target areas throughout your site, in six different height/width variations. So it is time to get busy cropping and make half a dozen variants.

This is a tedious process, as you need to verify you have input the correct dimensions and assigned the correct image variant to the appropriate target.

Some contemporary CMSs have an imaging engine that creates variants on the fly. Designate the target area dimensions (345w x 230h for the hero image on Product A landing page), point the source image to the multiple target areas and leave the rest to the imaging engine.

3. You need more than 15 minutes to publish breaking news

Assembling copy, images, selecting tags (maybe creating new tags), previewing in multiple channels and/or browsers, and kicking off workflow shouldn’t be an 8-step process. The more recently created and improved CMSs offer a highly flexible UI for the editor. This UI allows developers to pull all of the features required for fast article assembly into one authoring environment.

UI flexibility can allow an organization to consolidate a layout editor, a DAM with a thumbnail view of your images, inline editing view of your page, a list of components to add/delete from the page and a tag manager all into one screen view.

After all, if publishing breaking news takes longer than five minutes, it isn’t breaking. It’s barely news.

4. Your CMS hides part of their code in a black box

This makes de-bugging difficult. If you can’t have access to the code, how are you going to find and fix the issue? Worse yet, it could make you beholden to the CMS vendor or a partner if you want to extend or customize your CMS because many proprietary vendors do not transfer development or extension rights to their customers.

5. Every new Web project means you have to re-negotiate licensing with your CMS vendor

Having the ability to spin-up new projects – whether it is a new product section or integrating your latest acquisition – is a vital part of marketing. If your license terms require that you notify your vendor of every new project – and possibly incur additional license fees – that could change “spin up” to “spin out.”

Some multi site vendors severely restrict the number of domains, sections or geographies supported in the standard license agreement. More vendors are moving toward a more fluid licensing model that allows organizations to add domains without getting prior approval from the vendor.

So what is the secret in selecting a new CMS?

Create a concise list of requirements. List your top 5 to 8 pain points. Those are commonly known as current system “blockers” that inhibit your ability to move quickly or cause you to incur undue expense.

Second, put together a Proof of Concept that will not only assure that the new CMS addresses the “blockers,” but also advances your publishing and development pace.

Do not create a 50-point feature wish list or a POC that resembles an Apache project. And remember – you will never find a CMS that fulfills all of your needs out of the box. You will find some that meet most of your needs, and from that point on it is up to your developers to extend and customize.