Content Migration: Making It Successful
1/17/2006
I’d like to talk for a moment about what I call the Content Migration Fantasy. In this fantasy, an experienced team lead by a tough-yet-wise project manager ports legacy content to a new system. This being a fantasy, the work is done quickly and efficiently, due, in no small part, to a brilliantly executed content inventory and information architecture. In this fantasy, not only do the items that should be moved end up in the right place, but the items that shouldn’t be moved stay right where they are.
And, of course, the migration phase of the project comes in on time and under budget. No, better, it’s done early and under budget. The content migration team is celebrating at the local pub while other teams are sweating deadlines.
In the real world, we all go into content migrations with high hopes and solid plans. Depending on the size of the site and the culture of the organization, you can expect delays, misunderstandings, and more than one last-minute “uh oh”. There is a lot of good advice relating to managing the migration portion of a CMS project, and I’ve linked to some favorites below. In the meantime, here’s my short strategic plan:
- Finish your content inventory. By finish, I mean identify every piece of content on the existing site and new content. If the letters TBD appear anywhere on your worksheet, you’re not done.
- Identify where the content goes. Specifically. Exactly. When you get to item 507 on your inventory, you should know exactly where it will slot into your new site.
-
Gather all the content. Sure, locating the content on the existing website will be easy, but what about the new items? Knowing they’re in Jim’s drawer or on Rex’s hard drive is all very well and good, but you want physical and/or virtual possession of every item to be migrated before you start work. This will eliminate the need to create “Waiting For” placeholders — these tend to be overlooked in the final rush to launch a site.
Before you add a single item, you need the following ready to go:
- Content From The Current Site – I prefer not to work on a live site because it seems like servers die just when you need them most, so I like to work from a copy of the site.
-
Electronic Files
– Sounds easy enough, but you need content in a readable format. Plain text is good, but more likely than not you’ll get documents in Word or other standard formats. A word of advice: if the electronic file cannot be read by a modern machine (and hasn’t been accessed by your client’s staff this century), chances are it shouldn’t be migrated to the new website. This might be a great chance to update obsolete items.
-
Hard Copy
– Yes, by hard copy, I mean paper, generally of the 8 1/2″ by 11″ size, but I’ve been surprised by stranger sizes more than once. As with documents created with obsolete software, there’s an excellent chance that items available in hard copy only are due for major refreshing.
At the very least, you need to factor content conversion into your budget and workplan.
-
Ghost Content
– This is content that should be on the new website, but doesn’t yet exist. This is where hard deadlines and good judgment are helpful. You don’t want to build your new site around items that don’t exist, but popping a letter from the president in at the last minute probably won’t be a deal-breaker. If you haven’t received To-Be-Created items by your set deadline, it’s time for a serious talk with your client.
- Practice content triage. Prioritize your migration plan. My approach is pretty simple, yours may vary, depending on the project:
-
Top-Level Content
– This generally means entry pages to major sections, content deemed by the organization to be “critical”, and policy documents. If someone says the site’s launch has been moved up, you’ll know that the top levels have been built out with no broken links.
-
Secondary Content
– This deeper content should not be launch-critical, but still needs to be migrated. This is generally current content or content accessed on a regular basis.
-
Archives/Tertiary Content
– Large websites tend to have troves of “archives”. Government agencies, for example, tend to keep archives of old minutes and agendas as online public records. While it may be determined that meetings from 1999 don’t need to be migrated, chances are that there will be some infrequently accessed content. This goes last as budget priorities may dictate a slower migration pace (or the client may decide to do this work as time permits).
-
- Focus on the migration. I like to do content migration without any other business distractions. This is the first time I’m really “touching” the content, and despite the best efforts and most assiduous inventory practices, things slip through. This is my chance to make sure everything is perfect. The art of content migration doesn’t allow me to do detailed proofreading or rewriting (meaning I have to curb my natural instincts), but I do know that titles are spelled correctly, leads form complete, readable sentences, and nothing is duplicated.
You may be working in isolation or you may be working with a team of content migrators — these key steps apply in either case. I like to have the migration done early enough to accommodate last-second tweaks and mind-changing. Many of our clients require daily site updates, so planning for a final content load is also something we factor into the launch schedule.
Content migration is a big part of any successful CMS implementation — with a good strategy and careful planning, it can also be the most painless.