I have never yet seen a CCMS migration project that stayed within its original schedule. I do not say that to talk the undertaking down. A CCMS migration is one of the most worthwhile investments a technical writing department can make. But the discrepancy between planned and actual effort is strikingly large in this area.
There are reasons for it. Most are well known. And yet they are underestimated again on the next project. That is why I write them down here.
Why CCMS migration schedules regularly fail to hold
The first reason is structural: a CCMS migration is a process rebuild, not a software introduction. A process rebuild that changes the way information is created, structured, managed, and delivered. Anyone who plans it as an IT project underestimates the human and organisational share of the work from the very beginning.
The second reason is the data base. Most companies underestimate the state of their existing documentation before a CCMS migration. If you have 500 Word documents, the relevant question is not: how long does the migration take? The relevant question is: how many of these 500 documents are current, complete, and correct? In my experience, the answer to this question is rarely comfortable.
The data-rubbish problem before the system is introduced
When you carry content into a new system that is wrong or substandard, you fill a new system with an old problem. Garbage in, garbage out — that applies to every system introduction, not just this one.
The first decision should therefore be: what do we migrate, and what not? Discontinued products, outdated functions, content that nobody can verify any more — none of that belongs in the new system. It costs effort, creates ballast, and makes the structuring work harder.
My suggestion: start with the current, validated product portfolio. That gives a clear basis from which you can plan. Everything else is a decision you can make. But you don’t have to make it straight away.
A situation I know: a piece of information needs minimal revision. The revision takes three minutes. Importing it into the new system would take two days. There is no blanket answer here. It depends on how time-critical the project is and whether translations are involved. If they are, importing is almost always the right way — because you can then reuse existing translations as soon as the source text stays unchanged.
In practice, around 40 % of the existing documents were taken out of the migration scope — discontinued products, duplicate versions, content with no verified validity status. That reduced the migration effort considerably and at the same time markedly improved the quality of the data stock in the new system. That is not a side effect, that is the goal.
The underestimated process rebuild in a CCMS migration
Working in a CCMS differs fundamentally from working in Word documents. You suddenly work in a database, have to develop metadata, deal with XML or Markdown, observe structuring rules. Topics such as DITA, iiRDS, or ETIM are new to many teams.
In concrete terms that means: training, familiarisation, mistakes, corrections. Productive operation does not begin on the day the system is handed over. It begins after a learning phase whose length depends on the team’s starting state. Anyone who does not account for this run-up in the project plan has an unrealistic project plan.
The iiRDS specification provides good orientation on where the road for information delivery can lead. iiRDS specification, tekom Anyone who understands this early makes better architecture decisions.
Another aspect that is regularly underestimated: the interface work. A CCMS is not an isolated system. It has to receive data from CAD systems, ERP systems, and translation tools, and export it into various output formats. Each of these interfaces is a project within the project. I recommend clarifying explicitly in the system design which interfaces have to be mapped in the first step and which can be added in a second phase. All at once is rarely the right approach, and almost always a reason for delays.
Change management — leadership work, not a workshop
The third underestimated element in every CCMS migration: human resistance to change. That is no reproach against staff, it is an observable regularity. People are energy savers. The familiar path is less exhausting than the new one.
When I write about change management, I do not mean guru workshops with „you can achieve anything“ messages. I consider those of little use. What I mean by it: conveying transparently what is changing and why, showing staff the development prospects that come with the new system, drawing a clear line as to when the old way of working is no longer permitted. And holding that line.
You will get complaints. That is normal. Your job is not to be popular, it is to position the department for the future. Both at the same time rarely succeed fully.
In concrete terms I recommend: determine early on for each team member what role they will take on in the new world. Who is suited to structuring and maintaining the metadata model? Who to terminology work? Who to quality-assuring the imported content? People who see a concrete new task support change considerably better than people who only see the end of the old task. Analyse your team’s strengths and plan their development early. That costs time at the start, and saves resistance over the entire course of the project.
Connection to the EU Machinery Regulation 2023/1230
A CCMS migration also offers a good opportunity to anchor regulatory requirements structurally. The EU Machinery Regulation 2023/1230 places concrete requirements on user information, from the completeness of risk coverage to translation quality. A CCMS whose metadata structure maps these requirements from the outset makes conformity checks considerably easier.
Anyone who waits during the CCMS migration until the system is running and then retrofits the conformity structure incurs unnecessary extra effort. Better: take the requirements of the EU Machinery Regulation 2023/1230 into account already in the system design. Then you kill two birds with one stone.
The tekom publications on structured technical documentation provide a good conceptual basis for this. tekom, structured technical documentation In addition, I recommend the iiRDS specification as a reference for future-ready metadata models. iiRDS specification, tekom
In concrete terms this means: when modelling metadata, check whether you plan from the start for fields for document type, product affiliation, revision status, and language version. Those are exactly the pieces of information you need for a conformity check. You invest particularly in the design phase, and spare yourself laborious retrofitting in ongoing operation later.
AI and system introduction: mind the order
I am often asked whether AI tools can be deployed directly during a system introduction. The answer is: yes, but in the right order. AI can help with structuring source material, with consistency checking, with creating metadata suggestions. But only if the data base is ready for it.
In concrete terms I recommend: basic structure and terminology work first, then integrate AI support step by step. What that means in practice I have described in the article on AI in technical writing.
One more thing on the subject of the schedule: plan a buffer phase of at least two to three months after the official system handover. In this phase the team works productively, makes mistakes, asks questions, and raises requirements that were not known before. That is no project failure, it is the normal learning process. Anyone who does not plan for this buffer is under pressure and then makes poor decisions: shortcuts in familiarisation, migration of content that would have been better revised, or a relapse into old ways of working.
Conclusion: what you should change before the CCMS migration
In my experience, three measures before the project begins pay off most strongly.
First: clean up the data base before the CCMS migration begins. Identify outdated content and take it out of the migration scope. That saves more time than you would assume beforehand.
Second: start the terminology work. Anyone who migrates into a CCMS without maintained terminology rebuilds this work in ongoing operation, under considerably less favourable conditions.
Third: describe the processes before the tool is introduced. Anyone who only asks after buying the system what the new creation process should look like has reversed the order.
The three measures named can usually be completed in two to four weeks. They cost time. But considerably less time than the problems that arise when they are skipped.
If you are planning or preparing a CCMS migration and want to know where the typical pitfalls lie, I am available for a conversation.
Before the next tool is bought — let’s talk first
In technical writing departments, it is rarely the tool that decides, but the data base and process maturity. Schübeler Consulting examines your concrete situation: degree of modularity, terminology, interfaces, staffing setup. The result is a recommendation with which you can justify your next investment robustly.
Book your initial consultation online →
Prefer to write? info@schuebeler-consulting.de
— Johann Jörgen Schübeler, Schübeler Consulting