Content Migrations can solve a number of issues ranging from:
Consolidation from one or more CMS systems into the fewer systems. 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 artifacts 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, hence, search engines would have to make some adjustments even if it is informed about the process.[citation needed] 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 to the loss of information but also incur additional resources.[1]
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.[2] 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.[3]
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.
The API[4] 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.
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.
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.
HTML files, JSP, ASP, PHP, or other application server file formats are the most difficult. The structure for Flat HTML files is 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 them as structured databases, 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 helping simplify development but makes it very difficult to migrate content because the content is not assembled until the user looks at it on their web browser. This makes it very difficult to look at the files and extract the content from the file structure.
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 the content and place it into a structure like a Database, XML, or CSV format. 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
Obtain an inventory of the content.
Obtain an inventory of Binary content like Images, PDFs, CSS files, Office Docs, Flash, and any binary objects.
Find any broken links in the content or content resources.
Determine the Menu Structure of the Content.
Find the parent/sibling connection to the content so the links to other content and resources are not broken when moving them.
Extract the Resources from the pages and store them into a Database or File structure. Store the reference in a database or a File.
Extract the HTML content from the site and store it locally.
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.
Transform the HTML to meet the new CMSs standards and reconnect any resources.
Upload the transformed content into the new system.
Old to new
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.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
