Key Points:
Website migrations fail more often than people are willing to talk about. There are lots of types of train wrecks, but they include abandoned projects, stalled projects, or slowly grinding projects. Although these all feel different for the participants and have different results (for example, the stalled project, although perhaps significantly delayed, could still finish), why they occur has some common features.
Common features of content migration train wrecks
Here are some top reasons website migration projects turn into train wrecks. Although every migration is different, this issues are common enough that you should make sure to watch out for them.
1) Expectations mismatch
For most everyone, migrating content from one system to another is a rare occurrence. So this makes team members getting on the same page about the desired outcomes a challenge. Unfortunately, not sharing common expectations can mean that a train wreck is around the corner. For example, a common situation is for the technical team to say that the migration will be easy and for the site owners to just accept that at face value. Unfortunately, the site owners may expect things like the images to be resized while the technical team assumes the site owners will do this. The point isn't that one team is right and the other is wrong, but that not sharing a common understanding early in the process can mean train wrecks later. For example, in the case of the images if the site owners haven't set aside the resources to deal with the image resizing, and the technical team doesn't have the time to script it, then this would probably mean a stalled project since no one has the time to deal with it immediately.
2) Editors do not accept CMS
Sometimes editors just do not accept the CMS. This is a problem :-). In order to avoid this, editor needs should be part of the requirements in selecting and implementing the backend systems. Also, by phasing in changes you can ensure getting feedback as early as possible. Furthermore, you want to set up a strong process for taking everyone's input, which can spike when people start using the CMS in earnest.
3) Resources don't match desired quality
Often there just aren't enough resources to match the quality you're shooting for. Pair this with #1 above and this really gets complicated. Perhaps one of the most important secrets of migration planning is that quality is much more subtle than immediately obvious (and not just a "yes I want quality" or "no I don't care about quality" question). The problem is that usually organizations don't carefully think about quality, throw some people (or tools) at the migration at the last minute, and then just take whatever quality they get. This means you might implement what's easy rather than what is important. The solution is to plan out carefully both the quality levels you are attempting to achieve, and estimate the effort it will take to get there.
4) Cannot implement to plan
Whereas #1 above is when things get implemented in a way that the team was not expecting, sometimes everyone is expecting the same thing but the team can't seem to implement it. This often occurs when the plan was not reasonable in the first place, and so at a high level you want to think through how easy that shiny strategy of yours will be to implement. That said, one thing that always helps is to phase in changes. Not only does this mean that each step is easier to implement, but that the team also has the chance to react to what works at doesn't so that everyone isn't strapped to a long range plan that isn't working (or that folks did not understand). In addition, if you deploy your big project in this manner then you can set the stage for continuing changes in phases over time.
What to do about it
Fortunately, there's a lot you can do to avoid these problems. Mostly you avoid this by planning rather than letting migrations surprising you. We'll look at some effective means of mitigating against these risks below.
Phase
Although often difficult to get agreement on internally, phasing in changes to your website has many advantages. Some of these advantages were discussed in #4 above since this does help to achieve a plan that can be implemented. This actually also helps with #1 and #3 above as well since every can more concretely see results earlier.
Validate the plan
Implementing a plan takes coordination across a variety of disciplines, and it certainly isn't just technical. Operational, process, people, metadata, content, and many other factors are needed to pull off big website changes. Rather than jumping in to defining an impressive-looking Gantt chart, start by validating at a high level whether your plan or strategy can be implemented. For example, if your new plan requires a more extensive taxonomy, then who will manage the taxonomy and how will this be done in a high quality manner.
Estimate, with discussions about quality, early
One of the most effective things you can do in your planning is to do a wild estimate of the manual effort of your migration as early as possible. This should be done in conjunction with a discussion of the quality levels you are attempting to accomplish. Regardless of whether the estimate is accurate, you are sure to drive productive discussions. See Content Handling Process: Asking the Right Content Migration Questions for more.
Set clear vision for your website transformation
If you don't have a clear vision, then different stakeholders will expect different outcomes. Although a compelling vision isn't sufficient, it is necessary. The vision not only gets everyone aligned but also helps you prioritize and focus when, even with the best planning, issues arise. See Compelling Vision for a Large CMS Migration, as well as the Vision section in Website Migration Handbook (either v1 in PDF for free or v2 in multiple formats for purchase).
Include editor needs
Considering editor needs should happen in two steps: 1) considering editor needs during the CMS selection and 2) on an ongoing basis. To consider editor needs in the CMS selection process, these should be imbedded in the scenarios that you use to evaluate different candidates. On an ongoing basis, you should define your product management process to include editor input.
