Presented by Nancy Howe and gg Heath, Information Architects, Teradata Labs at the IXIASOFT User Conference 2016. How do you move half a million highly intertwined objects from one CCMS to another, while producing new content at a higher rate than ever? In this presentation we'll share the challenges we discovered, the solutions we developed, and the processes we used to migrate DITA content from a proprietary CCMS to the IXIASOFT DITA CMS. Teradata is a long-time DITA user, supporting approximately 300 deliverables, thousands of pages of content with up to 90% reuse, intense filtering, and translation. The long and winding road of migrating to IXIASOFT DITA-CMS included overcoming technical challenges like bursting massive conref containers into thousands of referable-content topics, completely changing our approach to versioning content, standardizing filtering, and implementing a new translation workflow.

1. ​ Move Our DITA Content to Another CCMS? Seriously?
​ gg Heath and Nancy Howe, Teradata
​ September, 2016

2. 2
No, Really….
© 2016 Teradata

3. 3
• At Teradata, we provide end-to-end solutions and services in data
warehousing and big data and analytics that enable you to become a
data-driven business…one that’s positioned to increase revenue,
improve efficiency, and create the most compelling experience for your
customers.
• Find out more at http://www.teradata.com
Who is Teradata?
© 2016 Teradata

4. 4
​ Today we’ll be sharing how Teradata is taking DITA content out of one
proprietary CCMS and putting it into IXIASOFT DITA CMS.
• Manage over 60 programs a year
• Approximately 300 deliverables
• Staff of ~40
• 70 percent content reuse
• ~50,000 files (maps, topics, images)
• ~120 ditaval files
• DITA, FrameMaker, and Word sources
What’s Our Story?
© 2016 Teradata

5. 5
Where Did We Start?
© 2016 Teradata
• Information Engineering tools and technology under constant
evaluation
• Requirements to:
– Reduce number of tools
– Save associated costs (software and people)
– Find an easily maintained and extensible CCMS
– Make it easier to connect to third-party tools
• Picked a CMS
• Tested features with our content

6. 6
Astoria IXIASOFT DITA CMS
Approval labels DRM versions
Effectivity/XPath DITAVAL
Conref containers Referable-content topics
Readable file names Auto-generated file names (CSH)
Major Feature Differences
© 2016 Teradata

7. 7
• Astoria approval labels:
– Freeze content for a deliverable map
– High maintenance to apply labels when changes occur
• IXIASOFT DRM:
– Manage updates to multiple documents across various releases
Approval Labels vs. Dynamic Release Management
© 2016 Teradata

8. 8
• In Astoria we used xPath for conditional, elemental filtering:
We had to learn how to include/exclude elements
• For IXIASOFT DITA CMS we needed DITAVAL files which required:
– Creating DITAVALs for every deliverable
– Testing output
– Dovetailed with filtering requirements for translation output
Filtering (Effectivity vs. DITAVAL)
© 2016 Teradata

9. 9
• Initial implementation in Astoria was single topics containing multiple
conref-able elements
– Not the best DITA practice
– Grew unwieldy fast
– Not easily maintained
• For IXIASOFT, elements had to be broken out into individual conref-able
elements
– Some were entire topic bodies
– Some were topic elements inside a topic body
Referable Content
© 2016 Teradata

10. 10
• Astoria uses human-readable file names
• We could control the filenames
• Direct linking in context-sensitive help to Ixiasoft file names broke the
links
– Helped engineering find a way to use the .csh file from Eclipse help
– Had to add <resourceid> strings to linked topics
File Names and Help Deliverables
© 2016 Teradata

11. 11
• Migrate only current content, no legacy
• Content clean up
• Migration responsibilities
• Break up our conref containers into referable-content topics
• Development then Production
• Import into a single DRM version (Import)
• Determine what content would be migrated and when
• Migration!!!!
Our Migration Process
© 2016 Teradata

12. 12
The Journey Begins
© 2016 Teradata

13. 13
• How do we burst our conref containers?
– Inside Astoria?
– Inside Ixiasoft?
– After export and before import?
• How do we maintain the conref referential integrity?
• Decided on a script to be run in between CCMSs
• Tweaking on the script was majorly iterative and fairly extensive
Migration Process: Burst Conref Container Elements into
Referable-Content Topics
© 2016 Teradata

14. 14
• Locates filenames that start with cc_
• Retrieves topic ID
• Finds all elements with ids
• Outputs new files as referable-content topics
• Associates new referable-content topics to their original references
Migration Process: How the Script Works
© 2016 Teradata

15. 15
• Rename all the conref container topics to “cc_<something>”
• Consolidate duplicated content
• Ensure we had no duplicate filenames system-wide
Migration Process: Prior to Bursting
© 2016 Teradata

16. 16
• Bursting tests began at the beginning of February, 2016
• Several months of tweaking the script
• How big can our import packages be?
Migration Process: Testing and Tweaking
© 2016 Teradata

17. 17
• Normalize content
• Related links (topic element
inside a topic topic)
© 2016 Teradata
Migration Process: More Tweaking?

18. 18 © 2016 Teradata
And that’s when Eric said…

19. 19
• Started with post-burst validation
• Added pre-burst validation
• Each validation gave us new issues to fix
Migration Process: Validate and Check for
Completeness in oXygen
© 2016 Teradata

20. 20
Migration Process: Validate and Check for
Completeness in oXygen
© 2016 Teradata
Error Description
Duplicate element with ID
<nameofid> found in the
same topic context.
Conref container has more than one element with the
same element ID.
Referenced topic ID
<nameofid> does not exist.
Occurs when #id in the referencing href does not
match the referenced topic id. This is caused by a
change to the original id on the referenced topic and
the href in the referencing topic is not updated to point
to the new id.
Reference with external
scope to non-DITA
resource does not have
the correct format
attribute set.
Xref must have following attributes:
@format="html"
@scope="external"
@id="<id-of-xref>"

21. 21
• Support our move from Astoria to DITA CMS
– Needed to add title elements to maps
– Missing type attributes on <note> elements had to be fixed
• Perform cleanup
– Removed <category> element
– Removed <othermeta> for showing/hiding comments
– Added <resourceid> to context-sensitive help prologs
– Removed scaling from graphics
Migration Process: oXygen Refactoring Operations
© 2016 Teradata

22. 22
Migration Process: Flowchart
© 2016 Teradata
Export content
from Astoria
Pre-burst
validation and
fix errors
Conref burst
Post-burst
validation and
fix errors
Refactoring
operations
Post-
refactoring
validation
Import into
Dev “Import “
DRM
Output
validation
Import into
Prod “Import”
DRM
Create new instances of
maps in product DRMs

23. 23
• Wiki instructions for all to use
• Continuous updates
Migration Process: Documenting Our Process
© 2016 Teradata

24. 24
• Bursting took many hours on our local workstations
• Using a remote desktop for bursting reduced the time by 40-50%
• Pre- and post-validation locally worked best
• Refactoring operations done locally went faster than remotely
Migration Process: Making Life Easier
© 2016 Teradata

25. 25
Import into
one DRM
• Allowed us to maintain our
extensive re-use
© 2016 Teradata
Migration Process: Managing Re-use

26. 26
• When were deliverables due?
• How could we leverage content synergies?
• Training people at the right time
Migration Process: When to Migrate?
© 2016 Teradata

27. 27
Migration Process: Migration!!!!!
© 2016 Teradata

28. 28
• Communication
• Coordination
• Testing, fixing, testing some more, validation, fixing, testing…
• Taking that final leap
Migration Process: Key Factors to Successful Migration
© 2016 Teradata

29. 29
Questions?
© 2016 Teradata

30. 30
Nancy Howe
Nancy.Howe@teradata.com
1.858.485.2142
gg Heath
Gail.Heath@teradata.com
1.858.485.3639
Contact Information
© 2016 Teradata