Products
Ready to get started?
No matter where you are on your CMS journey, we're here to help. Want more info or to see Glide Publishing Platform in action? We got you.
Book a demo
Part 1 in a Glide three-part series to finding your perfect content publishing system.
How do you prevent yourself suffering from CMS - Content Management Sickness - the corrosive illness where old content management software drags back your technology teams two steps for every one they take forward, and you inexplicably spend multiples of the expected budget?
Well — you should talk to people who spent their whole careers using, buying, and building better content management systems for publishers, that's how.
The team at Glide Publishing Platform have been building CMSs for publishers for decades. In some cases, well over 20 years. They have unrivalled experience in publishing and content technology, and are at the forefront of the industry transition to SaaS CMS which eliminate many of the traditional problems publisher tech teams have got used to grappling with.
As users, engineers, editors and writers, production experts, CMS project leads, and as the CTOs buying the systems, Glide people have seen first-hand the problems publishing companies can face with this crucial tech, and the things that can cause projects to derail and balloon over budget.
Most relevantly, they know the commercial pressures publishers face today, and understand how the the rapid rise of "the New CMS" have become central to audience engagement and publisher success.
In this part of a three-part series to finding your perfect content publishing system, we tap into that expertise to provide invaluable insight into the questions technology leaders need to ask, and the steps to take to end the costly bouts of sickness a bad CMS will inflict on your business.
For publishers — who manage content more intensively than any other business — this is a must-read to saving money and preventing grief for when you tackle your next major CMS project to be audience-ready for today and tomorrow.
You can't use old maps to see new lands, yet publishers do it all the time with Content Management Systems.
Old business models got you an old-style CMS which you needed to build and maintain. Is that really what you want again in the future? To get the system your business will need to thrive in years from now you need to rip up the old rulebook on CMS thinking and look at your problems with fresh eyes.
It's no longer just about "managing content": CMS today have to be dynamic components in any publishing business, front and centre in making content do more, releasing developers to do more, and proactively shielding everyday users from technical concerns. It should never concern you with its flux-capacitor count, so you can fully focus on what matters: your audiences!
It's easy to fall into the trap of using the "old map" that was function-specific not business-centric. A common path towards solving what your next CMS looked like was to sit down with current end users and get them to draw up a functional requirements list to replace the current CMS with a newer version of the old one. But most users just won't have the full overview of what a CMS needs to do today.
What other software or system today gets purchased based on 10 or 20-year-old buying methods? Very few, but it happens repeatedly with CMS and explains why so many major CMS projects trap buyers into the cycle of trying to build it into a system suited to publishing, and — directly, or with a partner — becoming responsible for its code for the next however-many years. They have become a software business by accident.
Has the world of publishing not changed in the last decade? Have the demands and expectations of your readers not shifted? Are your subscriber strategies the same as 10 or even two years ago? Is your dev team doing the same things they did in 2014?
What you needed a decade ago, is not what you need now, so you should not start the process specifying requirements based on those old needs. Not only will you need to reassess your business, you also need to have a very clear idea of what you wish to commit yourself to from a technical and developer standpoint: the fewer things to focus on, the better.
Across the board, businesses are leveraging the cloud and what it offers, using cloud services to replace the software and systems they once had to build and maintain themselves.
CMS are arguably the last vestiges of that old approach to publishing tech, even as leaders realise that building your own CMS today just makes no sense due to the cost and slowdown it brings.
Being digital first — meaning in this case that all your content is created first in a single digital system, which then feeds other channels such as print where it might be edited further on page — sounds like a technical decision. But in fact it is a business and people change, in workflows and content usage.
What are the benefits? Why not just let print do their own thing, and the digital teams do theirs in sites, apps, and newsletters etc? The decision was once led by major tech constraints and some ingrained habits — "Why do we have to change? I like using Notepad!" — but tech is now the easiest problem to solve. The challenge today is simply reaching consensus that digital-first — or perhaps it's better to say, "digital-once" — gives you by far the most flexibility and efficiency.
The biggest winners will be the editorial, and the product and commercial teams. Generating content only once, destined from first keystroke to be rechannelled, redistributed, reused, and syndicated, removes multiple down-the-line problems.
The first is seamless replication across channels. You would be stunned at how many publishers today are still forced to rekey content into a second or even a third CMS, for apps, print, or subscriber-only content, newsletters, or partner deals. It is spectacularly inefficient, and pervades the problem of content being spread across multiple systems in different states.
And imagine managing a library migration when large volumes of your content was first created in a print or marketing CMS.
A good digital workflow feeds all those channels, leaving print with its own final phase for designers and subs to bring pages together with images, fonts, and layout - none of which holds up the first cut of the content which is available instantly to the other channels.
Digital-first content creation and editing places excellence earlier in the entire workstream of content which pays off throughout its life. It changes the mentality of writers and ensures consistent and well-structured content on which to build all your channels, and makes content reuse and new integrations a basic capability from the start.
Not only will you cut back on repetition of work and reduction of disparities and error, but you more easily keep editorial tone across your channels. And as a kicker, you save a fortune in time and cost trying to get all those other CMS to work together how you want.
You won't be the first struggling to get organisation-wide cooperation on a CMS implementation. We've all been there. With so many channels and revenue streams now reliant on content, getting a chorus of agreement is more critical than ever: make it your Day One priority. The trick of course is avoiding conflict and keeping everyone happy!
So who to bring into the debate?
Your tech team will shoulder the burden of making the project happen: it's almost certain to come from the tech budget and it will be a tech task to make it work and maintain it in the future. Editorial will have to use it, so they definitely need a seat at the table too. And it's commercial's remit to make money, so should they not be in the driver's seat a bit? And these days the product team is often in the middle and expected to "own" the outcomes. Oh and the marketing team doesn't want to be left holding a dud either!
So who wins? Here, the unfortunate real world outcome is often that no-one does, and everyone can end up feeling resentful.
Critical systems of record like a CMS, which underpin a business, are everyone's decision, and everyone's responsibility to get right.
Before a single technical decision is made, it is critical to build a team of champions from within all the major business units that will be leaning on the CMS to succeed.
Their role is to make clear exactly what their unit needs, and to feed back to their teams any questions and updates and make sure nothing comes as a surprise when the switchover happens. This is particularly important with editorial: get them onboarded with training and user sessions well before launch, as they will be key to making migrations go smoothly and identifying what elements are correct or incorrect, or need to be updated or removed.
Because mistakes made now will snowball over time, getting expert outside help at this stage can be a very sensible investment: a good solutions partner who has sat in on countless similar scenarios in similar organisations, like those in Glide's partner network, with an impartial voice at the right time will be like a good accountant and quickly pay for itself in savings made elsewhere.
Bluntly, are you a CMS company, or a content company? The industry of publishing is filled with so many publishers who accidentally set about becoming a CMS maker, with very little or none of the expertise and at the cost of limiting what they can do elsewhere, that we think it's a fair question to ask.
So, which are you?
It's no secret how this scenario came about: for most of the early digital era the only way to make something suitable for really intense content and publishing work was to make it yourself or take a starter CMS and rebuild it to suit newspapers, with plug-ins galore, endless bespoking, future maintenance and so on.
How you started was irrelevant - building from scratch, or building atop a generic CMS - and what mattered was all the knowledge you built into it and how much money and development staff you had to throw at it to keep it healthy. You were roped to it like Captain Ahab to the whale, with a cost-line that only points up over time.
Your technical leadership has better things to do than pour budget to non-core dev, and your devs have better things to do - things that bring in revenue and make your audiences engage more.
Having watched publishers cut the shackles on a dozen other critical systems like CRM, paywalls, identity management and so on, it is still too common for the question "What is it that makes us unique?" to be ignored.
Arguably the greatest missed opportunity we see in a CMS re-platforming project is the decision to migrate content "as is", when old content is simply moved into a new system with original structures, limitations, or errors.
Do you simply configure the new system to match the old? Or do the opposite, and drop old dirty data into your new platform, and then try and deal with all the gaps where old content lacks quality? Or worst of all — leave it behind.
It's easy to see why this happens: migrating millions of pieces of content is a big challenge, and few want to add complexity at this stage.
But a migration presents a fantastic opportunity to refresh what you have, during the move.
Content replatforming is the best moment to disassemble, clean, and rebuild everything in your library to improve its quality and usability. In fact, it's arguably the best opportunity for a publisher to make all its content suited to new and future plans. The Glide migration team has a 90-step process to clean, check, and rebuild poorly structured content into a Glide quality format that is intended to make it all as reusable and easy to work with as the new content your system will be generating in the future.
So really, a migration is a multi-stage operation:
Aim for an improvement, not just a copy! Ah, and of course it's a great time to clean historic errors too.
The publishing landscape continues to rapidly change, driven by new players, new tech, the rise of AI within and outside the industry, and most of all by changing audience habits.
For publishers, in nearly every case these days, the only safe answer to this conundrum has been to opt for cloud-native tools and services. We would be shocked if you aren't already using the cloud to a degree, but if you're restricting it to just hosting or storage, then you're at risk.
Tying your business to immobile systems isn't just slow and costly, it's a recipe for disaster. Committing your scarce dev talent to bespoking and maintaining an old-style CMS for years to come is a glaring exposure, particularly in the hyper competitive market for development talent. Your total cost of ownership soars, and attracting and retaining the key CMS dev personnel becomes your highest priority. Your top talent should be building the things that make your business successful, your content products.
Only the largest or most exotic publishers build their non-core tech any more. It's rare. The ones moving fastest, and finding the most new channels the quickest, are abandoning the old "build everything" approach for off the shelf best-of-breed platforms and integrations.
Future-proofing is therefore multi-fold: of technology, new product, people, and ultimately of cost and opportunity.
This is part 1 of Glide's three-part series to finding your perfect publishing system.
Part 2 - Editorial teams: How to get better a CMS and better results
Part 3 - Product teams: Build faster, test quicker, and launch more with your CMS
See how the Glide headless CMS enables your tech, editorial and product teams focus on business objectives, not broken technology. Request a demo today.
No matter where you are on your CMS journey, we're here to help. Want more info or to see Glide Publishing Platform in action? We got you.
Book a demo
