A previous blog post covered some of the types of metrics to track progress in a migration. This blog post explores ensuring that quality is acceptable during the migration.
A Naturally Iterative Process
Whether you have a high degree of human intervention or not, you will be following a iterative process like the one illustrated below. Basically, you'll have a stream of sites/functionality/etc that you are migrating. As you migrate, you are checking the progress by some means or another. The worst case would be the internal team not checking at all but then getting feedback from actual site visitors after launching a part of your site. Even in that case, you will find mistakes and know what needs to be fixed in the next round.
Let's look at these steps. For illustration in this blog post, the concentration will be on quality of content, although of course the drive to progress on other migration metrics needs to be high quality as well.
The Stream
You have a choice in how to phase your project, and you should ground your phasing in moving toward your compelling site vision. By keeping the above process in mind, you can further optimize what you start migrating. Probably the largest issue you want to avoid is re-processing any content twice (that's the "re-apply as needed" box in the graph above), which is covered below in Short and Focused Iterations.
Apply Rules
The next step is to actually migrate content. Since you want this process to be as streamlined as possible, I list this simply as Apply Rules in the process. The key about rules is that, if defined correctly, you can have more consistent treatment (and results) of your content.
In an entirely manual process, you would hopefully have some sort of written checklist/process for those using the tools to migrate the content. The process might be something like: "a) indicate in site inventory that you are working on the page, b) turn into XHTML, c) add descriptive image descriptions, etc". At any rate, some rules would be followed during the actual migration.
In a more automated environment, the rules would be embedded in the scripts/tools used for migration. Note that not all scripts are created the same, and you should challenge your system integrator to creating scripts or configuring tools that can do things like scrape pages that might not be totally regular. Some questions to ask your system integrator include: a) will you be scraping pages, b) will links/images/documents be "managed" when migrated, c) how will references (links, documents, images, etc) be handled such they are consistent, and d) how is acceptable quality determined (see the next section for more)?
Find Mistakes
If you are applying rules to your migration, why a separate step in the process to check your work? One reason is simply that mistakes are found pretty much without anyone explicitly doing anything, so it's important to know what to do when mistakes are found (the following steps in the process). For example, you may have done a careful job migrating some content, only to have site visitors find issues with the content after it has already launched. Aside from the situation where mistakes are found "too late", some reasons to explicitly search for mistakes are: a) a different "pair of eyes" (whether a person or a separate script) can help find issues not found in the first go-around, b) it's often easier or lower-risk to check for errors (if automated) than to ensure correct migration, c) correcting mistakes earlier rather than later is more efficient (especially to avoid doing anything over), and d) you may not have the resources / backing to do specific testing later.
What to check when looking for mistakes? Although simply having people eyeball the content, a checklist would be helpful to make sure key elements are being checked. Note that the checks ideally cover what people, automated scripts, and the system has generated. Some example items to check: completeness (for instance, when checking a page as opposed to a piece of content, making sure that all parts of the page are fully formed vs. "no records found" errors), your standards / style guide, consistent layout (old, large tables not blowing out pages for example), persistent issues, and unnecessary code stripped out and only your styles used (so that it's not just about how the content looks now, but that when you change your CSS the look will change as well). Note that some of these tests are checking the content in various contexts and not just the content alone (since it may be far easier to discover content problems by looking at the pages that are to pull the content).
For a large migration, you probably will not be able to manually check every page. For any page, you have the choice of whether and how to check for mistakes, which broadly speaking fits into three possibilities:
- Manually checking
- Automatically checking
- Not checking
The decision on which of the three paths to take can be done by a variety of ways, including: by content type, by size of page/content, complexity of page, and importance to the compelling vision for your migration. If blocks of the content is highly regular, and manual checking seems to indicate that the migration works well for this content type, then automatic checks probably makes sense. For archival information formatting and small irregularities may not matter, not even checking it may be acceptable.
Change Rules
Whether it is checklists or automated scripts, the rules should be changed so that either the issue doesn't come up again (preferable) or at least there is an easy (hopefully automated) way to check. An unacceptable process is that mistakes from automated scripts are simply siphoned off into a bucket of items that need to be dealt with manually. Not only is this inefficient, but if you let that bucket of problem pages grow, you could inadvertently be blinding yourself to a major underlying issue that cannot be dealt with one by one.
Re-Apply As Needed
This is a key point. You could appear to be migrating along swimmingly, and then find an issue fairly late in the process. Do you go back and re-apply the new rules to the old content? Obviously you want to avoid either the impact or occurrence in the first place. To limit the impact, you could implement things in a way that it's easy to re-run automated scripts on content for tweaks. To limit the occurrence, short and focused iterations might help.
Short and Focused Iterations
There is no way to anticipate the issues you will encounter during the migration, but, especially since you want to avoid having to repeat any steps (a la "Re-Apply As Needed" above), short and focused iterations can help. By short and focused I mean:
- Trying to define what is acceptable quality up front
- Migrating a small amount of easy as well as very difficult content, representing as much as possible the full breadth of the type of content that will be moved
- Implement as much functionality (see other examples) as possible, to better expose issues earlier rather than later (see Why It's Difficult to Migrate)
- Check as thoroughly as possible as early as possible
The above list of suggestions concentrates on initial steps of the migration. Further into the migration, a key point is to make sure you understand the issues (meaning, you know what happened and how to fix it) you are encountering as early as possible, attempting to make sure that there are no deeper systemic issues.
