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).
