top of page

DCL Learning Series

Unlocking Seamless Documentation Evolution: Migrating from MadCap Flare to IXIA CCMS and Transforming MS Word into DITA

Marianne Calilhanna

Hello, and welcome to the DCL Learning Series. Today's webinar is titled "Unlocking Seamless Documentation Evolution: Migrating from MadCap Flare to IXIA CCMS and Transforming MS Word and More into DITA." My name is Marianne Calilhanna. I'm the VP of marketing here at Data Conversion Laboratory. And before we begin, I want to let everyone know this conversation is being recorded. It will be available in the on-demand section of our website at We plan to save some time at the end of our conversation to answer any questions you have, so feel free to submit questions as they come to mind. You can do that via the little questions box here in the GoToWebinar control panel.

So I'd like to quickly introduce my company, Data Conversion Laboratory, or DCL, as we are also known. We are the industry-leading XML conversion provider, but we do much more than conversion. We believe that well-structured content is fundamental to fostering innovation, and the services presented on this slide speak to DCL's core mission. Our core mission is transforming content and data into structured formats. So some of the solutions you see here, like semantic enrichment and entity extraction, migrations to content management systems, and tools for content analysis: everything we do is architected around supporting that mission. So the bottom line is if you have complex content structure or data challenges, we can help.

So we have a lot to cover today, and I am thrilled to introduce today's speakers. My colleague David Turner is with us today from just outside of Dallas, Texas. David is DCL's digital transformation consultant. He's an industry veteran in the areas around content management and content structure, and he's particularly adept at demonstrating the business benefits of digital transformation and helping organizations identify ROI to gauge investments in systems, structure, and semantics. Welcome, David.

We also have Dipo Ajose-Coker joining us from Paris. Paris, France, not Paris, Texas. And Dipo is the product marketing manager at MadCap Software. And I've been fortunate to know Dipo now for a number of years. First as a DCL client, and now as a DCL partner with MadCap. And every time I discuss or hear Dipo speak about content management or technical documentation, I really gain invaluable insights from his perspective on both sides of the fence, so to speak. So thank you so much for joining us, Dipo. And with that, I'll turn it over to you, David.

David Turner

All right, thanks so much. Yeah, I'm excited as well to get to have this conversation. I love working with Dipo, and we've done some of these conversations together before. Our title today talks about the concept of migrating from MadCap to IXIA, and I think a lot comes to mind when people talk about migrations.


Out in the natural world, migrations can be a really gentle and peaceful and beautiful thing, but often, they can also be very bold and disruptive kinds of things. So we want to talk a little bit through that, especially after this merger. How is this going to work? What are the implications of that? How do we make it be more gentle and peaceful and maybe less bold and disruptive? One distinction I do want to make in terms of defining terms at the beginning is this concept of migration versus conversion.

A lot of times, these terms are used synonymously in the industry, and a lot of times we use the word "migration" when we're really talking about conversion. The complexity is really more around conversion than it is migration. Technically, migration is the process of moving content as it is, if you will. So lifting and loading from one system to another, whereas conversion is about transforming that content into the different components that are optimized for a new system. Now, we tried to stick with the whole migration thing here in nature and all that kind of stuff, but I'm going to break apart for a second, sorry, Dipo, here. And I'm going to go into the whole Lego brick analogy because that's just my favorite, and it seems like it's –

Dipo Ajose-Coker

My favorite. 

David Turner

When it comes to migration, migration is having a pile of Lego bricks and moving it to a new storage system. Right? You're picking it up and you're moving it, whereas conversion is more like you've got Lego bricks that are already built into something, and you've got to break it down into those components and then go store it effectively. So it takes more thought, it takes more work, it takes more software to get those things in there. And a best case, you might be going from Lego brick to Lego brick, but sometimes we have customers that don't really have Lego brick, maybe they have some kind of brick, but it's like a Duplo brick. So it's not a one-to-one, so there's a bit of a transformation that goes from getting those into the structural format. Or some people don't have bricks at all. Right? It's a Lincoln Log. So we'll use the term migration today really to talk about this idea of moving the content. But a lot of what we're going to be talking about is really the conversion and really the whole transformation of the content, if you will. All right? Now what got this all started was that there were a couple of big pieces of news. People will probably recognize these headlines. These mergers shook the industry a little bit and led us to our topic today. So I want to just really start by maybe letting you talk a little bit about the vision here in terms of what MadCap is thinking by bringing into the fold IXIA and then also Xyleme.

Dipo Ajose-Coker

Okay, thank you very much, and thanks, Marianne, for that super introduction. Basically, MadCap software has always been a pioneer in creating help authoring solutions, and MadCap Flare has been out there for ages. We added Central onto it and the of tools that help to make sure that you're creating content intelligently, you're working smarter and not harder. And so, part of that vision was, for us, we listened to our customers. And customers would come to us and say "Well, we heard about DITA, can we use DITA in..."


And we're like "Okay, well, no, Flare will import DITA, but then it becomes its own XML. It's no longer following the DITA standard." And so, the vision was, okay, well let's answer some of these questions. Let's respond to what the users want. They want solutions that will fit to them rather than them having to fit to the solution. And so we started creating a new era in content management. That's our new slogan, it's a new era in content management because what we're trying to do is to bridge silos.

We want technical documentation professionals to be able to share content, both source content and output content, target content, with our partners in learning and development. These are two different strands. They've always been independent silos, but we want to be able to offer them tools that, one, will respond to what it is they want to build. You want to build a training course, well then pick up Xyleme, which we acquired this year. Oh, you really want that DITA solution? You want to go for structured content in DITA XML? Well, we acquired IXIA CCMS. And the vision, the future vision for us is that all these tools will be able to bridge those silos between the documentation department, excuse me, the documentation department and the learning and development departments. And other departments are coming along as well. The tools will be able to talk to each other, and thus, we're bridging those silos, and people in one department can use the source content, share that source content with another department. 

David Turner

Gotcha. I think you've already talked about this a little bit, but maybe you want to hit a little bit more on some of this vision of the silos.

Dipo Ajose-Coker

Yeah, so we've been talking about breaking down silos for as long as I've been a technical writer, and I've been a technical writer a long time. I only just changed to product marketing a couple of years ago. But what I realized in my last job was, I used to work for a large medical device company, and so we had our technical documentation. We had teams of technical documentation throughout the organization. But at one point, there was a request from the learning, the training department. Like "Oh, can you give us some of the PDFs that you've developed? Because we find our engineers that we're training, they're all picking up the PDF outputs that you're using, and they're using that to perform some of the procedures that we're having to repeat on our side."

So there's that silo, there's a natural silo. Different departments, different formats of training. A technical writer goes to technical writing school, they learn things like minimalism, data and so on. And then you've got learning and development specialists on one side, and they're not talking to each other. And if you do have to share information, you're having to share the output, share PDF. And so we want to bridge those silos between technical documentation and learning and development. So whether you're onboarding new team members, you want to deliver just-in-time documentation and so on. You can see all that on the wheel on there. We want to make it easier for those departments to start sharing that source content and producing brilliant output for their customers.

David Turner

Got that. So that makes sense. So I guess the next thing we probably should talk about then is the journey that you have in mind for customers to maybe move through and work with these different products. So why don't you tell us a little bit of a story of one of these journeys and what you're envisioning here?

Dipo Ajose-Coker

Yeah. Okay. So the MadCap journey, I find the best way to explain this, 


why and how should I choose, when am I ready for what tool, and so on, is to tell you a story. So I'm going to tell you the story of ACME Robotics. Their product, an analytics robot. A little company one owner, and they had one technical writer just to make sure that they had the documentation for that robot. And they produced a user manual and a service manual. Now, when they started off, as most companies do, you start off in Word or Google Docs. So one of these non-technical writing tools. They're great for linear documentation, but they're not great for creating technical documentation.

Now, as the company grew, they were selling more, and they got a few more products, and then they started having certain issues, certain pain points. So they wanted to be able to reuse content from product A, the analytics robot version A, to the analytics robot version B. They needed to have consistent terminology between both of them. There's no point calling the tail a tail in one and something else in the other one. And maintaining that documentation, making sure that they're not having to wait six weeks after the robot is ready for the documentation to eventually be ready. And so, they thought of, let's get a proper help authoring tool. And they went for our desktop solution, MadCap Flare. And that helped with their growth. And then as time goes along, successful company, they started acquiring other companies, and the team started growing. And so that grew up to six technical writers.

They were producing more manuals, three manuals, six service manuals, and now they have three products. So well, because they've got six technical writers, they're not all based in the same office. They were starting to have issues with "Okay, so who's updating what? Oh, can we quickly get this reviewed? Let's collaborate on this. Can I share this content with you?" And so while they added Central on to provide that collaborative experience, the review experience, being able to also host that content online so they didn't have to pay for a whole different hosting server for their website where they stored their technical documentation. They got real-time project tracking, real-time collaboration as I mentioned, but also add to that they had version control and workflow management, which meant that now whoever needed to sign it, they had a workflow. You've got a document, you finish writing it, you send it for review and approval, that goes through the workflow. Things are set up to start and stop automatically. The SMEs are able to access that documentation and make real-time comments in it with the technical writer there to easily and quickly correct that. And they were in different offices. And so, basically everything is on a central repository in the cloud. Each writer has Flare on their desktop and they've got Central to communicate with everyone.

Again, expansion. I mean, they were doing really great. So what happened? They expanded and bought more and they started getting contracts with hospitals because these robots were actually proving very useful in the operating room and serving, bringing the food up to the patients in the ward. And so, they were expanding, growing at an exponential rate, and the team grew to ten technical writers. They were now creating four user manuals, ten service manuals. They've got four products now, and one of them is regulated, the one that they were selling to hospitals. But also, because the robots havegrown and the company has grown, expanded, they also have instructional designers who are training. They're now 250-odd employees serving their 2,500 customers. And so, the next challenges that they had was being able to look forward in time and scale that documentation.


They know that, hey, the way things are going, if we keep growing at this rate, we are going to end up with ten products at the end of three years. We are going to have issues trying to make sure that we're scaling at the speed that we want to.

Now, you can scale with Central; however, they had other considerations that they wanted to take to taking into consideration as well. And part of those was like traceability reporting, quality management system tool integration, so being connected to databases, requirements, databases and so on. And obviously, that's scalability. And so they needed to move into an enterprise class content management system. Now, enterprise class content management, there's a few of them out there. IXIA CCMS is a DITA-based XML enterprise scale CCMS. And so they said "Well, hey, technical writing team, we found this great tool for you. It's got a web interface. You could do everything that you can do, you can even do a little bit more." And it's based on the DITA standard, which is well known as one of the superior standards for writing technical documentation. But at the same time, we don't want to have to train the instructional designers in DITA. You guys, you've done your masters in technical writing, they've done their masters in instructional design.

Why do we need to train them up again? Let's get them a tool that is suited for them. So they got Xyleme for that tool. And so, within the same company, you've got two different CMSs. One is a component CCMS and the other is an LCMS, a learning concept management system. And these were able to serve their needs. And like I said, the vision for the future is that these tools will start talking to each other. We've got some big, big surprises coming up this year, but these tools will start talking to each other, and they'll be able to exchange a lot of information between themselves. XML is a standard. It's open to that. It's made for that sort of exchange. So I think that story gives you an idea, lets you know when to choose what.

David Turner

Yeah, and I mean, I can see the vision from this. It's a nice linear story. I start out with – I got a couple of writers, I can use Flare. Maybe I grow to a couple of sites, so I want to have some version control and things, so I moved to Central. And then maybe I've got multi-site, I've got a lot more writers, and I need to get onto a standard, and maybe different needs. So now I need to move to IXIA. Oh, now I want to bring on my training department. So let's bring on Xyleme, so I can get all that learning content in there. I'm guessing though, companies are always going to be in different places. So is it possible that someone could come on and just skip the Flare part and just move straight to IXIA? Or is it possible you've got somebody that's already on IXIA and they just want to add on Xyleme now?

Dipo Ajose-Coker

Oh yeah. I mean, you can come in at any stage you want. Well, apart from Word, we don't do Word, but you can come in at any stage you want. If you are ready to go directly from Word to IXIA CCMS, well, design your content strategy, talk to the experts, speak to consultants. I mean DCL, that's one of the core things that you do. You help with that content strategy, you help with analyzing that content and then preparing it for that conversion from Word XML to DITA XML, if they're moving to IXIA CCMS, for example.

David Turner

Absolutely. So I would say as you're moving, depending on which tool you move to or how you move through this journey, that's going to help determine your migration path.


Because if you've got Microsoft Word content that you need to get to Flare, that's going to have different considerations than if you've got Word content that you're trying to get to Xyleme. Or similarly, if you've got Flare content that's going to move to Xyleme, for example, that might look a little bit different as well. And I think that leads us really to the next point we wanted to make is, as you're looking at this, whatever you're doing, you do need to remember that migration paths are very seldom the exact same. When you look at the way that people migrate, it's different than the way that birds migrate and different than the way dolphins migrate. So different organizations are going to have different needs, et cetera. And I think there's several different factors. Yeah, it's going to make a difference what your organization is, it's going to make a difference in terms of what content types you have, what are the needs there?

And so, as we just talked, if you've got a different destination, I guess if I'm migrating from my house to the grocery store, my migration path might be different than my migration path to my in-laws' house. So again, it's like if somebody's using Flare for the first time, their migration might have a different set of requirements than someone going directly to IXIA. Or maybe you have IXIA already and now you're wanting to bring on your instructional designers, totally different path. I think another key thing, and I think you're going to talk about this more a little later, is the whole idea of: what expertise do you have? Put this in the migration context. I might know lots of shortcuts to get from point A to point B, whereas, if I use Apple Maps or Google Maps or one of those, it might take me a very standard way to get someplace.

So somebody might have expertise, be able to get there quicker, but other people might need to follow a different path. I think the amount of content that you have is going to be a factor in here. And really, like you said, the number of writers. Another thing, you can, a lot of times, be really nimble if you have a small amount of content. There's a lot – you can do it yourself, but when you start to get bigger and bigger and bigger and you need to scale that thing, it really changes things.

Dipo Ajose-Coker


David Turner

Yeah, and I think another big thing, it is just really figuring out: where are you right now? If you're going to try to pick the right migration path and the conversion that goes along with it, you really need to stop and just take stock a little bit of your content maturity. So I took this from Scriptorium. Our friends over there, they have an article on this, which, we have a link here. Leigh Anne, if it's possible to throw that link into the chat or whatever, that probably would be helpful. This work is actually based on something that, oh, what's her name? Bailie.

Dipo Ajose-Coker



David Turner

...Rahel Bailie did back in, 10 or 15 years ago. But any case, so the idea here is that different organizations are in different places with their content. If you're in a silo, well that means your content's being developed in all these different places, you don't have any synergies. Whereas, if you move to managed or strategic, you can read these definitions all here. In terms of choosing your migration path, if your organization is in a place where you're siloed, your path might start, not by choosing a tool, but just by trying to establish some standards for terminology.


Instead of hiring DCL to do a bunch of conversion work for you if you're in the siloed part, your better first step might be hire a consultant. But as you get further up the chain, maybe if you've unified content delivery, but you're authoring and your delivery processes, those are a mess, that might then make sense to look at a CCMS. But I think there's lots and lots of different factors. While I consult with people around this and ask people a lot of questions, you've been in the trenches. You work for a product company now, but you were a tech writer. You've done at least one of these initiatives, if not more. There's really, I guess, a lot of factors in choosing that pathway. So I'll go ahead and click to the next slide. I'll be quiet and let you just talk a little bit more about what's your experience and what are some of the key things that you've thought of in choosing a pathway?

Dipo Ajose-Coker

Yeah, so like I said, I used to work for a quite a large medical device organization, and as such, you can imagine the amount of content that we had was massive. I can't even remember how many different service manuals, and there's different modalities that were involved as well. So different departments building different bits of equipment. And so, that was quite a huge volume that we had to take care of. And so, with that sort of approach, there's different pathways that you can take towards migration. You can either go a direct migration, I will just take everything, convert it, and then move over to the new system and start publishing from there.

That might not always be the best bet, especially if you have complex content and a high volume because you're just not going to be able to properly test that everything went over correctly and displayed as you want. There's a theoretical display of what you want, and then when you click that "publish" button, and then things don't look exactly right, you're going to want to maybe change one or two things. You don't want to have to convert everything and then have to go back and do that. We also have to consider the organizational capacity. How many writers –

David Turner

Before you move on, can I ask you a little bit about that? So what I'm hearing and what I would say in all this is that I think your tools, you guys have a lot of built-in tools. Roght? Most times, you'll have tools to say, hey, you can automatically import this Word document and we can convert it to XML. Now, you might have to do a little bit of prep or you might have to do a little bit of cleanup, but if you've got five Word documents, then that's your path, right? Let's just do that. If you've got 5,000 documents, even if you get a migration partner that says, hey, we'll load all those Word documents for you, if somebody still has to go through and one by one, prep them, and/or clean them up and convert them one by one, you need a different path. And similarly with complexity, if you've got things that are very, very simple formats with very little tables and very little in the way of cross referencing, you might be able to do some of that yourself, but when it starts to get into the weeds, you might want to go a different path. And that's what you're saying, I'm thinking?

Dipo Ajose-Coker

Yeah, an example of complexity is having the one product, one main product, but you've got to tweak it for the different markets. And so, one of the issues that we had was for the Japanese market; there was a new product that we developed, but the clinical trials hadn't been done over there. Now, the assumption was we've got clinical trials,


we can sell this worldwide, let's go for it, boom, boom, boom, heads down, and let's go for it. However, just before it came to time to sell the product on that market, we got like a  "No, no, no, you did not do your clinical trials on our population, and our population has proven different statistics from the European clinical trials that you did." And so, we had to then find a way to exclude some of that information, and the right information.

Now, in one page, you might have a sentence over here, a paragraph over here, and so that's referring to that thing. You've got to find a way to remove those. And doubling a Word document and then removing those paragraphs, that might work if you've got five documents, like you said, but when you've got a thousand of them, it's just not conceivable. Even a find and replace will end up making mistakes inside of your documentation. And so yes, a hybrid or gradual approach is most appropriate when you've got complex and voluminous content. If I look at organizational capacity, what's your team's bandwidth? Do you have someone? I was pretty much seconded over to the migration projects, and so most of my time was spent dealing with migration issues, planning, speaking with consultants, speaking with DCL, going back and forth with trials, matrixes and all that sort of stuff.

And then also communicating to the team and to the other stakeholders within the organization as to what was going on, what the expectations were, and what the reality was at that time, at that point in time, any delays and all that. And all of that sort of stuff, you've got to consider that in making that decision. Do you have the bandwidth to dedicate all your tech writing team to creating that conversion? And all of them are focused on that, and the product can just keep going on. You don't need to release. If you're releasing every month, you're definitely not going to have the bandwidth. However, if you've got a longer cycle, then there's something that you could possibly consider.

David Turner

Yeah. And I think that could also be a hybrid approach. I mean, we're doing some things with Xyleme right now where there are scripts that are being written to do some things, but because of a deadline and some organizational capacity –

Dipo Ajose-Coker

That's it. 

David Turner

We're supplementing that and we're coming in and saying, okay, so they did steps one through six, now we're going to take steps seven through ten and knock that out so they can get this done. And meanwhile, they can go focus on another part. 

Dipo Ajose-Coker

That's it. Business continuity. I said that a little bit in that, are you delivering monthly or do you have a longer delivery cycle? Is the conversion going to slow down work somewhere and you're no longer able to be as reactive as you are, be as agile as you were with delivering new documentation or new training materials as and when. So your business continuity needs will determine also, okay, well, we can not deliver for a year, let's go for a direct approach. Or we need to keep delivering, so it's a hybrid. Let's do one manual, and we'll keep with the old system for the other ones. And once we've fine-tuned and really done that one well, then we take on the next manual. And so you're working with both systems at the same time. The gradual approach would be that, well, you're not really updating the other stuff. So while you start, test out the waters if you want, start, create,


convert one document, update it, and so on, and the next document. And you're doing this a little bit at a time and not the whole thing all in one. And then well, your strategic goals well, is speed to market important to you? Are compliance or requirements important to you? If compliance is important to you, you have got to think of a way to explain any changes in your documentation.

Now, one of the things we could do and what we did during that migration was when you've converted, you can count word for word that each single word was accounted for in the converted content. However, when you publish, it's not going to look like that. We went from FrameMaker. It's not going to look like the FrameMaker content. You've created a whole new style sheet to make that thing look good. And in doing that, you might be breaking some compliance rules. So, things like page breaks on certain elements, keeping a notice, a safety notification with the step. If you've not planned for that, and then that in your Word document, they were always on the same page, everything looked brilliant, but when you moved it over into XML and you created that PDF from it, then that warning message was going onto the next page. Now, that can create a dangerous situation because you always want to see a warning message before performing the steps. So that can create compliance issues when it comes to validating the converted manuals. Speed to market, again, it's a question of: is continuing to deliver as soon as you finish building the product, is that important to you or is it something that you can skip for a little while? Put those into your considerations in order to eventually choose your pathway.

So that should lead it on to: what is important to you? I've spoken to most of these things in here. You want to future-proof your content. Is that what's important to you? Because we all now, with the advent of chat GPT and all that, we know that structured content is king. Basically, structured content allows you to add metadata to that content. It's in XML, so you can always add attributes and things like that. And you're adding metadata to your content, which helps in training large language models because it's machine-readable XML and your instructions and the context are also machine-readable, which allows that LLM to be more effective in its training. Do you want to reuse your content? I spoke about our vision. Do you want your learning and development departments to eventually be able to pass content over to the tech docs or do you want them to be able to pass over? Do you want to be able to furnish another department, maybe your legal department with data sheets and things like that?

All of that you want to, that's future proofing your content and choosing a right decision to migrate to structured content means you're preparing for all of these. Is regulatory compliance important to you? So do you want to simplify your audits. And one of the nightmares, and we would get a warning months in advance "Okay, well this date the auditors are coming and everyone, that's it." There are no holidays, that sort of stuff. But I'll be like, "Okay, well we could take holidays." But the idea was everyone had to prepare.


Now, if you've got a system that at the click of a button, it'll prepare that audit report for you, that is totally 100% trustable. Hey, that is something that is really important to you, you want to spend less time preparing for and then fixing defects that they found to do in an audit. Do you want to enforce the structure or do you want your system to be able to speak with other systems?

I mentioned like a requirement database. You can link those to the topics. And so, if one requirement changes, you know all the topics that you've got to go and update. And that way you've got less work doing an impact analysis on that content. Reusable content, optimizing go-to-market, so full traceability and audit tracking. If that's important to you, then you want to start go looking at structured content in one form or the other, DITA or InDesign structured content. Efficiency and consistency. That's always important to everyone, I think. I don't know of any business that does not want to be more efficient, but these tools are there to help you do that. And then last but not least, workflows and processes and templates. Do you have a standard set that you want your service manual to always be delivered in this format and always be presented that way? And we've got studies. I mean, everyone knows if you present different information but in the same format, in the same layout all the time, it's easier for someone who's used to reading that documentation to find what they want. Which parts to skip immediately. Your eyes will float to the important areas.

And so that's your templates that you want to create. Workflows for reviews and approvals to make sure that you've not left out that one important person. That then means that the whole verification is no longer valid. Or being able to just verify that you've covered all the points in your requirements. And then one of the greatest things on the IXIA CCMS side is its ability to have dynamic release management. That's what we call it. It's simply stated branch and merge. You've got your main trunk, and then you are allowed to start developing something that might or might not be integrated in the product at a particular point in time. So you've got this great new idea, something that you're adding. You'd be able to create a branch for that feature, develop it, and still keep publishing from the trunk, and then eventually when it's ready and approved, you merge that back in. And so to make it easy –

David Turner

I went ahead and just transitioned to this slide, because it sounded like you were trying to hit on some of the unique things. I thought it'd be good to just hit from a high level your products and what's where.

Dipo Ajose-Coker

Perfect timing, because basically, we've translated what those pain points are, what is important to you into the features, into some of these features that you see on here. So, if you take a look at this, and this will be available on our website, you'll be able to go over and download it. We'll provide it as a downloadable resource for you as well at the end of this webinar. But if collaborative authoring and review is important to you, if you take a look at that line, all our products do that. However, if you then want to take a look at something that may be primarily built for large teams for large learning teams, then looking at that line, you see that, well, Xyleme is the best choice for that. That's an enterprise class learning content management system. And if you're looking just for large technical writing teams, then the dots go on. You can use Flare with Central or you can choose IXIA, which is fully 100% compatible.


There's no point going through the whole table. I think reading out a table, it's probably been screenshotted a few hundred times.

David Turner

Gives you a good idea. All right, so let's say somebody decides that they want to move forward. What else do you got to think about? That brings us to the discussion of barriers. What could possibly go wrong? As I look at this, I think about a few things. I'll bring one up, and then I'll ask your thoughts and your advice. The first thing I think of in terms of when somebody decided they want to do this, how do they get the budget for it? How do they build the business case? Any advice you have on this?

Dipo Ajose-Coker

Okay, yes, building the business case. Now, when you're talking about that, you're talking about getting someone to open the purse strings and dip in there. And so, you've got to think about what is important to that person. What is important to you as a technical writer is different from what is important to the CEO. The CEO wants to be able to release a product every month. Well, then you go to him and say "Well, if we've got the system, we'll be able to reuse content. That means we're leveraging content that we've already created that reduces 30% of my workload. Our translations will save money on that, but also, we'll be able to reuse translations across so there's even more savings over there." And so basically, what you want to do is look at what is important for the person that you're speaking with.

If you're speaking with the regulatory department and you're trying to get their buy-in, well, what you want to be talking about is the full traceability that you would have with a CCMS or an LCMS that is able to provide you with a report of what's changed, when, where, and who signed off on it as well. With Xyleme, we've got brilliant analytics in there that will then allow you to report on everything from the source content, but also on the outputs as well. How is this content being used? If you mentioned that to your manager in that "Hey, I can tell you which topics are being consulted, which topics are being searched for but not found, and that way we're better able to answer what the client wants," then hey, you've got his buy-in. And by doing that, you are reducing costs of the service center or of the online center. So again, you want to pick these things, things that are important to you, but translate it over into what is important for the person you're speaking with.


David Turner

I know another thing we often talk about, and we've done this actually with both people trying to build a business case for an IXIA and for a Xyleme purchase, we have a tool at DCL called Harmonizer that basically allows you to look at large content sets and identify how much reuse there is. So a lot of times when people go to their management, they go "Oh, one of the great benefits, we're going to be able to reuse content." And their management says "Well, how reusable is our content?" And they go "Well, um..." They try to just guess. Harmonizer can give them real numbers. You can run a report and say "Look, 45% of our content is reusable," but this is not about Harmonizer today, this is about barriers. So another, I guess, barrier is content formats. We've talked about that a little bit, and we'll just go through that a little faster.

I think you're going to talk about this more in a second, but getting content from Word to XML, in some ways it can be easy, in some ways it can be really challenging. Other formats, going InDesign or FrameMaker to an XML format, there could be some real challenges. And that's where DCL can really help and consultants. But in the interest of time, I'm going to go to – oops, I didn't mean to do that.


In the interest of time, I'm going to just hit on one other barrier, and that is what I think is the biggest one. And we could do an entire webinar on this, but we'll one or two minutes, and that's change management. People don't like to change. So what advice do you have as say, prepare for this?

Dipo Ajose-Coker

As one of my favorite content strategists says, "Tools are easy, people are hard." People don't like to change; however, usually people put up a resistance to change if they feel it's being forced on them. So you've got to find a way to encourage, to cajole, to show what that person is getting out of it. So, you've got training barriers. Somebody who's nearing retirement feels "I don't want to have to learn all of this again." Well then you maybe find ways or including that training in what they're doing. That's one of the hardest things to do, is get people to learn new things, especially if they don't want to.

What are you going to gain out of this? Well, that repetitive work that you were doing, copy and pasting between sixteen Word documents? Well, that's going to go out the window now. Well, and then you're speaking to maybe the documentation manager, and you're going, okay, well you kept going on that. The new person kept formatting their tables with gray backgrounds and left aligned and so on. Well, by implementing something that has publication, central publication, then while you are removing that little issue that you're having with that person. So it's a question of finding, again, it's pain points and finding ways to alleviate that. Train your staff, keep them informed as to what is happening. Keep them informed as to why you're making the change. Some of the reasons might coincide with what they've been thinking. And you've got to find a champion also within your organization, within your teams.

David Turner

And I think from a content perspective, there are things too. So you've got, if people are getting a brand new system and they're having to go through all this, their change and training and worried about getting this into their workflow, if they then, now you have to add on top of that, oh, by the way, you've got to prep content and you got to clean up content after you've converted it. A lot of times, that's what puts them over the edge. Or if they go to use this new reuse feature and there's no content for them to reuse because they haven't migrated it yet, and they're having to create everything over from scratch. A good conversion strategy to get content and get content correct and have it working, so when people start using the system, I think that could be critical. But anyway, we're getting close to the end of our time and I want to make sure we talk about, I know MadCap has made some commitments in this from a product perspective to help us with these barriers. And I want you to get to hit on that just at least a little bit.

Dipo Ajose-Coker

Yeah, I mean, one of the things that we find that is really on some uncertain vendors is locking down content in order to try and retain the client. Your content, when it's transformed into Flare XML, Xyleme XML, will not be locked down. You are allowed to import and export your content at your own will. Do whatever it is that you want to do with it, that is our solid promise. Your content will not be locked down. And I know even of DITA CCMS providers, DITA is a standard, and as such, it's supposed to be an open standard. It's free for all. However, once it goes into this system,


and I found this out the hard way, there's loads of proprietary code that's injected into it, which then means the day that you say, okay, well I'm no longer happy with this particular vendor, I want to move to another vendor, then you find you're going to have to pay so much to just clean out all the extra. It's a difference between pure XML and a Word XML. All the office, MS Office code and all of that's imprinted in it is there to keep you within the Microsoft family. Tools are going to be made available, and there some of them that are already available. So to easily convert a Word document into pretty much any format, one of which is DITA, export tools, analysis tools are going to be there. And while you can do some of these yourself, import the large document and all of that, when it comes to doing your volume content, I would still recommend talking to a consultant and getting a consultant company involved in that particular thing, particular import and export and analysis of reuse, like David just mentioned with Harmonizer.

And also, we've got a dedicated solutions team. So we've partnered with DCL for that conversion aspect. We've partnered with many other organizations for content strategy, but also for creating the different outputs that you've got. We've got consultants who are ready there to train your company, hold your hand all along the way. And in-house, MadCap has onboarding specialists. Each solution has its own dedicated – so it's not just someone on the Flare side who's trying to onboard an IXIA, DITA, XML person, it's someone who knows DITA, who's specialized in that, that's going to help hold your hand and onboard you to make sure that you're happy with the solution. And our customer success teams are world-class, ready, always to be there to answer any questions that you might have. The goal is to be successful using our software.

David Turner

Absolutely, and I like to hear that. And there are some great tools available. From the partner perspective, when do you use an import tool versus when do you use a conversion partner? A lot of that's going to depend, again, on your use case. I tell people all the time, a lot of people are familiar with the idea of converting a PDF into a Word document. They have a nice standard software for that. And it's easy, right? You click convert and your PDF becomes a Word document. And if you've written a novel and it's just basically straight text, it'll come out perfectly. If you've got a couple of tables in there and maybe a footnote, you might have some challenges. But again, if you don't have a lot of content, it's pretty easy to clean up.

But then, if you have a mountain of content, if you've got a thousand pages of content, do you want to go through and clean all that up or do you want to hire a professional who has different tools and better tools? And that's really the same thing here. It's pretty easy to get a Word document into XML, or even a small amount of Word documents can be brought over, and maybe you have to do some minor cleanup. But then you have to start and look, where do I need to bring in a partner? And I know MadCap is committed to having the solutions team to help you find out, make the right decisions about when the tool makes sense, and when a partner makes sense. So anyway, we've talked about the pathways, we've talked about the barriers, we've talked about your commitments.


Let's talk about getting started. What are some things that you can do to start getting ready for this?

Dipo Ajose-Coker

Okay, so yeah. Now, while you might not be in a structured writing tool already, you can start applying some of the principles of structured writing, just for the bare fact that it does help with creating great content. So, I look at the principles, the best principles of structured writing, information typing. That is one of the, I think, the most beneficial parts of structured writing, in DITA structured writing especially, because it introduces the concept of first of all, dividing your information so that you are making it easy. You want to create that content. For the writer, they're only concentrated on creating a task element, or they're creating a concept element or a reference element. These are different types of information, that looking through the inputs that you get and then sorting those out will allow you to better create that content. But also, the DITA DTD also prevents a mixture of types of content.

And so, you could start doing that just by applying that on paper. Look at the content, create a Word document and title it "concept," and then the title of the concept. And you start doing that manually in order that you're preparing. You want to also look at the granularity. You don't want 16-page documents anymore. And even if you are in Flare, Flare is XML. It's topic-based writing. However, there's no limits as to how long a topic can be. What you want to do is start reducing the size of your topic so that it's easier to reuse. It's easier to reuse a paragraph of information than a page of information because you might have different elements in that page that you want to put in there. And that leads on to reusability. The more granular your content, the more reusable it is. However, you've got to watch it. Don't go too granular. Don't start creating files with one word in it. There's just no point, use variable in that case.

And then semantic tagging, start applying semantic tags to your XML if you're an XML. If you're in Word, it might be, I don't know how you would do that, but you could maybe put it in brackets, just a context type thing. Audience is this, meant for this product and so on and so forth, that you can add, maybe even as the comments. And in preparing for the journey, don't do it by yourself. Talk to the consultants, talk to people who have the expertise to do this. They've got the experience and expertise to help you along the way.

David Turner

And I'll just add on quickly to that, that really consultants are so critical, because while we focused on talking about migration and conversion today, there really are a lot of factors. And I just listed to a couple here. What's your content model? What's your reuse strategy? What are your workflows? What are your metadata and taxonomy needs? There's all of that. So anyway, we've got five minutes left, so I know we want to get to a couple of questions that are there. I'll let you throw in here just a couple of last essential strategies and considerations, and then we'll head over to the questions.

Dipo Ajose-Coker

Yeah, well basically, I mean, it's all on there. It's underestimate nothing and plan for everything. Something will go wrong. Don't worry about it, something will go wrong. So just plan, have a plan B for pretty much everything. Having a content audit will help you then develop that strategy, know how you want to divide that content, what sort of outputs and how you want to mix great branches and so on and forth.


You must keep your teams trained. It's ongoing training. Yeah, learn about DITA. You do that the first few months, and then nothing else after, that's just basically heading for disaster at some point. Mind the compliance gap. I did mention that. Make sure that you are able to trace everything. And in being able to trace everything, if you're documenting all the steps of your conversion process, then that is going to help you to mind that compliance gap. And finally, I'll say the perfect – sorry, the enemy of perfect. Perfect is the enemy of done. Sorry, I just got that all wrong. Perfect is the enemy of done. Yeah. So it will not be perfect the first time around. You can aim for perfection, but be ready to accept good enough to go.

David Turner

Well, thank you, Dipo. And Marianne, I apologize, I didn't leave nearly enough time for questions. I know, I'm so sorry, but –

Marianne Calilhanna

That's okay. We have a lot of questions. We're not going to get to all of them. So I want to let everyone know who submitted a question. Absolutely, Dipo or David, or Dipo and David will be getting in touch with you to answer questions outside of this forum. We have a couple similar questions. So I'm just going to combine a few into one. But Dipo, can you speak to tools or assistance for that migration from Flare to DITA, Flare to IXIASOFT? What can be done to make that conversion process easier?

Dipo Ajose-Coker

That would be that slide where I mentioned applying the principles of structured content. First of all, try and get that structure in the source as right as possible so that you are able to apply and conversion matrix to it. And so, I could take the FrameMaker example. You've got character styles and line styles, I think it is. Well, make sure that it is applied uniformly in the same way. And if you're in Word, it's even worse because adding a bold to a particular style creates a new style. And when you have a plethora of styles within your documentation, it's going to be hard to say, for every header one, create new topic. That's a kind of matrix that you would use. In terms of tools, Flare has a built-in converter in there.

However, it's not for massive loads of documentation. It will help you out. I mean, you can use it to convert 6,000 documents if you want. However, what you will miss in using a service like a Harmonizer is that opportunity to have the analysis of it to spot all the areas where you can reuse, and then to automatically recreate those topics of reuse for you. And then, well, I could talk forever on this, I won't because we are short on time. Give me a bell and I'll point you to the right people at MadCap Software or at DCL who can give you more detailed answers and specific to your situation as well, because every situation is different.

Marianne Calilhanna

And so the rest of the questions, we're going to have to be in touch. We have come to the top of the hour, and I want to thank everyone who stayed on. We really appreciate your time today. So this is the DCL Learning series. It comprises webinars such as this. We have a monthly newsletter and a blog. You can access many other webinars that are related to content structure, XML Standards. Dipo is featured in many of our webinars. Those are found at in the on-demand section. We do hope to see you at future webinars. Stay tuned. You'll be hearing from Dipo and David to answer the questions we couldn't get to today, but this concludes today's broadcast. Cheers, everyone.

Dipo Ajose-Coker

Thanks. Bye.

bottom of page