Oftentimes, a Content Management System selection is part of a large-scale site migration or redesign. When a new CMS is involved, you will want to make sure to put the CMS through a proof of concept, which should be part of your CMS selection process. A migration or redesign should include these three steps if you are using a new CMS. This table highlights the differences between a proof of concept, pilot, and full migration:

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, 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 content/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.

If you're going to do a large web site redesign or migration, you are probably already planning on conducting a pilot. One natural approach is basically to consider the first site/section you migrate as the pilot, but not take the time to respond to issues uncovered during the migration (which would reduce acceptance of the project). There are other easy traps to fall into, so what does it take to do a strong pilot?

1. Flex Important Muscles

A web site isn't just a pile of pages, but includes content, tools, configuration, relationships, account management, reporting, people and processes (see description). So you should not consider your pilot just a test of some pages, any of which on your site could be piloted as well as any other. What is to piloted or not piloted is a key decision, and may or may not mean piloting lots of pages. The steps to decide should be:

1. Define the compelling vision for your redesign,
2. Decide which components of your site are key to your vision,
3. Pilot the highest-risk or most important items.

Note that this usually does not mean piloting the easiest pages, or just trying to plow through a lot of pages to show progress (see more on tracking progress).

Since on of the purposes of a pilot is to discover issues as early as possible, so you can either reset expectations or put in more resources, you want to pilot the parts that are most important to your effort. Otherwise, you will think your pilot was a success only to have a train wreck later.

2. Launch Actual, Live Site

The best pilot will be one that results in a site that real-live web site visitors can actually use. Not only will you get feedback from the most important stakeholders of your site, but many other production-only issues will be more obvious. Examples will be load/caching issues, url redirection, and usage of your site that you were unaware of. But, even more important: you will be forced to work through all the issues to launch a site, rather than just having a couple people publish a few pages and declare the pilot complete.

3. Reserve Time to Respond to Issues

If you have a schedule that goes straight from pilot to mass migration, then the pilot won't be of much use since you won't have time to respond to issues you uncover. You need a step where you regroup and respond to issues found during the pilot.

Ideally, you will have the time to:

1. Define with key stakeholders what needs to be changed/fixed before the full redesign or migration occurs
2. Implement all those items that were agreed-upon with stakeholders prior to the full-blown migration

What the Pilot Will Do

The successful pilot should then allow you to:

• Better estimate how long the actual migration or redesign will happen (see "why estimate")
• Tweak the system, approach, expectations, and training
• Enhance buy-in
• Avoid some major roadblocks

So you want big changes on your site. Should you stick with your current system to accomplish this, perhaps doing a simple redesign, or is it time to migrate to another system? This is such an important decision, but easy to just fall into one of two camps: "our tool stinks and a new one would solve our problems" or "we couldn't possibly move." So how do you go about making the decision? Two steps can help you decide:

1. Inventory what you already have (and not just a content inventory).
2. Rationally review the situation for each item in your inventory, and then decide if the advantages/costs of staying outweigh the pros/resources of migrating or not.

What is a site?

What – exactly – is a site? If we're talking about whether to move or not, what are we talking about moving anyway? First, the obvious two parts of any site:

• Content, which is either managed or unmanaged.
• Tools, which could include anything from a highly automated CMS implementation, to someone using a text editor and ftp client.

You will also have some/all of these:

• Configuration
• • Templates that drive how pages are consistently generated (chances are, these are not implemented in a way that's a simple copy-and-paste). For example, on the Hobbs On Tech blog, all the blog entries are generated from the same template of the CMS, but moving the templates to another system would not be 15 minutes of work.
  • Special functionality, including how search is configured or how page urls are handled.
  • Platform / implementation architecture. You may or may not have a platform that helps, behind the scenes, in ensuring quality of your site.
• Relationships
• • Metadata. Metadata is becoming more and more important to driving how pages work, and an important element of any decision of how to modify a site.
  • Structured content. You may have something like a "book" content that has chapters, or some other content that has components that are highly related. Regardless of the technology, the relationship between the components (for example chapters and books) would have to be maintained in a migration, or might be very difficult to maintain in your existing system.
  • Links. Links within your current site and with partners need to be carefully considered, so that you don't break links or inadvertently end up with duplicate content in a redesign or migration.
  • Integration with other existing systems, both to and from. This can include generic interfaces such as RSS and XML, as well as highly customized interfaces internally or with partners.
• Account management
• Reporting
• • Self-inspection, including how many content items are in the repository and ability to easily find and edit content.
  • Analytics, including passing key metadata to analytics packages / services.
• People and Processes (not the "account" above, but real live people used to supporting and trained on your system)
• • Publishing interfaces, including workflow.
  • Existing training and support programs.

Obviously the different components could be sliced and diced differently, and complex sites will probably have other concerns. That said, the basic message is to consider all aspects of your existing (and desired) site when deciding whether to migrate to a new system or not.

The Inventory

To do an effective inventory, you will first need to define your compelling vision of what you want your site to be. After you have that, for each of the components of your site (using the above list as a start), rate each according to the following:

• For the completely as-is case, with no changes, how well is the current site supporting the Compelling Vision? Perhaps you leave the effort baselined as 0 for this case. Obviously, one of the items you may be after is reducing the ongoing cost of running the site, which perhaps you can capture in the People and Processes section (or you may decide to create a separate sheet to decide analyze the ongoing costs).
• Another possibility may be to tweak the current system toward satisfying the Compelling Vision. In this case, rate both how close each component will be to meeting the vision, and also how much effort it will take to get there.
• Repeat the ratings of how close the system would be to where you want, along with how difficult it will be to get there.

Even if you just spend an hour on this exercise, hopefully you will have a clearer picture of your situation. Here's an example spreadsheet (with 5 being the best/difficult, and 0 being the worst/easiest that's been started for a hypothetical site:

The Decision

This will almost certainly be iterative. For example, you may look at your original analysis and decide that maybe there is an easier way to improve the metadata in your current system toward your strategic goals. Or after going through the exercise once, you may realize that there would be content repercussions that you didn't anticipate until you thought through the analytics requirements. At any rate, to help you make a decision you can see how difficult each possible approach would be, and weight that against how strong you anticipate the end solution to be. In addition, you will have some documentation of how you came to your decision. You can also use this sheet as a reality check when you conduct a pilot of your approach. For example, if you see that modifying the templates in your current system during pilot is far harder than you anticipated, you can revise your estimates and perhaps re-evaluate your initial decision.

Related posts

You may also be interested in these blog posts:

• Why It's Hard to Migrate Content
• "Just like current system"
• Compelling Vision for a Large CMS Migration
• The Web Diet: How to Simplify Your Web Site

How do you staff a large web site migration? In this blog post I'll review some of the roles needed in a migration. Remember, much of these suggestions are for a relatively large migration (and some of these roles may be ridiculous for small migrations). Also, there are many elements to planning a migration (see checklist), but I'll focus on staffing here. Note that the compelling vision is particularly important when talking about staffing, to make sure that you're aligning and motivating everyone.

Balancing Complexity and People

First, let's revisit the fact that there really is an interplay between the complexity (along with size) and the people required for the migration. This may seem obvious, but you often have a choice between putting your web site on a diet and the general resources needed. The focus of this blog post is on people, so just keep in mind that if some of these roles seem ridiculous then perhaps you just need to confirm that the complexity you are attempting is possible with the people you have on hand (as opposed to, as the diagram at right is showing, having more complexity than can be supported by the team).

Roles You'll Need

Here I'll concentrate on the staffing required for the migration itself, rather than the overall web team required for continuing to run the web as an ongoing undertaking (the migration is just a step in the long life of your web site). In general the migration will be a burst of effort, where people are brought in temporarily, but it is essential to keep the team needed for the ongoing support as well.

Also, I'll assume that the content strategists, information architects, (graphic) designers, taxonomist, system architects, and other people involved in the definition of the project have already defined what needs to be defined. Of course, they will still need to be available for issues that arise during the migration, but I'll assume that the overall structure has already been defined and it's time to get migrating. The policies and standards should have also been defined by the policies and standards teams so that the migration will occur consistently.

Note that the roles below are roles and not necessarily individuals. In other words, you might have one person playing multiple roles depending on the size of your migration. In addition, some of the roles below might not even be necessary for your migration.

Internal CMS Product Manager

You'll need someone to be managing the configuration / implementation of your CMS, and I would argue that you should have someone "internal" doing this (rather than, for example, you systems integrator). This product manager works with the various teams to ensure a high quality implementation and defines the product. One of the most tangible and high profile tasks they'll undertake is owning the feature request process. The best source for more information on this is this article on Internal CMS Product Management.

Liaisons and Coordinators

For very large projects, coordinating across large organizations, you need to think about how two-way communications will occur between the core infrastructure implementation team and the various units within your organization. For example, if you run a worldwide corporation, then there may be five different regions to work with and hundreds of users of the CMS. Obviously you're not going to have all the stake holders communicating directly with the developers. In a large organization, you could consider a model like this:

This type of model may seem (and be) overkill for your particular organization, but when you start having a hundred-plus people who will be involved in the migration, you may need:

• Liaisons on the technical team, who know the technology and can hand-hold the business users on how to get the system to do what they need it to do. Also, they can help work with the business users to understand any special requirements they may have.
• The business liaisons help prioritize all the requests and general issues that their business users are having in order to make sure that the most important items are getting taken care of.

Content Specialists

A site migration / revamp is usually an important time to improve the content. There's a good chance it is also necessary. For example, if you never had topics-based pages and are adding them now, then you'll probably need new content. Here I'll just list the different roles:

• Content Publishers. These are the folks that do the initial migration of content from the old system to the new (if it is not automated), and, depending on the tools and what you are trying to accomplish, doing HTML modifications/transformations or tagging. This role in particular may need to burst during the migration.
• Editors / Writers. Some content may largely be cut and pasted, in a fairly mechanical fashion. Other content needs to be written. Obviously, you need access to writers/editors for the web to do this work.
• Subject Matter Experts. During the migration, depending on what you are trying to accomplish, you will need access to your content subject matter experts. If your site is about the nuances of tax law, then you'll need access to your tax law experts.

Other roles

Some other roles need less description, although they are no less important. You should make sure to reflect on whether you need these roles in your migration:

• Project Manager. Although the CMS Product Manager may play this role, you may need to have a separate person looking specifically at keeping the project moving forward according to schedule and budget.
• Developers. Who exactly you need depends on what you're trying to accomplish and the tool you have, but you'll need developers (whether in-house or outsourced) for configuration/implementation of large sites.
• Help Desk. Unless the business liaisons can handle the various issues the CMS users raise, you will need to involve your helpdesk. The helpdesk may end up passing a large volume of the requests to the liaisons at the beginning until the patterns of requests are understood (and the helpdesk has the knowledge needed).
• Trainers. All the users need to be trained on how to use their system (for their particular task).
• Executive Sponsor. Someone high up in the food chain sponsoring the migration. In particular, they need to articulate the compelling vision of the migration.

Which do you need?

I've put a little spreadsheet together to help you keep track of which roles you already have, which you need, and which you won't need:

As always, I appreciate any comments you might have.