Content Migration

Content Migration is the process of moving information stored on a Web content management system(CMS), Digital asset management(DAM), Document management system(DMS), or flat HTML based system to a new system. Flat HTML content can entail HTML files, Active Server Pages (ASP), JavaServer Pages (JSP), PHP, or content stored in some type of HTML/JavaScript based system and can be either static or dynamic content.

Content Migrations can solve a number of issues ranging from:

• Consolidation from one or more CMS systems into one system to allow for more centralized control, governance of content, and better Knowledge management and sharing.
• Reorganizing content due to mergers and acquisitions to assimilate as much content from the source systems for a unified look and feel.
• Converting content that has grown organically either in a CMS or Flat HTML and standardizing the formatting so standards can be applied for a unified branding of the content.

There are many ways to access the content stored in a CMS. Depending on the CMS vendor they offer either an Application programming interface (API), Web services, rebuilding a record by writing SQL queries, XML exports, or through the web interface.

1. The API^[1] requires a developer to read and understand how to interact with the source CMS’s API layer then develop an application that extracts the content and stores it in a database, XML file, or Excel. Once the content is extracted the developer must read and understand the target CMS API and develop code to push the content into the new System. The same can be said for Web Services.
2. Most CMSs use a database to store and associate content so if no API exists the SQL programmer must reverse engineer the table structure. Once the structure is reverse engineered, very complex SQL queries are written to pull all the content from multiple tables into an intermediate table or into some type of Comma-separated values (CSV) or XML file. Once the developer has the files or database the developer must read and understand the target CMS API and develop code to push the content into the new System. The same can be said for Web Services.
3. XML export creates XML files of the content stored in a CMS but after the files are exported they need to be altered to fit the new scheme of the target CMS system. This is typically done by a developer by writing some code to do the transformation.
4. HTML files, JSP, ASP, PHP, or other application server file formats are the most difficult. The structure for Flat HTML files are based on a culmination of folder structure, HTML file structure, and image locations. In the early days of content migration, the developer had to use programming languages to parse the html files and save it as structured database, XML or CSV. Typically PERL, JAVA, C++, or C# were used because of the regular expression handling capability. JSP, ASP, PHP, ColdFusion, and other Application Server technologies usually rely on server side includes to help simplify development but makes it very difficult to migrate content because the content is not assembled until the user looks at it in their web browser. This makes is very difficult to look at the files and extract the content from the file structure.
5. Web Scraping allows users to access most of the content directly from the Web User Interface. Since a web interface is visual (this is the point of a CMS) some Web Scrapers leverage the UI to extract content and place it into a structure like a Database, XML, or CSV formats. All CMSs, DAMs, and DMSs use web interfaces so extracting the content for one or many source sites is basically the same process. In some cases it is possible to push the content into the new CMS using the web interface but some CMSs use JAVA applets, or Active X Control which are not supported by most web scrapers. In that case the developer must read and understand the target CMS API and develop code to push the content into the new System. The same can be said for Web Services.

The basic content migration flow

1. Obtain an inventory of the content.
2. Obtain an inventory of Binary content like Images, PDFs, CSS files, Office Docs, Flash, and any binary objects.
3. Find any broken links in the content or content resources.
4. Determine the Menu Structure of the Content.
5. Find the parent/sibling connection to the content so the links to other content and resources are not broken when moving them.
6. Extract the Resources from the pages and store them into a Database or File structure. Store the reference in a database or a File.
7. Extract the HTML content from the site and store locally.
8. Upload the resources to the new CMS either by using the API or the web interface and store the new location in a Database or XML.
9. Transform the HTML to meet the new CMSs standards and reconnect any resources.
10. Upload the transformed content into the new system.

Vendors

• Active Navigation
• Kapow Software
• Proventeq
• Tzunami
• Vamosa
• Nonlinearcreations
• Seeunity
• EntropySoft

References

1. ^ What the Content Migration APIs Are Not

External links

• The Definitive Guide to Automating Content Migration
• Content Migration Seven Steps to Success
• No Small Task: Migrating Content to a New CMS
• A Look at Automated Content Migration: Part 1 - Kapow Technologies
• A Look at Automated Content Migration: Part 2 - Vamosa
• Content Migration articles on CMS Wire