Content migration

Implementing a content-management system can be a boon to your organisation, but anticipating its benefits without knowing exactly what information it will control could end up costing you. By Martin White.

In most cases, a CMS is used to upgrade the publishing environment of a mature website or intranet. Therefore, a CMS is rarely implemented without there being legacy content to migrate into the system. This will be the most difficult element of most CMS implementations and may well derail the entire project plan. The paradox is that if the existing system is well organised and managed then there is probably no good reason for implementing a CMS in the first place.

The process of ensuring that content migration is managed effectively has to start at the very beginning with a careful review of the content of the site. However, it involves more than just migrating content. Each page will have design elements that may or may not be translated into the new system and, indeed, in many page-authoring systems the link between content and design is hard-wired. Then there is the issue of handling any change in the links between pages and, finally, the management of metadata.

Most static sites have very little metadata associated with them – usually no more than the name of the author and the date of publication. Virtually all of the benefits of a CMS are derived from the metadata associated with each page and adding this is probably the most time-consuming part of the entire process.

Conducting a content review

When developing the business case for a CMS, an initial review of the broad content categories on the site should have been carried out. For the purposes of migration, this should be undertaken at a more detailed level, especially where an intranet is concerned, as just one missing page containing mission-critical information could have a significant impact on the entire organisation.

On the other hand, a great deal of content on the site, at least 20 per cent, might no longer be current or relevant. The problem is there is no logical way of identifying this content. For a website page, hits can be an important measure of useful content, but this is not the case for intranets, which is why it is difficult to identify valuable intranet content that needs to be migrated.

The process of conducting a content review is quite simple, but immensely time consuming and unpredictable in terms of how long it will take.

The standard way of conducting a content audit is to use an Excel spreadsheet in which every page of content is identified. The typical columns used are: ID number; Page title; Link; Document type; Metadata; Author; Redundant, outdates and trivial (ROT); Comments; and Priority for attention. This format does not convey the actual scale of the work involved.

There is a very good account of this process, as undertaken by Peoplesoft in 2001, (http://www.boxesandarrows.com/archives/002721.php), which resulted in 6,000 lines of Excel spreadsheet information, but no mention of how long the process took.

Managing the spreadsheet is made difficult by the fact that it is unlikely to fit on one screen, so there will probably be multiple panes for each worksheet, never a comfortable way to handle Excel files. It may be possible to identify sets of pages that are consistent with one another, but there will be few instances of these, so the time saved will be negligible.

Images and diagrams can present particular problems. Often images are handcrafted for a specific piece of content and, in migrating the content, the size or aspect ratio of the image may need to be changed. To do this, it may be necessary to identify and access the source image or diagram, which might prove difficult to locate as most images will have meaningless file names.

Only when this work has been completed will it be possible to derive some indication of the work that needs to be done within the migration process itself. Of course, it is not just a question of migrating content from one site to another, but also of deciding where content should be migrated to on the new site.

Software-supported migration

Many CMS vendors claim to have software that will automatically copy content from the existing system. While this is possible in principle, in practice it is worth looking at the small print. Software works according to a set of rules. If the rules are broken the software either doesn’t work, or worse, works in unpredictable ways.

As companies become aware of the resource-hungry nature of content migration, a market for smarter content migration through applications software is beginning to form. Most of the larger CMS vendors either have their own proprietary application, or rebadge one of the commercial products already on offer, such as those from Vamosa (www.vamosa.com) and Metalogix (www.metalogix.net).

The Vamosa site has an ROI calculator that compares the cost of manual migration with a Vamosa software licence. The result is some frightening costs for the manual process, so as a sales tool the calculator is very effective. But the problem with all ROI calculations is that a lot of assumptions have to be made about unit costs, in this case, of migrating a page. At the outset, few organisations know how many pages and files there are on their sites, and how many are worth migrating. Therefore, working out the benefits of automated migration versus manual migration for a business case based on ROI is not very effective.

There are three main issues to consider when evaluating these products. The first is to be certain they will work given the particular range of content on the existing site. The second is the extent to which they can be used for specific CMS products. Currently, the Metalogix product is only suitable for Microsoft Content Server. The third element is the way in which the performance of the product can be checked on an incremental basis, rather than trusting it to luck and some very clever software. This requires a set of test data that can be migrated into the new CMS, where the degree of successful migration can be assessed.

There is one problem that is presently very difficult to address. All these CM migration products are dependent on a stable CMS environment, so the process of migrating the test file cannot begin until the CMS has been loaded and developed. This is not the time to discover that the performance of the migration software is not as high as was anticipated, requiring a significant amount of manual migration and checking.

Both Vamosa and Metalogix have established a good client base and the products of these companies work well in situations that play to their strengths and capabilities. Without doubt there will be more products coming to the market to meet the increasing demand for migration solutions. As always the watch word is caveat emptor, with any decision to use software-supported migration based on a sound knowledge of what has to be migrated and an equally sound appreciation of the risks and rewards.

Migration strategy

The time to start the migration process for any sizeable site is as soon as the content audit has been completed. This could be several months after the start of the CMS implementation, but work can begin on removing ROT content from the current site, working with authors and technical staff on file names, and moving some of the more creative sub-sites to the new design templates. The secret of success is not to lose site of the overall timeline and to weigh up the level of effort going into the content audit and migration against the benefits to users.

When implementing a CMS, the ultimate goal should be delivering information to users that they can rely on rather than just being able to say, ‘Our new CMS went live on schedule’. One of the maxims of all CM projects is the importance of managing expectations.

It is essential to undertake a content audit early on in order to make a realistic assessment of the scale of the migration problem and to identify the categories of content that will be available at the time of launch.

At the time of writing this article I was reading a pre-qualification tender document from an organisation looking to implement a CMS. The document stated that the organisation had around 200 websites and that the volume of content was difficult to quantify, but would be around 500,000 pages, increasing by five to ten per cent a year. Even at the lower of these two rates, some 25,000 pages of new content will be created from the time of releasing the tender document to implementation of the system. Nowhere in the tender documentation was there any specific reference to migration issues, yet the tender was suggesting that the system would be implemented within six weeks of the contract being signed and the initial website would be running within six months.

By comparison, in a presentation given at Intracom 2002, a company described how it had purchased a CMS in April 2001 and managed to get the intranet of some 250,000 pages live in August 2002.

In the world of CMS implementations there are very few statistics about the success of projects. In my opinion, too many companies see the selection of a CM vendor as the major challenge and that once this has happened, all will be well. The reality is that it is only when the vendor is selected that the problems really begin and, by that time, the launch of the website or intranet has already been announced publicly.

The bottom line is that for migration to be accomplished on schedule, it needs to be considered at the project’s outset.