Web Site Migration, Implementation, or Redesign in Five Steps

I've been doing a lot of thinking about migrating Content Management Systems recently, with some of this thinking up on the Hobbs On Tech blog. In talking with practitioners, I realize that much of what I've been writing actually isn't CMS-specific and isn't migration-specific but probably relevant to large content technology implementations, whether it is an initial implementation, redesign, or migration to a new system. That said, in this article, I'll continue to concentrate on CMS migration, trying to bring together an approach to migration in a coherent whole. In fact, I have started to write an e-book on CMS migration [update: buy version 2 or download the original version for $0], so would appreciate you pointing out any areas that should be covered to be useful in a migration handbook.

A strong process for a CMS migration doesn't just look at one dimension (for example, just design), but looks at the relationships, team, tools, and pages that truly make a large site happen. The first section of this article covers these, and then the steps of a migration are covered:

It's not just the design, or just the content, or just technology....

Sometimes, a site redesign really is just that, meaning some templates or CSS changes and that's it. Or it really is just migrating content into a new system. Let's face it: that's rare, except for small or relatively new sites.

One way of looking at this is that the Compelling Vision defines why you are doing the redesign/migration, the pages define what you want, the relationships are a blend of what you want and how you will accomplish it, and the people and tools are all about how you will accomplish it.

Below I'll start with things that might not get planned for (at least sufficiently) during a migration effort. All of the components are related (for instance, good metadata probably means good training for people), but it's probably a good idea to isolate each of these to make sure they are covered.

Relationships

By relationships here I mean metadata, structured content, links, and integration with other systems (for example social media and public repositories of information, but also your partner sites) -- basically how your content lives in the site and world. These things aren't plug-and-play in any system, because they are always unique to your organization. For metadata, there is defining the metadata, setting up the tools to support your metadata, training on metadata (both how to use the tool and how to tag effectively), and possibly writing guides on how to use metadata. The reason that metadata and other relationships are becoming more and more important is that your content is appearing automatically in more contexts, both on your site (slicing and dicing by topic for example) as well as off your site. Designing for these relationships is more subtle than may be obvious (for instance, false precision and taxonomy mappings). The point here is that you need to plan for all of these relationships so that you do not box yourself into an implementation that cannot allow the functionality you need.

Team

Your site visitors need to be considered in a redesign (see Jakob Neilson's Fresh vs. Familiar: How Aggressively to Redesign), but here I concentrate on other important people: the team that will implement and maintain your new system. There are two parts to making sure your team will be ready: a) having the right people (and availability of those people), and b) communicating /training these folks. See Staffing a Team for Large Web Site Migration and Training During CMS Migration for more.

Tools

Many casual conversations about technology amount to name-dropping ("I just installed FlamingoDogCMS at home last night, and it's much better than the system we use"). People have strong opinions about technology, but hopefully you can steer toward substantive requirements that drive your technology (see Where's the juice in your requirements?). In the case of strongly content-driven sites, you need someone who has experience to help steer clear of potential issues in these technologies specifically (for example around automatic pulls and content re-use). See Should I Stay or Should I Go for more details on the configuration, templates, and special functionality that you should make sure to plan for.

Pages

The Page receives perhaps the most attention, since it is in everyone's face and also very concrete to discuss. User interface, information architecture, content strategy and design are discussed in detail elsewhere. These are all crucial aspects and need to be defined for your project, but please make sure to dig into enough details to figure out how to deliver the desired pages.

Also, note that even the technical migration isn't just about pages (see Why It's Hard to Migrate Content).

Migration in Five Steps

Note that I didn't say five easy steps :-). That said, projects may focus on just certain phases (especially ignoring the pilot or maintenance), so listing out generic steps below may help in deciding whether you have addressed them sufficiently for your particular project.

1. Vision

You need a reason for going through the effort of a migration or redesign. The implementation probably will not be easy, so you need to define a compelling vision to align everyone and also remind everyone why you are doing this in the first place (see Compelling Vision for a Large CMS Migration).  Read more on Vision.

2. Plan

Your plan needs to consider all four components listed above, along with the next steps in the process: the pilot, implementation, and maintenance. Part of the planning is defining exactly what you are attempting to implement, but also more about how it will be accomplished. Obviously you will encounter unexpected issues, but hopefully the planning will help reduce those -- furthermore, by clearly planning you may be able to articulate what you are *not* doing as well (think about putting your web site on a diet).  Read more on Planning.

3. Pilot

The objective of a pilot is to better estimate how long the actual implementation will take, enhance buy-in, and give you time to tweak the system before proceeding to implementation. For more information, see The Pilot in a Site Redesign or Migration: A How-to Checklist.  Read more on Piloting.

4. Implement

At some point, someone declares "enough is enough, it's time to migrate". Sometimes you're ready, but usually it's just time to take the plunge. Hopefully you've been able to plan, pilot, and appropriately scope the project. In staffing a migration, you will want two particular roles filled for the actual implementation: project management to track through and push the implementation, as well as product management to maintain overall quality (and also to keep scope under control when issues arise). Note that during implementation the process for dealing with enhancement requests is crucial so that you don't end up building an unsustainable beast (see Be Ready: Initiating CMS Migration as well as CMS Implementation: Product or Project Manager?). You will also want to insure quality during migration, and decide how to track progress during migration (hint: it's not just about pages).  Read more on Implementation.

5. Maintain

Maintenance isn't part of the migration per se, but the migration would be a failure in my opinion if the implemented system cannot be maintained. What are some of the reasons that a site can't be maintained:

• Insufficient ongoing training
• Insufficient standards or buy-in around standards resulting in immediate degradation of coherence of site (see more on standards and web governance overall at WelchmanPierpoint). On the flip side, this can also occur if the technology is so rigid that people break out of the system to do everyday changes (see Standardization and Large Web Sites).
• Insufficient or inappropriate staffing levels (See migration staffing suggestions).
• No product management of the web site or CMS driving the web, so the toolset itself becomes difficult to maintain.
• Insufficient helpdesk support (see this little note on responding to urgent user issues)

Read more on maintenance.  

The migration plan needs to pull all this together

Do you have someone on your team who is committed to looking at all aspects, or are they really in one of the slivers above? If working with a systems integrator, are they looking at how to get to delivery or setting everything up for ongoing success of your site?

A typical (but not ideal) project might go something like this (in the graphic, darker boxes mean more emphasis: for instance, a typical project might have no visioning of the impact on people):

• The information architecture and design gets the most attention (with probably less attention on the content) in visioning and planning. Or, this could be flipped and if the technical team is running the show then the planning around the technology might get a lot of attention with little attention to IA/design.
• If there is a pilot at all, it probably focuses shallowly at a technical level rather than a comprehensive pilot. Or, there is a pilot but not enough time to react and make changes based on the findings from the pilot.
• Implementation just has to get done, but if all the components weren't planned, then items get jettisoned during implementation. The people impacts are probably only minimally considered (with everyone left wondering how their job will be impacted).
• Maintenance?

The point is that you want to be looking at your migration as a coherent whole rather than isolating one component or attempting to skip steps.

Please follow up with any comments including what you think is important to success in a migration or any particularly thorny issues you'd like more writing on. Please either put comments directly on the blog post or through Twitter at @jdavidhobbs.