Why people don't really plan website migrations
Guest post by David Hobbs
Let's face it: Most organizations don't really plan their website migrations. This dramatically increases the risk of a train wreck, since any problems (many of which should have been anticipated) come so late in the process that it greatly disrupts the project. Let's look at some of the reasons that folks use to avoid planning, and why these are bad reasons:
Our integrator or internal technical team said this would be easy. It's true that sometimes migrations are easy. That said, the technical team often takes a very narrow view of what a migration is, and the non-technical folks end up having to close the gap. So by looking at the steps of content being handled (the actual movement being only one) and the expected quality level, you can make sure not to have the migration "done" and yet face a large amount of work.
The migration will be painful, and there's no reason to think about it until we have to. By searching for patterns and discussing expected quality level, you may be able to make it less painful. But even if it will be just as painful as you fear, not planning for that reason overlooks another important reason for planning: getting everyone on the same page. Without this, your project could get derailed when stakeholders are not seeing the results they expected.
I have a tight budget so we just have to make do. If you have a tight budget, then at least you should estimate the manual effort and discuss the expected quality level of the migrated content. If you find out you don't think you can make the expected quality level with the available resources, then perhaps you can get 80 percent there by phasing the project, dropping more content, or moving in at lower quality.
We have interns. Even if you plan on throwing people at the problem, you will need a plan of how to coordinate everyone. Also, even if you have interns then you need to figure out who is going to QA the entire process.
We have a tool that will make this easy. A tool may make the migration easy. That depends on the migration needs, and in particular if the tool can handle every step (Sort, Place, Edit, Move / Transform, Enhance, and QA) of the content handling process for your needs. In many cases you need people in many of these steps, for instance if editorially (not HTML-wise) some of the content needs to change.
This is complicated and has to be manual, so what's the point in planning. Usually a migration can be reframed in terms of patterns or phases, and even if it does have to be manual, the problem can be broken down and executed more effectively. Moreover, it may be possible for large swaths of content to be automated once looked at carefully.
We're not going to migrate anything. I recently heard this from the manager of a major megasite, and sometimes this means that the technical team won't be supporting the migration. But this type of statement is overly dismissive because for any significant website undergoing a transformation, some content will need to move by some means. If the central team won't be doing any of the migration, then perhaps there's an even greater issue: how to coordinate a distributed team in making the migration happen.
We really need to figure out the design, IA, technology (or whatever the current pain point or team bias is). Often there is a very direct migration impact on design or other discussions. For example, I have been involved in many IA discussions where the simple "where's that information coming from?" question can spawn a useful migration question. But even aside from clear issues like the mere existence of information, your design will be impacted by the quality of the migrated content.
Do you have any other reasons I haven't heard to not plan your migration? I'd love to hear them.
David Hobbs recently published version 2 of the Website Migration Handbook, a practical guide to planning a website transformation. His company, David Hobbs Consulting helps clients get control of their website transformations, from strategy through implementation oversight. One aspect he looks at with clients is the content handling process, which is more than just the movement of the content. Some of David's recent clients include the Centers for Disease Control and Prevention, the World Bank, Thomson Reuters, BIO, the MBC Group and Realtree.com.