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.

Business drivers

Reasons to consider migrating content

Content Migrations can solve a number of issues ranging from:

  • Consolidation from one or more CMS systems into fewer system. This allows 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.
  • Complex upgrade paths from un-supported versions can be simplified by migrating content to a newer version of the platform.
  • Compliance requirements might require more functionality from the underlying store, examples would be a need to audit content access, improved security or records management.

Arguments against migrating content

Content migrations entail risks. Even though some of the reasons like cost might be obvious, there are some less obvious reasons to avoid a migration exercise. These include corruption in transit and loss of context, particularly the unstructured content, which is typically one of the larger artefacts of business. There is also the risk of external references not being considered (broken links to content). The size of the data to be migrated makes the very resource intensive (Source- Destination- Temporary- storage, network bandwidth etc.), which means that auditing the migration process could also be complex and require consistency and traceability.

Another common issue in content migration is the loss of SEO and page rank in search engines. Migrating to another location and adopting a new software means that all website URLs are going to be changed as well,[1] hence, search engines would have to make some adjustments even if it is informed about the process. In a white paper, Oracle also outlined several issues involving the so-called people perspective. It cited the probability that people involved in the content migration might not have a thorough grasp of the history, structure, and meaning of the source data as well as the new system, which could lead not only in the loss of information but also incur additional resources.[2]

One of the methods that address the risks is the use of metadata. It is employed to describe, access, and manage records, serving as the ultimate means by which the integrity, trustworthiness, and authenticity of a record can be proven.[3] The process, for instance, could adopt a two-track framework where one track deals with the overall content, structure, layout, and vision, while the other is focused on metadata.[4]

Approaches

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[5] 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 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.
gollark: Well, you can't, really.
gollark: So, lucas, what exactly do you want to do? Because sandboxing like that is quite hard.
gollark: If you have them be unlabelled and have some code downloaded onto them, you could make it so you can't read the code, at least.
gollark: <@443563927251582976> Are you trying to make a bad potatOS ripoff?
gollark: ... hmm, that could probably work?

References
  1. "Top 5 Risks that Stop You from Website Migration and Their Solutions". CMS2CMS. 2016-06-09. Retrieved 2018-09-04.
  2. Oracle (October 2011). "Successful Data Migration" (PDF). Oracle. Retrieved September 4, 2018.
  3. TAHO (September 2015). "Information Management Advice 60 Part 5 Successfully manage Information Risks during System Migration" (PDF). Tasmanian Government. Retrieved September 4, 2018.
  4. Sanchez-Alonso, Salvador; Athanasiadis, Ioannis (2010). Metadata and Semantic Research. Berlin: Springer. p. 28. ISBN 9783642165511.
  5. What the Content Migration APIs Are Not
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.