Content migration

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.

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]

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.

Old to new

1. Remember the content strategy on your new site can evolve as brand objectives change and as you start to understand how content performs in this new environment. It may be necessary to bring back old content that hadn’t initially been migrated — make sure you archive everything that doesn’t make the initial cut for this reason.