Skip to main content
April 24, 2023

Balancing CMS and CCMS implementation (podcast, part 1)

In episode 142 of The Content Strategy Experts Podcast, Gretyl Kinsey and Christine Cuellar discuss balancing the implementation of a content management system (CMS), and component content management system (CCMS). This is part one of a two-part podcast.

“When you have two types of content produced by your organization and different groups in charge of that, and maybe they’re in two different systems, that it’s really important to get those groups working together so that they can understand that those priorities don’t need to be competing, they just need to be balanced.”

— Gretyl Kinsey

Related links: 



Christine Cuellar: Welcome to the Content Strategy Experts Podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. Hi, I’m Christine Cuellar, and in this episode we’re going to talk about how to balance the implementation of both your CMS, which is your content management system, and your CCMS, which is the component content management system. This is part one of a two-part podcast. I’m here with Gretyl Kinsey. Hi, Gretyl!

Gretyl Kinsey: Hi, Christine. How are you?

CC: I’m doing great. Thanks for being on the show. So, Gretyl, before we get started, I just want to kick off with a real basic question, and I know that we have a lot of content on this that we’ll link in the show notes. What’s the difference between a CMS and a CCMS?

GK: Sure. So a CMS or a content management system is generally a broader term, and that’s for a tool or a system that allows your organization to store and manage content. And this could be talking about a lot of different types of content storage in management and operations around that. A lot of the common ones that we see are things like storing print-based documents such as PDF files or updating and publishing your web pages. So this is really more of an umbrella term that you see for content management.

And then in a narrower scale, a CCMS or a component content management system is a specific type of CMS, and that’s used for creating, storing and distributing structured topic-based content. So, for example, we see this a lot with XML and more specifically DITA content. And the component portion of that name is talking about the fact that you have content in individual topics or chunks, and those are called components, and those are assembled into the deliverables that you send out to your customers.

CC: Gotcha. Okay. So why do a CMS and CCMS need to connect? What kind of integration are we talking about here that we need to be balancing?

GK: Sure. And I want to talk a little bit here about what exactly we mean by connect first, because there are two different angles to this that we see a lot. So one level of connection is when you have actual integration or connectivity between the systems where they hook in and talk to each other. And some systems are built actually with this in mind. So they’re designed to connect out of the box. So you might have a tool that has a web CMS and a CCMS under the same brand, and they’re designed to hook together and communicate. And then other times you could have CMSs and CCMSs that have the ability to connect with each other, but it’s not built that way out of the box. So it would be some kind of a custom connector that’s built like an API that allows them to have that integration.

And then the second level of connection that we talk about is where you have the ability to send content back and forth between two disconnected systems. So rather than that direct connection or integration, this requires a compatible content format and a process for getting that updated content from one system to the other. And this could be a one-way or a two-way connection, but it’s sort of more of a bridge rather than a direct integration where the systems are not actually connected, but they can still share content.

CC: Gotcha.

GK: And so when we’re talking about either of these levels of connectivity, either these types of connectivity, the ultimate goal is to prevent the CMS and the CCMS from becoming disconnected silos, because that is something we do see in a lot of organizations and it can have some real consequences for your content development. So one big one is inconsistent information coming out of each of those two systems. So if you’ve got all of your content in a CMS and then you’ve got a separate CCMS silo and they can’t connect or share content at all, you might have completely different processes for checking that content, making sure the messaging is the same, and if it’s inconsistent, then that looks bad to your customers at best, and then could get your organization into legal trouble at worst. So that’s one really important reason why we want to avoid those kinds of silos.

Another reason is that there can be difficulties with brand consistency and messaging. So this is not just the consistency of your content itself, but how it looks and feels to your customers. And, of course, this can be a really big headache if you ever need to go through a rebranding.

CC: Yeah, the marketer in me is just cringing right now, as you mention it.

GK: Oh, yes. And this is actually a reason that we’ve had some of the organizations who have come to Scriptorium for help is because they needed to go through a company rebranding and they had their content at a bunch of different silos and couldn’t figure out a quick or efficient way to make that rebranding happen. And then of course, that problem can and does get magnified if the rebranding is due to a merger or an acquisition because if you’ve got two or more companies coming together and they’ve all been working in silos, then suddenly how do you get everything rebranded under one name as quickly as possible and as painlessly as possible. If you didn’t have those silos to start with, that could happen a lot more effectively and with a lot less hassle and headache for everyone.

And then of course, another reason to avoid silos is that you waste a lot of time and resources creating and publishing the same content potentially in two different places. If you don’t have a way to share the content, then there may be times when a marketing group that’s working in a CMS needs the same information. So things like technical specifications, if you’re selling a product that people need to know that information about, but then also that same information would obviously be in your tech docs and if you have two disconnected silos like a CMS and a CCMS that can’t integrate or share content, then people would be writing that information twice. And that just wastes a lot of time.

CC: So when it comes to a timeline of the, I guess what we typically see when we’re implementing a CMS and a CCMS, do they get implemented at the same time? Does one of the systems typically come first? What does that standard timeline, I guess for lack of a better word, look like?

GK: Yeah, and I don’t know that there really is a standard per se. I can say that unfortunately they are almost never implemented at the same time.

CC: Oh, gotcha.

GK: If you do have that opportunity to do a complete overhaul and get a CMS and a CCMS at the same time, I would say definitely take advantage because that is pretty rare. What we see more often is having one system that’s already been chosen and established, and then you have to choose another one that will be compatible with it. So whichever one your organization has put in place first, that sort of gives you your parameters and your requirements for the other. From our perspective, we do see more organizations that already have an existing web CMS, because that is a little bit broader. It might manage some more of the parts of the content lifecycle than something like a more structured environment like a CCMS would. And so then what will happen is they’ll realize they have a need for structure and then realize they need a CCMS to manage that content and then need to choose a CCMS that will align and be compatible with the existing web CMS.

CC: Okay. So what are the pros and cons of each of those: implementing together versus separately, that kind of thing?

GK: Yeah, sure. And one thing I also want to point out about that is that there’s a big “it depends” kind of factor, which I know is the thing you hear from every consultant that it depends. But I know that one thing we always look at before we even get into the pros and cons are things like limitations that come into play. And so, one of the big ones we see at almost every organization is the budget. So how much budget do you have? Who controls that money? Are there timeframes in which you have to use it? All of that can really make a lot of your decisions for you about implementing, whether it is one system or more than one system at the same time.

And then of course, you have deadlines and timeframes that are set by your organization around their production schedule and other goals. And so that can also be a really big limitation for implementing a new system. And then of course, it’s important to think about what business needs are actually driving the decision to implement a new system or maybe more than one new system in the first place. So all of those are the big considerations that we think about first.

And then when we think about the pros and cons, like I said, if you are implementing a CMS and a CCMS at the same time, the big advantage is that’s rare. You want to take advantage of that opportunity, because you can evaluate both systems at the same time instead of already being locked into one tool and then having to make another tool fit with that. So that’s obviously the major advantage that you have is that you have more of that freedom to look at your options and maybe pick something that’s going to be a really good fit for you without sort of limitations or parameters.

But of course, that being said, sometimes those parameters can be good. So if you already have, let’s say the typical scenario, you already have a CMS in place, maybe if you didn’t have that in place, you would be looking at five or six CMSs and then five or six CCMSs as well. And you have a lot more tools to evaluate in the first place. You have a lot more areas of compatibility to assess. And so that timeframe is going to take longer to make that decision. And you can get bogged down by indecision-

CC: That’s true.

GK: By saying, maybe we have two or three options that would all be good fits for different reasons. But if you already have, let’s say your CMS in place and then you’re just looking for a CCMS that can play nicely with it, maybe you’re only narrowed down to two or three options. And it takes a lot less time to really find out what the right decision is. So there are pros and cons in that way.

CC: That’s true.

GK: Another thing to think about also is just risk. Because implementing any system is a huge undertaking. It takes a long time. You have to go all the way from the evaluation to making the selection, to getting everything stood up and ready to go. And then there’s always a little bit of experimentation and churn as you actually start getting content into that system and getting your publishing lifecycle going. And so if you’re doing that for more than one system at the same time, there is a lot more risk of

something possibly going wrong, not going according to plan. And then of course, the investment that you have to make into an implementation is quite large as well.

So there’s definitely, I think, less risk in only implementing one system as opposed to trying to do two at the same time, even if you do have the advantage of, we got to choose these together so we know they’re going to work well together. So yeah, there definitely are pros and cons for whichever way you end up doing it. A lot of times it won’t be your choice. It’s going to be limited by all the various circumstances I talked about at your organization, but things to think about just in case you’re ever in that situation.

CC: And so something that comes to mind is, I know that when you’re implementing systems, whether it’s the systems we’re talking about here, or just systems in general, a lot of times organizations can get stuck when both systems have competing priorities and that can cause a lot of problems in how things are implemented and in the timeline of how things are implemented, all this kind of stuff. So are there competing priorities for a CMS and a CCMS?

GK: Sure. And one big one that we see a lot is that when you’re talking about the people who are actually developing your content, your authors, your subject matter experts, contributors, a lot of them tend to see creative freedom in how they create the content versus consistency as competing priorities. The less structure you have for your content, the more creative freedom it gives you, but then it also introduces a lot more room for inconsistency and human error. And so there’s always that balance to strike. And if you have groups at your organization where, let’s say, one group needs that creative freedom, so maybe your marketing team, they need the ability to have full freedom of their design and what information they’re putting where, but then you’ve got another group that they need the rigidity that comes with topic-based authoring and with having information delivered in a specific way for legal and regulatory requirements, then obviously something like structured authoring is going to benefit them.

I think it’s important that when you have both of those types of content produced by your organization and you have two groups that are sort of in charge of that, and maybe they’re in two different systems, that it’s really important to get those groups working together so that they can understand that those priorities don’t need to be competing, they just need to be balanced. That’s always the challenge when it comes to those priorities is, yes, they seem like they are competing, but really it’s more about striking that balance and making sure that each group understands the importance of the other group’s needs and how they can still work together and share information that needs to be shared, but also still have the ability to work in the way that they need to work to get the content out the door.

There are tools that can help you strike that balance. So, for example, a web CMS can give your marketing team the creative freedom that they need, but also so can some types of CCMSs. So there are ones that use topic-based authoring and those smaller components we talked about, but not an XML structure like DITA. So that might be an option to look into. And then of course, an XML or a DITA-based CCMS can give other groups, like your technical team or your training team, that structure and the components that they need to create that more heavily regulated technical or legal content. So it’s really worth having these different groups explore the options that are out there and help turn what seems like competing priorities into those more balanced or coordinating priorities.

CC: Gotcha.

GK: I think it’s also worth noting that just because your content is structured, so topic-based XML, DITA XML, that doesn’t mean that it cannot be made to look beautiful when it’s published. There are a lot of things that we can do with PDF output, HTML output, all other kinds of output formats to make things look really nice. So you don’t always have to have that unstructured nature to give you the creative freedom for a really nice look and feel. And then also, it can be delivered in creative ways. So because it is componentized, because it’s in little topic-based chunks, that actually lends itself really well to having flexible delivery, to delivering personalized content to different segments of your customer base and to having a lot of different formats that they can receive it.

So yeah, I think we see a lot these days where people can log into a portal and get stuff served up to them according to parameters they’ve put in about what they’ve bought. We can see a structured componentized content used to serve chatbots, all kinds of other things. So there is a certain degree of creative freedom in structured content as well that I think a lot of people don’t always realize from the outset just because there is that structure.

CC: And I’m going to jump in on that because I think when it comes to marketing content, I feel like your freedom to be more creative when a lot of the mundane technical tasks are taken off of your workload, and that is something that structured content allows you to do. So that’s something, me standing on my little soapbox, I get excited about when we’re looking at structuring content and streamlining content operations is that, yes, you may feel like your creative freedom is a little bit restricted, or maybe it’s a little bit more complicated for you to learn how to get the kind of creativity and design that you want from your published content, but the benefits of having your workload reduced because you’re not focusing on things that you don’t need to be focusing on anymore is really massive. And in the long run, I think that frees you up a lot. I get excited about stuff like that.

GK: Oh, yeah. And I absolutely agree. I do think from the side of people working in structured content, they realize how much more freedom they have when they’re not doing a lot of manual design tasks anymore, when they are free to just write the content they want to write and realize that-

CC: Exactly.

GK: … it can be delivered and mixed and matched and put out to their customers in a lot of different ways. And so it really does, I think, take a little bit more practice in doing things to realize how much more freedom that you can get when you work in structure.

CC: Exactly. Yeah. All right. So I think that’s a good place to wrap up our conversation, but we will be continuing this discussion in the next podcast episode. So thank you so much, Gretyl. I really appreciate you talking about this today.

GK: Absolutely. Thank you.

CC: And thank you for listening to the Content Strategy Experts Podcast, brought to you by Scriptorium. For more information, visit or check the show notes for relevant links.