Quality and Content Migration

Discussions of migration (insofar as they happen at all) often rush toward the mechanics. But we should always anchor our discussions of migration on quality. In fact, higher quality may be one of the reasons we face a migration at all (for instance, usually we are replatforming because it will result in higher quality overall, with the content quality being a component). 

In fact, in some important ways, migration planning isn't about planning moving from one place to another but about how to attain the high quality we want.

There are eight sides to quality and migration:

1. Quality is the first consideration in migration planning.
   

2. Quality is one of the migration control knobs.
   

3. You can either back into quality or you can plan it.
   

4. There is no perfect quality, and in fact, quality is in grayscale (and different for every organization).
   

5. There are many components of quality.
   

6. We need to consider existing quality…
   

7. …and we need to consider the quality after migration.
   

8. We need to consider short and long-term quality.
   

#1 Quality is the first consideration in migration planning.

Anchor the entire migration discussion on quality. In the end, we should maximize quality toward business and visitor goals working within the constraints of our resources and current content.

#2 Quality is one of the migration control knobs.

Organizations have much more control over migrations than they often realize. There are three control knobs: quality (the target quality you are shooting for), weight (how much stuff and complexity is moving), and distance (how big leap it is from the way things are to the way you want them to be). And all these control knobs are tweaking one thing in the end: the effort it will take to complete, which is why estimating effort is crucial. Although weight is the control knob that can most quickly make big swings in the migration, quality is key since what we really want in the end is high quality for the most important content. Also, quality is probably the most subtle.

#3 You can either back into quality or you can plan it.

The common approach to migration is to back into quality by:

• Some teams considering the migration “done” just because it is moved from one system to another (leaving it to another team to clean up, usually with no real time to do so)
  

• Migrations are sometimes distributed where different teams are migrating different sites or site sections, each with different expectations and delivery capabilities of quality
  

• In general leaving migrations to late in the game, when there is more emphasis on getting MORE done than on the IMPORTANT things done (for instance, it may be more important to hone and radically improve a small subset of content and not even move a large block that would be relatively easy to move).
  

A stronger approach is to consider the migration trade-offs and come to some agreements on quality

#4 There is no perfect quality, and in fact, quality is in grayscale (and different at every organization).

There is no perfect quality — in other words, any content could be improved. And sometimes low quality is ok, for instance, if you really need to have some information available for archival reasons (but that you, for example, slap an "archived page" designation at the top). Also, sometimes a small improvement in quality makes all the difference. For instance, perhaps a PDF isn't the best way to represent some information but instead of converting the entire content of the PDF to HTML the team spends time on the top reports to simply extract the existing summary (which is what most visitors care about anyway) with a link to the full PDF. There's a tradeoff between paying special attention to some content vs. to the bulk of the content (assuming the bulk of content makes sense to move), but nonetheless, there is always a range of quality

#5 There are many components of quality.

Quality isn't really grayscale but multi-dimensional, including things like:

• How structured the content is
  

• Whether assets that make up a piece of content are each managed or if for example it's all just hand-coded in HTML (which is highly related to the above, but different)
  

• Editorial quality that only people can really ascertain like voice
  

• Whether the content effectively applies a taxonomy
  

• More mechanical writing quality like spelling and grammar
  

• Visual design quality like spacing
  

• How actionable the content is (how shareable it is)
  

• How scannable the content is
  

• How reflowable the content is (for example for differently-sized displays)
  

• How well the content integrates with other relevant systems (for example passing effective data to site analytics)
  

• How consistent the content is across the repository
  

For all of the above, the question is whether it serves the audience and business needs. For example, there is little reason to highly structure content if it does not serve a business or user need (and in fact extra structure will adversely affect content entry).

#6 We need to consider existing quality…

The existing content quality is probably the most obvious, and can even be used to decide what content should be moved at all. This is in the realm of content inventories. Note that one thing that can be important during a migration is to set rules and thresholds around quality — in other words, that only content that meets certain quality level gets moved. This rule can then be used on an ongoing basis. Notably (and this fits back in with estimation), we don't necessarily want to even spend the time looking at pieces of content to decide what to do with it if we can avoid it.

#7 … and we need to consider the quality after migration.

This is the part that is perhaps most often missed, and where that distance knob interacts with the quality control knob. One of the key aspects of distance that we need to consider is how far it is from the current quality to the target quality. More importantly, we need to tweak these so that we maximize our success. For example, we may decide to target 80% of the quality we first expect in starting the first round of planning in order to actually target something that is achievable. The conversation of target quality also impacts other areas that don't immediately seem like migration, like how the templates can degrade in an effective way when some older content does not meet the same standards as the more recent content. The interaction between the standardization you have now vs. the standardization you expect after the migration, for example, has a direct impact on how difficult a migration is.

#8 We need to consider short and long-term quality.

The focus during migration is often the quality upon relaunch. But this obviously leads to problems, with digital presences often quickly devolving into lower quality over time. To combat this, do two things:

Use the same mechanisms during migration that you will on an ongoing basis. Ideally, you define rules about content quality that can be used to make content decisions during the migration that can continue post-migration.

Go for implementing the right structure in addition to having it look right on launch. The goal upon a relaunched redesign should not be just that it looks good right then, but that it is using the structures that will allow high quality over time. For instance, instead of hard-coding aspects of the page, it should use widgets that could render new future standards should they change. Another simple example is where content is tagged to flow correctly not only upon launch but to support search and other techniques that may change over time but require high-quality metadata to function.

In summary, please keep quality in mind when migration planning. In fact, this should be our starting point. As the eight points above show, the issue of quality and migration is more subtle than may be immediately obvious (and hopefully also more interesting).