Tackling website migrations: An interview with David Hobbs
Website migrations are one of the most misunderstood and underestimated parts of a CMS project. Thankfully we have David Hobbs to help demystify the process.
David is principle at David Hobbs Consulting, and a self described ‘Large Website Consultant’ helping clients get control of their website transformations, from strategy through implementation oversight.
I met David many Gilbanes ago and have been a loyal follower of his blog ever since. There are very few folks who cover the topic of website migrations with the detail and passion that David does. And by very few, I mean nobody else.
He recently published the second version of his Website Migration Handbook, which is essential reading in my opinion for anyone about to undertake a large-scale CMS project.
We caught up with David to delve into the topic of website migrations. The conversation covered so much ground, we’re publishing it in a two-part series.
Hi David, congratulations on the second version of the eBook. At 74 pages, this has to be the definitive resource on website migrations. You clearly have a passion for the topic. Where did that come from?
Thanks Jeff. Well, I definitely spend an unnatural amount of time thinking about website migrations. Being burnt myself is one of the reasons I’m interested in migrations. But perhaps the biggest reason I’m passionate on this is the huge gap out there. People seem to think of migrations (if they do at all) as a purely mechanical undertaking, and nothing could be further from the truth. Of course, sometimes migrations can sometimes be a purely technical undertaking. But even when there is a technical component there is usually much more outside of the mechanics. For instance, how do you align all the stakeholders behind the new system?
Another reason I think this stuff is interesting is that migrations are always at their core about finding (and creating) patterns. There’s always some order that can be applied to even the messiest situations. This can be very broad patterns like figuring out how a large number of sites are similar enough to be rolled out in a batch to the more detailed look at the texture of content.
Speaking of big undertakings, you mention megasites in the ebook. What’s the largest web content migration you’ve been a part of?
I like to think in terms of messiness, and not raw size like pagecount. Sometimes impressive-sounding numbers of pages can actually be fairly straightforward, for instance if they all follow the same template / rules / structure. Also, a relatively small site can have complexities that aren’t obvious to the site visitor. By a megasite, I mean a supersite that has lots of subsites. For instance, the World Bank had over a thousand subsites (one per country, etc) when I worked there. I’ve worked with several megasites with hundreds or more subsites and more than a hundred thousand content items.
I’ve always been a fan of your recommendation for a CMS Product Manager role. An internal owner responsible for the configuration, feature requests and overall CMS roadmap. What skills should an organization look for in assigning this role?
This is something I end up talking with organizations about a lot, but I haven’t written about much. I plan on changing this soon, and I couldn’t help myself focusing on this some in version 2 of the handbook since it’s so important (also see this short paper). Fundamentally, there needs to be a solid way of engaging with internal stakeholders about ongoing changes to the website. This need sometimes spikes right when a migration starts, when people start asking for all sorts of changes once they start using the system. Not having an effective way of dealing with this can result in Frankenstein’s monster. But moreover you’ve just got to have a way of talking with all the stakeholders while maintaining a high quality CMS implementation over time. Some organizations go out and talk with lots of people about what they want, but unbridled talking isn’t that helpful if no one is framing the purpose of the whole project. So the person playing the CMS product manager role has to have that rare blend of solid technical skills, solid business understanding, thick skin, and the ability to see through the chatter to understand and set the direction going forward.
My experience has been that organizations almost always underestimate (or ignore) the content migration effort. Any tips to help build the business case for doing it right in environments where budgets and resources are already tight?
By far my biggest recommendation, and one that I am doing earlier and earlier with clients now, is to estimate the manual effort. Especially with tight budgets and resources, it’s far better to discover potential problems earlier rather than later. But perhaps even more important is that this drives discussion about quality and the broader goals. I always challenge teams to consider both higher and lower levels of quality to see the impact on the effort required. To estimate, you want to batch the content into similar chunks (for instance, press releases) and then look at the steps of content handling in a migration to figure out how much time each step will take for each type of content. There’s a lot to this, but for starters check out Content Handling Process: Asking the Right Content Migration Questions.
We deal with a lot of myths on this blog. What’s the biggest myth when it comes to web content migration?
Aside from thinking that migrations are entirely technical, the biggest myth is that all web content migrations are the same! But migrations vary widely, even if we just look at the mechanical transformation. For instance, I encountered one very large intranet where a significant portion of the effort was going to be rewriting large swaths of content. Sometimes the site structure stays exactly the same but the componentization of pages changes significantly. Other times the main purpose of the migration is better slicing / dicing of content where the metadata has to be improved. In consolidation projects there are other concerns.
One way of looking at how hard a transformation will be is how much of a change will be evident to the site visitor (x axis) and the backend (y-axis) — here’s a graph from version 2 of the handbook:
Your readers may want to check out this list of questions to help think about where your migration fits.
Thanks for all the great information David. I’m sure folks will be checking out your Website Migration Handbook for even more nuggets. Stay tuned for part two of our discussion where we’ll get into the gory details of migration train wrecks.