Make the move successful: Replatforming content ops

Alan Pringle: Hey everybody, I am Alan Pringle, and today I want to talk with Bill Swallow about content operations and replatforming. Hey Bill, how are you? Bill Swallow: Good, how are you doing? AP: Good.

So I guess we should start this by saying the reason why we want to talk about replatforming is really we have done a few replatforming projects. We've had some prospects reach out who are interested in doing it. So I guess we need to explain what it is and some of the things you have to think about when you're going through the process. So if you would not mind, would you define what we mean by replatforming content operations?

BS: Sure. So generally when I talk about re-platforming, it's in the context of a company having one system in place and maybe it's time has come and they need to move into a new one. So it's the entire process of determining what type of system you're going to need, what your requirements are for that and being able to lift everything up from the old system that you want to carry forward and put it in the new system, configuring it and what have you to get it to work going forward.

AP: So we're not talking about using a whole new technology or a whole new platform. It's shifting to a similar platform for some of the reasons that you just mentioned. And I think that's another thing. There are several reasons why a company might want to do this.

And I know our clients have had various reasons for doing this. Let's focus on those for a little bit. One of them, I know you kind of already touched on this. Sometimes you just outgrow a system.

It just… that's how it is. So let's start with that kind of, it's not sustainable anymore because you're bigger, too big now for what that system can do. BS: Sure, either you've outgrown it or it's approaching end of life or it's just not meeting the needs that you had five or ten years ago when you bought the system. So there are a lot of different factors there, but basically it comes down to what are your requirements and is it meeting your requirements?

AP: Right. BS: Are you able to get the things done that you need to do given the fact that, you know, the world is quite different now than it was five or 10 years ago. AP: Exactly, and there's another angle here too that I think we need to briefly mention is that sometimes you're gonna have two sets of requirements because two companies can merge or there can be an acquisition and then all of a sudden you've got two content operations platforms that are pretty much doing the same exact thing and I guarantee you the IT department is not gonna have that.

BS: Absolutely. AP: So there could be a situation where you've got two and one of those is going to go away. And in some cases, and we should talk about this too, it's not necessarily about picking one. It's not uncommon to go to a whole other one.

So there is quote, no loser. That's also an option. BS: That's very common because usually in the case of a merger, you have two established groups with two established systems that may be starting to age out on both sides. And it doesn't make sense to spend the time and the effort to move one group into the other system when that system is probably going to be replaced in a few years anyway.

AP: Yep. So basically, the circumstances of the merger have provided a perfect opportunity to do something that's painful. Replatforming is not magical. There's still going to be technical hiccups and everything else.

But at least it's not as painful because you're both moving out of systems that maybe aren't optimal into something that will basically treat your content creators and all the people managing content much better because it's going to support their needs better. BS: Or at least everyone goes through the same pain together of learning a new system. It's team building. AP: And so you bond through shared pain experiences.

Exactly. All right. Yeah. huh.

We'll go with that. We will go with that. There's some other aspects here too that are kind of related to that. And that are the idea that things, because things are getting maybe rickety, that things are getting too expensive to maintain.

You keep making these little tweaks and changes in things that become less and less repeatable. And that adds up. That's time and money that you have invested. BS: It certainly does.

Aside from the hard costs of licensing and just the general time to use the system, produce things, you do have, after you've used the system for so long, you've got your workarounds built in and they may not be a best practice and the workaround may solve the problem on its face, but you're doing a lot of things that you really shouldn't be doing with that, you know, with that workaround in place. You really should be doing something that's a little bit more streamlined. And, you know, as you're bringing new people in and new groups in, whether it's a merger or whether it's just another department that realizes that, Hey, you know, they have this, you know, shiny system over here.

Why don't we start using it too? If you have workarounds in place, it takes a lot longer to get people up and running in a new system because not only do they have to learn the system, but they have to learn how you've worked around it. AP: Right, and that's where you start talking about technical debt because all of those workarounds that you're describing, that equates to technical debt. And one day, you're gonna get your backside handed to you because you have all of this technical debt.

And replatforming is the perfect time to press that reset button and say, we're gonna get rid of those things. We're gonna have a system that addresses those problems in an official, correct way, and none of these weird workarounds. BS: Mm-hmm. AP: And by the way, those workarounds, what if the person who did them leaves and hasn't been documented well?

BS: Yeah, that's a big problem. My guess is that if you've been using one particular system for, you know, 10 years or even more, you probably have a lot of content just sitting there that hasn't been touched in years, hasn't been needed in years, but it's still sitting in the system. And it's still coming up in search results as people looking to, you know, find topics that they need to edit for a new release. And it's just getting in the way.

It's a good time to, you know, cut clean and, you know, ditch all of that old content that you no longer, that you know, you no longer need and focus on, you know, what you need to produce going forward. AP: Yeah, I think maybe sometime on the show Hoarders, they can do episodes on content people and their technical debt, and basically just hoarding all of this content in various digital forms all over that nobody's actually looked at. I'm sure we would all laugh and be horrified at the same time by such a shit.

BS: It wouldn't make for exciting TV, though. AP: Yeah. So let's talk about the overall process for how this kind of works. We've talked about what it is, a lot of the reasons for it.

So let's talk about how to do it. And it's not a one-size-fits-all thing. We can tell you about our experiences that we've had. But I know one of the first things you got to do, for example, is choose your new system where you're going to be moving into.

BS: Right. And out of the gate, the knee-jerk reaction is to go with something new and shiny, but you really need to sit back and figure out what it is you need that system to be able to do and how you need that system to be able to do it. you know, we've had a lot of clients who've come to us after setting up a system, maybe two or three years prior, who just are like, this is just not working for us. And as we talk with them, we realized that, you know, they, essentially, you know, had a square peg and they bought a round hole to put it in.

And here they are three years later, still trying to force that peg into the hole. So you need to sit back and really think about your requirements and not the requirements that you have today, but the requirements that you have today and anticipate having at least five years down the road. You have to leave yourself open because otherwise your opportunity for growth in that system is limited by your choice, and I hate and we always say, know choose tools last. Same thing goes for the systems.

The reason why we're talking about it up front is that you do have an existing system. You do at least need to identify some candidate systems that you're going to be moving into and have clear requirements for those systems and why you want to look at them further before deciding on the one you're going to implement. AP: And those requirements can help you identify the differentiators, the things that make one system a better fit for your needs. And the more fine-tuned and discrete your requirements are, the easier time you're going to have finding that match for the new platform that you need to address all of those requirements.

BS: Mm-hmm. AP: Another part of this is moving the content from the old system to the new. So let's talk about content migration, because that, a lot of times, I think people underestimate what that can take, even when you're talking about basically two very similar technology stacks. BS: That's the easy part.

Content is content, Alan. It's just all just words. It's fine. You can move it.

No problem. Yeah, I think this is the most overlooked piece of all of it. Even if you're moving from one system that uses the same format for the content under the hood to another system, you're still going to have to make changes. AP: We can take this outside later.

Yeah. Yeah. Yeah. BS: The old system maybe had a couple bells or whistles that handled things a very specific way.

And the new system has a couple of other ones and they don't match. So you're going to have to find a way of mapping from, you know, content type A1 to content type A2. Even though they're both content type A, you still have these little differences that you need to map out. AP: Right, because what may have been best practice in your existing system may have required a custom thing that that system does that system B does not do.

So you've got to find the equivalent of what that custom thing is. We've run up against that quite a few times and it's not that uncommon, but you're right. It's rarely a one-to-one situation, unfortunately, even if the underlying foundation or structured standard you're using data in particular is the same thing. So yeah.

BS: Mm-hmm. Yeah, DITA in particular is interesting because you would think that all systems would play with a documentation standard in the same way because it is a standard. It's not the case. There are different efficiencies that the systems bring that come with some modification.

And it's not to the standard itself, but how it interacts with it. And it may do things like replace linking with, you know, linking via file name with, you know, linking with a UUID and, you know, a unique identifier. And that unique identifier is going to make perfect sense in that system that you have now, but it's going to make absolutely no sense once you move it to another system. So you have to find some way of converting it over.

AP: Exactly. BS: That being said, that's the best case scenario that you have two systems that use the same underlying content technology, and you just need to map a few things differently. There are other cases where you have a completely different approach to content from system A to system B. One might use XHTML or might use something else, might use RTF, who knows?

And then you move to another system that uses XML or uses Markdown or what have you. But that is a bigger lift and shift where you suddenly have to remap and convert everything to a new format. AP: And that's really the distinction between moving to a whole new system and replatforming. What you just described there is really going to a whole new tool environment, a new process.

Whereas what we're talking about more is where you're basically using a tool in the same area or a competitor of the tool you've got now. BS: Mm-hmm. AP: And it's just moving things over and fixing those little custom things that aren't going to work in your new system. So yeah, there are all these levels here.

And I think one thing we really need to communicate here, even when you're re-platforming from one tool that's very similar to the new one you need, there is still work to be done there. It's rarely just a very clean cut, lift and shift. And a good example of that is the publishing pipelines because tools in this area have slightly different ways for publishing and getting your content out into the world. BS: They do.

And even if you're using the same, you know, the same publishing pipelines that you're able to somehow lift them up from one and drop them in another, because of the changes in how the system handles the source content, you're still going to make, need to make modifications to those publishing pipelines later because, you know, like my example with links, because they're going to work differently in another system. You need to tweak the output generators to handle those links appropriately.

AP: And another example of that is when your content system integrates with other systems, the way that, for example, your content system integrates with a workflow management system, it may be different with the other system, or your product lifecycle software, that can also have to be hooked up differently. Or who knows, maybe you're changing it all together. So you also, beyond just looking at the publishing pipelines, look at how other systems are integrated in with your content development system.

BS: Right. It's not a matter of just, you know, unplugging all the wires and plugging them back into the new box that you bought. I mean, it's very different in some cases, you know, one may have a built-in, API, another system, you know, it might have no handling, and you have to build an API to now, you know, talk to whatever your portal, your workflow management, your digital asset management system, what have you. It's usually never clean cut.

You can never just unplug those wires and plug them back in. And yes, there are no wires involved usually. AP: Yeah, well, and by extension of that, like you can't just, you know, unplug and replug, you also have to think about people and how they have used that system to create and manage the content. You've got to kind of help them understand the differences and basically help them remap and reprogram their brains to understand, okay, you did it this way in system A, you're going to have to do it.

This way in system B, it's a little bit different. So you still have the training and change management requirements. Again, it is not lift-and-shift, and that goes for people's brains. It's not gonna work like that.

It's just not. BS: Mm-hmm. No, no. And another thing that a lot of people tend to gloss over is the amount of testing that's required once you get the system stood up.

You have to make sure that all the content is valid in the new system, that it's running and behaving properly, that you're able to publish outputs, find where things might be dropping out as you publish content and fix those. So it's never going to be a very straightforward project. AP: Yes. I agree, and I think this is a good time to like offer up some closing tips on things to think about, and I know one of them is this is going to take longer than you think.

BS: Yeah, yeah. I've, I've warned people to budget at least six months, and that doesn't mean about six months. That means at least six months and expect it to take longer. Even if it's a, even if it's as close to a lift and shift as you can get, it's going to take time.

and some of the reasons for that are not only is the system going to be different and you have to stress test it and make sure that it's, it's going to work in a live, you know, working environment, but remember that you also have competing demands at work as well. So that you can't have your entire team just stop what they're doing for six months or even pull it into three months and say, we're going to stop everything, not do any production work at all. And we're going to focus on just standing up this new system.

You really can't do that. AP: That never happens because there is no such vacuum on this planet in the business world, right? BS: No, you can't stop. You cannot stop the production machine.

You need to keep going. Aside from all of your daily job requirements, you now have the additional requirement of setting up a system. trying to shortchange yourself with a short timeline is not going to... First of all, it's unrealistic.

Second of all, it's not going to gain you anything. If anything, you're going to implement things incorrectly, you're going to start out of the gate with workarounds in the new system and it just, ends poorly. AP: And sometimes you're going to have to keep that legacy system running. You're going to have parallel systems because it's a CYA is what that is.

Just in case something goes sideways with the new one, you still have your old process and can use it to deliver content that has got to hit some particular deadline, for example. BS: Right. You've got to keep things moving. You can't just stop work.

But, you know, all that being said, the number one thing you need to do when you're thinking about any type of a shift in technology like that is to take advantage of the changes that you're going to be making. You know, if there are, you know, if there is content that you don't think you're going to need going forward, move it to the side. You might be able to move it in later. You know, don't have to necessarily delete it, but don't bring it into the system unless you know you're going to need it.

It's a great time to do some spring cleaning on your existing content database. Move in the stuff that you know you absolutely are going to use, and then slowly start bringing in other stuff or not, if you end up not needing it. AP: And then do a hoarder intervention, because you may need it. And that kind of brings up one of the last points I want to talk about.

Having an outside perspective, yes, like us, come in and help you kind of think through this, that can also be helpful. And really, I think the last point I want to make is, on the edges of this discussion, is really, you always have to have an exit strategy, even when you're going into a new tool. It really will benefit you to do something that seems so counterintuitive and to think about, what are we going to do if this tool goes away while you're implementing the new tool?

Because the fact you're doing a replatforming already tells you that exiting is a reality, and sometimes you've got to do it for all the reasons we just outlined. BS: Mm-hmm. AP: So always be thinking about how are we gonna get out of here if we have to? That's something that a lot of people in the heat of trying to get something new stood up, they really don't think about.

BS: Mm-hmm. Yeah, software isn't forever. Systems come, systems go, they get improved. And your requirements are ever changing, you with the content that you need to manage.

So not thinking about your next jump is really to your detriment. AP: And on that most excellent note, I will thank you, Bill, and we will end this here. Thanks. BS: Thanks.