Tracking Web Site Migration Progress

Before undertaking your large site migration, you should define how you will track progress. As mentioned in a previous post, you'll want to be moving toward a compelling vision of your site. As such, you probably do not want to be tracking only the page count that's been migrated (aside from inaccurately tracking your progress, your overall quality may be better by reducing as much content as possible). One possible approach is to track a variety of dimensions, which would result in status graphs like this:

In this example, 90% of the pages are in the system, 50% of the templates are done, 30% of the major functionality is complete, 20% of the sites are complete, and 10% of the integration with other key systems is complete. This is probably a very dangerous situation, threatening major reworking of the pages that have already been migrated (since, for example, once diving into the sites and functionality you may realize you need different metadata). It probably doesn't make sense to have the percentage complete of each of these progressing in lockstep, but by tracking things in this way you can highlight issues. Also, you more clearly see how much work you have left. In the case above, if you were only looking at the percentage of pages complete, you would think you were almost done. That said, the graph above clearly indicates that is not the case.

So what are some of the dimensions you will want to track?

Pages or Content Items

Depending on your site and objectives, you may want to be counting pages or content items. In a site with significant content re-use, tracking content items (along with sites/templates) will make more sense. Remember again that objective isn't to ram a lot of content in place, but only meaningful data (see my previous Web Diet blog post). In addition to pages or content counts, another item to potentially track is content types.

Sites

If you're only migrating one site, then obviously this isn't a metric to track during migration. That said, if you are migrating multiple sites that are driven off of the same platform, then it probably does make sense. Tracking when sites are actually launched is probably the most useful (rather than when they are "ready" to be launched), so that you are actually confirming that it works out in the wild (search traffic comes to your site, you don't hear about major issues from users, etc).

Templates

The look and feel usually receives a lot of attention, so tracking when templates are implemented would be compelling to a wide range of stakeholders. In addition to the look and feel, the template's functionality should be complete before a template is declared Done. For example, if there are auto-pulls for a template, then the template is not complete unless the auto-pulls are complete.

Integration

Large sites will usually integrate with a variety of existing systems, especially internal systems but also external systems. These may be largely independent of many of the other factors you are tracking, except for data/content format and common taxonomies. Also, since working with other teams can take a long lead time, tracking these and putting the focus on early collaboration is important.

Functions

Your site objectives might include new functionality, and, depending on the complexity, these can take a while to implement (including the need for iteration as you explore what really needs to be implemented). Functionality could include things like quizzes, maps, contact form, calculators, data manipulation tools, special search tools, and conference/event management.

Languages

If your site will have multiple languages, then you may want to be tracking certain functionality (it's not just about being Unicode-enabled!) but also tracking when different languages are fully complete. This will include translations, and you'll need to define how complete different languages need to be.

Channels

Sites are expected to share content in multiple streams / channels, and this may be an important aspect of what you are trying to accomplish in the new site. Example channels could be, in addition to your web site(s): email alerts, Newsletters, APIs, RSS, and other sites (like Swivel for data). Getting the channels right has similarities with the integration points, but in general channels are more generic. Aside from making sure the data is compatible with multiple channels, you'll need to have your database layer well implemented and also define the mechanisms that the content can be accessed (which will include defining the url structure for accessing these different tools).

These are just some examples of metrics to track during a migration, but hopefully give concrete enough cases to help think through what makes sense for your site.

I hope to cover in a future blog post how to actually go about confirming how far you are on each of the metrics you track, since self-reporting is not desirable. In addition, by defining how you will measure in advance, you may avoid issues in the first place since the system will be designed to satisfy those metrics.

As always, I would appreciate any comments.