Migration Part 2
Web Content Migration Project Design
by Reza Haniph
13-May-2004
Implementing a new CMS doesn't always call
for an involved content migration (c.f. John Girard's article in these pages). But oftentimes migrating legacy
content is essential to meeting business objectives, and in some cases it
can become a very large migration. If you've come to realize that
getting legacy data into your CMS is critical for the adoption, usage and
success of your venture, then it's time to focus the how: how do
you design the process to migrate content efficiently and effectively?
Assembling the Team
First step, don't be demoralized. This isn't an easy task, but can still become do-able if broken down into discrete steps.
Reframe Perceptions. Your first battle will be against pre-existing attitudes towards the migration. These are always complex but normally slanted towards under-stating the complexity of the problem (time, resources and finances), especially on behalf of managers focused on CMS tool selection and implementation. This psychological wrinkle needs to be acknowledged upfront and addressed.
Start compiling the information required to help you to reframe perceptions. We've found that information sessions with other companies undergoing migrations, talking with consultants, and perhaps most importantly, trying pilot migrations will help adjust outlooks and expectations. Therefore, make sure you start this process as early as possible.
We should also note that people may believe that this is simply a "technology" problem that can be addressed with a "technology" solution. No so. Technology is certainly key part of the solution, but it must work in tandem with the people, the processes, and the organization. All need to be working together to make your migration a reality.
Assemble a cross-functional team. Content migration represents a multi-dimensional problem that requires broad expertise. You'll need, for starters, an experienced project manager with executive support that can negotiate across business units. This person is responsible for galvanizing the team into action, and securing the necessary resources. A taxonomy specialist will be needed to understand how people search and retrieve information, and to develop a flexible taxonomy. Two technical members will be needed: one with working knowledge of the CMS, and another with knowledge of your internal web infrastructure. Web design experience is also required, with a slant towards the specific needs of the sites being migrated. A user experience (usability) expert and a member of the business unit being migrated (usually from marketing) complete the basic team. Other members, like knowledgeable content and business users, may be called on as circumstances dictate.
In short, you may need the time and attention of the same team tasked with implementing the CMS -- or even a second team of similar profile. In either case, you will need to account for migration on your resource Gantt charts.
Centralize migration activities. To enable the reuse of experience across business units, teams usually centralize migration activities. There's much to reuse from early migrations, including automation tools, design templates, taxonomies, user experiences and training. Rather than keep reinventing the wheel, we've seen companies become more comfortable as knowledge is captured and reused. David Tauriello, the Director of Content Management at the American Speech-Language-Hearing Association (ASHA), says that "with our new processes, we can do a 100-150 page migration in a morning, and that's exciting."
Use your content owners wisely. One of the assumptions often made is that existing content authors will migrate, cleanup or change their content. Not a chance. Most content authors are pursuing everyday jobs. Migration tends to be an add-on to everyday tasks, which isn't surprising considering migrations are often considered "easy". When presented with the choice of migrating content vs. current activities, their incentives and bonus will frequently be dominated by their current activities. We've never encountered a change in incentive compensation to encourage authors to focus on migration activities.
So, use them where they can add the most value: to review migrated content and ensure that the migration is accurate. Rather than presenting authors with unfamiliar processes and teaching them new techniques (like how to cut-and-paste and apply metatags), present them with their content to review.
Understanding Your Content
Jumping into a migration without taking the time to examine legacy content can be a rude awakening. Debbie Pascoe, Vice President at Maxamine, a company providing web site analytics, remarks that "companies are frequently surprised by the results of our scans of their sites. From the amount of content, to the number of broken links and old or stranded pages, people are shocked by their first unbiased comprehensive view of their content." Here's how to avoid that shock.
Audit Your Content. To start with, you'll need to understand what you're facing. There are many templates out there that can help you understand your content. Typically, companies only need to spend two weeks on the content audit for a site with under 4,000 pages. For much large sites, leverage web site analytics tool to assist the process (e.g. Maxamine's Knowledge Platform). During that time, you'll gain a tremendous amount of new information about your site, and how to start planning the migration.
Establish a Content Convention. Be careful what you're counting and how you communicate your message. We've seen teams use the generic term "counts" when referring to the quantity of their content. This becomes confusing - is it individual pages, or does it include images, flash, powerpoint and word documents, spreadsheets and other objects? Confusing theses objects may over-estimate the scale of the migration effort. Or greatly underestimate its complexity.
There are a lot of things that make up what a piece of content is. Is it a document? Is it a thumbnail? Is it the metadata? Is it a header, footer, main page? Come up with a standard convention for referring to your content and stick to it. It'll make measuring, managing and communicating progress that much easier.
Track Your Content. Once you have a convention, we suggest that you establish audit trails as the content is processed. This will enable you to gauge progress and identify bottlenecks as your content is being processes. This will allow you to understand how and where content is being transformed, and be pro-active about any problems along the process.
Decide What to Migrate. One critical decision is what to migrate, and what to leave or archive. Frequently large amount of content may be out-of-bounds for an initial migration effort (e.g. courseware, highly secure content, contracts). These specialized content types require additional processing, templates and security protocols that may complicate your initial migration.
Delivering Results
Predicting all the activities and workstreams necessary for a migration is a daunting task. It's almost inevitable that something will get left out. However, much of the processes and tools developed on early migrations can greatly reduce the risks associated with future migrations. The key is to focus on "quick hits": short, manageable projects that can deliver consistent results in a limited timeframe.
Run a Pilot. We've never met a customer that hasn't run a pilot. To work out the kinks in the process, and become more familiar with your content, run a pilot program on a limit amount of content. This is your beachhead in your migration campaign, and allows your team to test ideas and practices.
Running test and benchmarking results during the pilot will give you a better idea of how the rest of your web properties will be migrated. Some of the statistics we've seen collected include:
- Speed: time to migrate a page, site freeze duration, customization time (site navigation, templates, workflows);
- Quality: pages removed, internal and external link integrity, metadata coverage;
- Cost: cost per migrated page (automated), cost per migrated page (manual) ;
- Volume: number of pages, pages changed since latest migration.
Leverage Technology. Taking the time to ensure that results are accurate before communicating with the content owners is critical. In many cases, leveraging technology solutions before content authors are involved presents an attractive opportunity. By the time the content reaches them, it's been migrated, converted, tagged and ready for review.
We've seen people go down the path of using an army of temporary help to perform manual migration tasks. Migration work requires knowledge of your content and your business. It also requires careful analysis and design. We believe hiring low wage or even offshore resources should be considered only in extremely simplified cases. Instead, we suggest using technology solutions to extract content and then presenting the results to content authors for review. This will save them the routine tasks of content standardization, cutting and pasting content, converting links and changing encoding.
Focus on "Mini-Sites". Pilots are a great way to see results quickly and devise new approaches. We've successfully extended this to future migrations by using the concept of a "mini-site". A "mini-site" is a self-contained grouping of content, frequently represented by a business unit, government agency or corporate function. We look for some consistency in the content, and easy to identify ownership of the content within the organization.
How big does the mini-site need to be? Ideally, we'd start with between 2,000 - 4,000 pages using automated solutions (or under 500 pages with manual solutions). If your content is larger, you should be able to decompose it into natural groupings (e.g. press releases, case studies, best practices)
Although each mini-site may be slightly different, we've found that the 80:20 rule applies: you'll be able to handle 80% of the content using tools and technologies developed on previous migrations. There are always customizations necessary for each mini-site. For starters, site-navigation, design templates, and workflows will all need to be tweaked.
Use Site Freezes Carefully. You've probably heard various trail legends about extended site freeze procedures. In some cases, a two-week freeze ended up stretching to six, as migrations ran into problems. To be sure, managing the migration of dynamic assets is tricky business. Rather than use prolonged site freezes, we've seen companies carefully manage preparation activities, including pre-migrations of content. Preparation can reduce site freezes to a couple of days. Hopefully there won't be much that's changed from the latest migration, but if there is, much of the new content can be handled manually.
Develop a Menu of Options. The migration team should look at providing a menu of service options and prices, so that business units can understand what they are paying for. Business units can then determine the appropriate level of service at a price they can afford. We've found that some smaller mini-sites can invest the time of their content authors to re-craft their sites within the CMS system using existing templates. Other, much larger sites, need help migrating their content, and can't divert content authors as readily.
Carlos Villarreal contributed to this article. Carlos is a Managing Consultant in EDS Content Management Practice.