Content migration

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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[edit]

Reasons to consider migrating content[edit]

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[edit]

Even though some of the reasons like cost might be obvious, there are some less obvious reasons to avoid a migration exercise

  • Content, especially unstructured content is typically one of the larger artefacts of business, moving data of this size exposes the following risks:
    • Risk of corruption in transit
    • Risk of loss of context, content not only have binary data and metadata, it typically also has historical audits, security (folder and class security), multiple binary data sets and more
    • Risk of external references not being considered (broken links to content).
  • Due to the size of this date, Content Migrations can be very resource intensive (Source- Destination- Temporary- storage, network bandwidth etc.).
  • Auditing the migration process is can be complex and need to ensure consistency and traceability.

Approaches[edit]

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 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[edit]

  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.

References[edit]

External links[edit]