| 2 | | TODO |
| | 2 | == What does "migration" mean? |
| | 3 | In a general sense, //migration// means moving your data from one environment to another. Depending on the grade of difference between source and target environment, migration covers highly different tasks: |
| | 4 | 1. The simplest case is moving data from one IT system to another one, but keeping the same structure and data management software. This can, for example, happen when the system should be hosted on a new server, and is mostly an IT task the vendor of the system used can perform best. This is also the case if the target system is a newer version of the source system. |
| | 5 | 1. The next degree of difficulty is moving data from one software system to a different one, but keeping the data structure. An example is moving DITA content with metadata from one CCMS to another one. Such an operation is also rather an IT task best performed by the target system vendor, but we suggest to moderate this process with our expertise in data and metadata models. Even though if the data structure keeps in place, it is often possible to improve the data during migration by increasing the level of re-use etc. Also, mapping languages and versions is often an issue. |
| | 6 | 1. If not only the software system changes, but also the data model, we recommend to let us conceive the migration steps. While the export from the source and import into the target are still IT tasks, the data must be converted from the source to the target structure. Since such a transformation needs to map the data to different semantics, granularity and also re-use (like the re-use of warnings using the //conref// markup in DITA), it is a task that requires good expertise in data models and a neutral perspective on source and target systems. Often, there are ten thousands or even hundred thousands of objects to be processed, therefore the transformation must at least be semi-automatic with a high level of automation. |
| | 7 | 1. Finally, if yet there is no source system at all and the documentation is maintained in the file system, either modular (e. g., Adobe !FrameMaker) or unmodular (Microsoft Word), the structure must first be created from the unstructured source data. Basically, this task is similar to the previous scenario. Even in unstructured Word documents, there is at least some structure that can be derived from paragraph formats, positions of paragraphs in relation to other items etc. However, this structural information is rather weak and often used unsystematically by authors. Also, particularly in monolithic Word sources, modularization and re-use must be applied. Thus, even this and the previous migration scenario are technically similar, migrating unstructured and unmodular content to structured, modular content like DITA requires more thought and planning than transforming one XML structure into another. |
| | 8 | |
| | 9 | > **NOTE:** The examples mentioned above all relate to moving technical documentation between CCMS systems. The same principles apply, though, to other system categories, too, like PIM systems, Media Asset Management systems etc. |
| | 10 | |
| | 11 | == What we can do for you |
| | 12 | In one sentence: we can perform all migration process steps that the software vendors are not ideally suited to do. Thus, apart from the first and most simple scenario of just moving the same data from one server to another, we recommend to speak with us first. We start with the big picture and cut it down into smaller work items. While we definitely should work together with you to define the source / target mapping, and implement the (semi-)automatic data transformation, the export from the source system and import into the target system typically requires the assistance of the vendors. We will coordinate all these work items for you and take care that you can seamlessly continue your work in the new system. |
