Migrations can easily grind to a halt. By methodically launching a subsite as a pilot, and giving time to react to issues, you can partially mitigate against that risk. For more information on pilots, see The Pilot in a Site Redesign or Migration: A How-to Checklist, CMS Proof of Concept, Pilot, Migration, and How to Migrate Content into a CMS. Just to re-iterate one important point, it's not a pilot if you don't plan for a) time for real users to use the piloted subsite, and b) time to fix issues before moving on to subsequent subsites (see more).

How do you select what subsite to pilot?

The pilot needs to launch an actual subsite, but which one? There are two key factors:

• Ensure the subsite will meet the objectives of the pilot
• How easily the subsite can be teased out of the rest of the site

Before diving into some of these details, note that if you have a very large suite of sites that you will be implementing or migration then you may be more likely to launch a site as your pilot (rather than a subsite).

Ensure the subsite meets the objectives of the pilot

You may be tempted to pilot whatever is easy, but that would not really help you much as a pilot since you probably would not learn much of importance. One of the most important things to keep in mind is your pilot needs to test how well your compelling vision for the site will be met, so that you can quickly correct course if your vision is not being met. Including the compelling vision, the subsite you select should meet the objectives of a pilot:

• Test key aspects of your compelling vision
• Test virtually all aspects of the eventual migration:
  • Automated migration
  • Manual migration/editing/entry
  • Deployment (making the site "live")
  • Integration with other systems
  • url rewriting
• Feedback, with the intention of making changes prior to migration
  • From actual web site visitors
  • From the core redesign team (inevitably, the more "real" the system gets, the team will see more issues and uncover more miscommunications)
• Estimate effort levels, which requires:
  • representative content types (again, not just the "easy" ones)
  • not just your super stars doing any manual migration, but a representation of actual users

Many subsites will probably be ruled out by the list. For instance, a subsite that just has one content type and only a few users would not work because a) you won't be getting a good estimate of the effort for moving all content types, and b) you might not get good feedback. Note that you may not be able to accomplish all of these objectives, but by thinking about them you can better choose a site and plan your pilot. On the objective of estimating effort levels, you will also need to establish a method of tracking people's effort (such as using some sort of automated reporting, or even a spreadsheet).

How easily can the subsite be teased out from the rest of the site

Broadly speaking, there are two ways of launching a pilot: a) replacing an existing subsite entirely, or b) as a stand-alone beta site (with a prominent link such as "Try the PuppyWeb Beta!"). Some advantages of replacing a site "in place" are that you are doing a deeper test, with all of your current users on a richer set of functionality. For instance, you can test url rewriting directly to see if your old links will still work (if that's what you are attempting). A stand-alone beta is easier to take down in case of emergency, and also is easier to extricate from the rest of the site. So which approach you take depends on your particular objectives and constraints.

Regardless, you will almost certainly have to think through linkages between the site that you are piloting and the rest of the site. A major factor in deciding on what subsite you pilot may be how easy it is to decouple / couple from the site. One helpful set to defining this is to draw a high-level architectural diagram, highlighting the interrelationships between systems and subsites. These are some of the factors to consider in how the piloted subsite will relate to the existing subsites:

• Internal references between content within the subsite under consideration
• References between your existing site and this subsite
• Other linkages with organization-wide services and reporting, such as site-wide search, site-wide RSS feeds, and site-wide statistics.
• References to the subsite from outside you site entirely (for example, Google references)
• How identifiable the subsite will be to site visitors (will the delineation between piloted and "old" subsites be clear to the visitor?)

If a subsite already "stands alone", then it may be easier to migrate that. If an objective of your new overall site is better integration, then you may be able to highlight that in the pilot (by pulling content from both the "old" stand-alone site and content elsewhere).

Redesigning your site or migrating to a new CMS? The size of your site matters in how you plan for it. Do you have a complex site? Answer these four questions (don't worry if you don't know the exact numbers):

(push "click to edit")

Obviously, the calculator above is not comprehensive, but hopefully it gets to the how complex, broadly speaking, your site is. The questions attempt to use fairly objective measures. If the calculator shows your site as simple but you know that you have underlying complexities that the questions do not capture, then of course take that into account. For example, this does not cover extensive content re-use, which is a bit less objective to add in a simple calculator (re-use means different things to different people) but important to complexity.

A quick note: if your site is simple, then congratulations! This is something to be proud of, since you have a site that is relatively easy to manage and maintain at a high quality. That said, obviously some sites just are more complex than others, so if your site is complex then that is entirely valid as well. The point of this article is to point out that the complexity of your site should drive how you plan and run the migration. See The Web Diet for ideas on how to slim down your site.

Why Site Complexity Matters

The complexity of a site is often implied in discussions, but this can obscure core requirements. For example, the majority of CMS discussions are probably of the Joomla vs. Wordpress (or pick your other favorite) variety. Big picture, this is appropriate since most sites are simple. If your site is simple (like this Hobbs On Tech web site is), then by all means launch into these discussions. Or just pick the system that all your friends are using. That said, if you have a complex site, then you probably need to consider other platforms and also use a more rigorous CMS selection process. If over the weekend for a personal site you were talking about Drupal vs. Joomla, then you may be tempted to apply that same discussion to your company's site with hundreds of thousands of pieces of content in multiple languages. The discussion / approach will need to be different for a complex sites.

Similarly, the complexity of your site impacts your implementation approach. If you have a complex site, then a rigorous process is key. For a simple site, perhaps no real process is needed at all.

Process for the Complex, Large Site

Implementing a complex site requires the most planning and coordination. There are just more moving parts and relationships to manage. For example, widely communicating a compelling vision is key for a complex site, since there are more people to communicate with, coordinate, and set expectations with. Similarly, clearly planning (and, again communicating the plan) is essential since the project is naturally more risky. Aside from the obvious reason of there being more to design, any ambiguities can quickly explode into major issues. For example, if you do not define core functionality clearly (let's say how content is re-used), then it can be implemented differently by different developers for various sections of the site. This ends up being even more complexity to manage, and an albatross that can weigh down future enhancements. Also, management items such as defining the metrics to track migration are even more important since there are more people to align. The complex, large site should consider following all the steps in this interactive checklist.

Process for the Simple Site

Assuming it fits with the vision, one of the keys of a simple site is to make sure it stays simple. This may be as simple as just being very diligent about the simplicity, or, for slightly larger sites, putting some sort of process in place about how changes are made to the site. In general, the simple site can concentrate on the why and what of the site, and not the how (see more about the why, what, and how of implementations). That's the reason so much discussion is about what the site should look like (for example, designing the look of a site) and much less on how to implement. So a simple site still needs to define the design, functionality, and IA (although perhaps not as deeply), but probably does not need to define the metrics to track a migration or have a pilot (or communicate progress during the migration). Also, automation in the migration is much less important.

Process for the Medium-sized site

Deciding how to plan for a medium-sized site implementation is probably the least obvious. Obviously, the *why* (vision) and *what* (IA, design, functionality) has to be defined. The *how* is the most interesting. If you are attempting a bold new direction for your site (rather than more superficial changes), then you may need to follow all the items on this checklist. In particular, a change in direction may mean that a pilot is particularly important. The breadth of functionality / relationships will also drive whether defining metrics to track the migration is important (if your site has a lot of pages but no other complexity, then a simple tracking of pages may be sufficient). A major consideration is how many internal stakeholders you have, which will impact how carefully you have to communicate / train. This, along with how much is to be migrated, will also impact how much attention needs to be paid to the estimation of staff resources required.

You're staring at a seemingly insurmountable pile of content that needs to be moved. For whatever reason, you are moving to a new content management system. How are you going to migrate this stuff? A natural conclusion is that you'll have to manually review, edit, and move content. That is understandably intimidating and would probably take a huge amount of time and effort. Moreover, especially for a large site, a manual approach has many other issues including lower quality due to inconsistency in decisions that the various editors make. Furthermore, even if you are going to be doing a lot of manual work, you should still look at the problem as a whole and break down the steps rather than just dealing with each piece of content in isolation.

So how can we turn this mess of content into something that is easier to deal with? In the following steps:

1. Divide the problem into manageable pieces
2. Take time to pilot and estimate
3. Re-assess based on your pilot, and migrate

Step 1. Divide content into manageable pieces: type, cut, automate

The first step is to break up your content into types. You may be lucky and your content is already neatly arranged or easy to identify. Or you may have work to be done to figure out your content types. You will need to do content analysis anyway to move into your CMS, so the first step in in the process is categorizing your content by type. To use a container ship analogy, instead of looking at the shipyard full of containers as a whole, start looking at each type of container separately.

The reason to break your content into types? You'll need to do that for a variety of reasons such as defining the metadata (which will help enable site behaviors) as well as define the editorial requirements on an ongoing basis. For the purposes of planning your migration, breaking into types will help you decide what to cut. You may feel that your press releases over five years old don't need to be moved, or the encyclopedia you tried that didn't work can be deleted.

One of the main take-away points here is that you want to define the rules for cutting content. For smaller sets of content, this may not be needed and evaluating / identifying from spreadsheets listing all content may work. But hopefully you'll be able to define rules that will allow you to not even have to take a second look at those that were cut. Defining rules may allow you to just cut wide swaths of content that isn't contributing value to your site. Some other ways of deciding to cut could include web analytics (cut anything that hasn't received page views in the last month), site section (not just the encyclopedia entries, but the whole encyclopedia site), metadata that already exists (the topic "parcheesi" doesn't interest anyone, so delete anything tagged to it in the current system), or even contributor/source (perhaps everything that intern entered three years ago can be safely deleted).

Next, you want to decide what you can automate. You've already decided what will be migrated, so now you need to decide what's going to be automatically moved. Automating isn't an either/or proposition, and in general you want to automate as much as possible. Again, the idea here is to define the rules about what will be automatically migrated and what will not. This will be useful in helping you estimate your effort and help prioritize. The biggest issue on what can be automatically migrated and not is the structure and "regularity" of the content. If you had a bunch of content that was already in a CMS, only referred to a common CSS stylesheet, was only in standard HTML, already had high quality metadata, and all the relationships between content was clearly defined, then you could migrate that easily. That's because in that example it's structured and regular. Chances are, your content is more interesting and varied (and hopefully less interesting once in the new system), so you will need to look at samples of your content and try to determine how regular and structured it is. If you can see patterns (which can be more art than science to find), then you hopefully can automate the migration of some portion of some/all content types.

After Step 1 of typing, and then finding rules for cutting and automating, you will have a more useful inventory of your content, with numbers like this:

Step 2. Take time to pilot and estimate

At this point you have some big numbers based on educated guesses, but you could still be wildly off on how many can be automated. At this point, take this one step further and try to estimate how long it will take to do the manual migration and automated migration. You might say that the press releases just need a small amount of manual massaging, so each one will take an hour on average. But perhaps those articles that you want to manually touch require actual rewriting, so will be four hours each. Using the numbers from the table above, this would mean the manual migration of the press releases is 5,000 * 1 hour = 5,000 hours and the effort for the articles would be 8,000 * 4 hours = 32,000 hours. This probably is more manual effort than you're willing to take, so you probably would cycle through Step 1 to see what other assumptions you might be able to change (for instance quality).

Let's say after your do your further analysis, you think a larger percentage of your content can be automatically migrated. Well, until the rubber hits the road, you won't really know if those assumptions are true. At this point, you should pilot an actual migration of a section of the site. Then you can actually see how much can be migrated and, by doing a sampling, you can discover how good the migration quality is (and potentially cycle through iterations to improve quality).

Step 3. Re-assess based on your pilot, and migrate

After the pilot it complete, it's time to re-assess where you're at. Did the automation yield the quality you were expecting? Are there ways of improving the quality through the automation rules? Are you going to need to jettison more content, or lesson the quality? You may decide that you need to do manual QA on a certain sampling of the automation on some content types, to confirm that the quality is working out over a large batch of content (this may also vary based on content type). See Why estimate? I'm not getting more resources for this site migration.

In sum, this is the overall process of migrating content:

After you have done the pilot and re-assessed, you should:

• Have a good estimate of the effort it will take
• Get a flavor for the types of issues you will be encountering
• Have a way of breaking down the problem for the actual migration.

Also see the previous entry on ensuring quality during migration.

Be Careful!

This article jumps straight in the middle of migration planning, and assumes you've already taken care of other important planning, including:

• Defining a compelling vision
• Considered your content strategy
• You have already conducted a proof of concept on your CMS
• You aren't considering this a one-shot deal, but are looking at how to steward this content and the site over time

Remember that a migration is almost never just about content, but you need to consider relationships, teams, and tools. 

A final note: you may feel a bit of a deer in headlights with the issue of whether something can be automated or not. I've heard some interesting excuses from systems integrators / development shops about why something cannot be automated, which may sound like valid reasons to you. Hopefully by conducting your pilots and estimates, you will have compelling reasons to automate as much as possible. As mentioned above, it can be a bit more art than science in seeing patterns and being able to apply them, and it certainly should go beyond throwing a tool like HTMLtidy at the problem.

This blog concentrates on web site implementation success, and I try to take a holistic view of that. Of course, we all have our biases, and my technical background probably comes through pretty strongly at times. That said, my primary concern is making sure that web sites get implemented well. In order to do so, I get inspiration from folks in various disciplines. For this blog post, I thought I would concentrate on some people in specialties that probably do not get enough focus:

• Content Strategy: Kristina Halvorson (@khalvorson) of Brain Traffic and Jeff Macintyre (@jeffmacintyre) of Predicate are folks to watch on content strategy, which Kristina defines as "the practice of planning for content creation, delivery, and governance" (from the Content Strategy knol). Check out Kristina's book Content Strategy for the Web.
• Product management: Scott Sehlhorst (@sehlhorst) writes the insightful Tyner Blain blog about product management in general, which I think is an area that does not get enough attention for web site management. Some recent favorite posts of mine are Product Manage Your Website and Modeling User Competency.
• Design, with a focus of successful ongoing management: Paul Boag (@boagworld) comes at the problem of running large sites from a designer's background. See the Boagworld blog as well as the Website Owner's Manual. A recent favorite post is 10 Problems Your Content Management System Will Not Solve And How To Overcome Them.
• Web Operations Management: Lisa Welchman (@lwelchman) of WelchmanPierpoint defined Web Operations Management, which "takes Web management out of the arena of daily management, mini-projects, and silo'd technology implementations and moves it into the more mature operations arena".

Of course, I missed many others in the above and related fields, but I wanted to highlight some of the key related fields and some of the folks behind them.

Are there others we should be watching when trying to implement successful web sites?

Tools get too much focus. I guess it's natural, and I also fall for the allure of a good tool discussion. But we should get a bit real on our spotlight on tools, and concentrate on what it takes to successfully implement or migrate a web site. I've written about how to migrate before, but not tried to describe the success factors in priority order. So what are the keys, in priority order, of a successful implementation?

Let's take the example of photography. Go to photography forums, and the discussions are about cameras, just like most of the discussions around web sites are tools ("Do you prefer Drupal or Joomla?"), or maybe the end result ("I love the new CNN redesign"). In photography, successful photos probably rely on something like the following, in priority order: 1) vision of the photographer, 2) timing and lighting, 3) format (medium format digital, 35mm digital, mobile phone camera), 4) support (tripod, steady hands, holding camera out the window of a moving car), 5) lens, and somewhere way far down in the list is the actual camera. Of course, it's not as much fun or sexy to talk about it this way, but the first items in the list are more important. Give an excellent photographer a pinhole camera with perfect pre-dawn glow, and you'll wind up with a better photo than a two year old in harsh noon lighting with the "best" camera on the planet.

So, what are the keys to a successful web site then? Here's my stab at the answer, in priority order:

1. Vision

Before implementing a site, you need a strong, widely communicated vision of why you are going through the effort. Otherwise, your whole endeavor could be misguided or just lack the direction needed to keep the whole project moving forward.

2. Support (the "tripod")

Can you actually implement and then maintain this thing? Do you have the governance, processes, and teams in place? During and in preparation for the migration, you need to train the relevant teams. Are you following a sound process for your implementation?

3. Product Management (the "lens")

You might have the vision and staff in place, but in practice during implementation (and on an ongoing basis), there are lots of seemingly-small details that need to be worked through that affect the overall quality. Note that this is not only about project management of delivering to originally-defined scope, but the continuous tweaks that need to be determined as the project goes forward. For an infrastructure product like a CMS, the tool must also be managed architecturally to ensure it is sustainable. Strong product management also means being able to clearly define the essential requirements, and concentrating on defining your requirements will also naturally help you in selecting your technology as well. See more on product management.

4. Class of tool (the "format")

You aren't going to build Amazon.com on Wordpress. If you need to build a website in the next hour, you're not going to build a new infrastructure from scratch but might use Drupal. More important than the specific tool is probably making sure you're in the right ballpark with the type of tool you are using.

5. The exact tool (the "camera")

I would suggest that the exact tool is not as important as the items above. That said, if you have strong product management clearly defining what needs to happen to meet the vision (and the processes to make this happen), then you'll more likely wind up with a strong tool. Another point: in the choice of whether to change tools or not, it's probably more important to first make sure you expend effort in the higher-priority areas. Of course, any of the above issues could derail a project, but I would argue that you can recover from the "wrong" tool if you are at least using the right class of tool. But you can't recover from a poor vision and improper support.

What do you think the priorities are for implementing a successful web site?