Don’t Forget the Bytes – Cautionary Advice from Deane Barker
Here’s something that content migration projects often seem to forget: at some point, you’ve gotta move the bytes.
Migration projects are an interesting mix of process, governance, political maneuvering, and strategy. You have a bunch of content in System A, and you have to get it to System B. In the process of doing this, you have to figure out what is going from A to B, deal with all the political machinations involved with dropping old content, figure out how the old content is going to work in the old system, then develop a project plan to manage the entire migration process.
Oh, and also, the actual bytes of content – the one and zeros on disk – have to move from one system to another.
This is the part that often gets forgotten or underestimated. In the back of people’s minds, I’m guessing they think one of a couple of things:
- “There’s just an import and export, right?”
- “We’ll get interns to copy-and-paste it all over.”
- “I’m sure we can just go direct to the database and pull it out with SQL.”
In some cases, these solutions might be right. In most cases, they won’t.
What we find in a lot of migration projects is that the process-oriented aspects are taken care of, but the technical aspects – of which there are many – are ignored until it’s too late. Deep into the project process, a developer is brought in to figure out how the content is going to move and it becomes obvious that it’s a lot more complicated than anyone though.
Example –
How will you determine context or placement? You have 1,000 pages in System A with a menuing system and renders all your navigation. Well, System B doesn’t work like that. In System B, there is no menuing system, and instead there’s a hierarchy of pages, from which the navigation is drawn automatically.
So, from System A you now have to extract both the content, and also the placement, or geography, of the content. Can you do this? Well, okay, we’ll pull all the menus and use them to form the page structure – this will be easy.
But, wait a minute, Page X appears in three different menus in System A. But in System B it can only appear once in the tree. How do we manage this?
And, so it goes. In the average migration project, this will be one problem among dozens you’ll have to deal with. Unless you’re moving content between two systems that manage and architect their content in much the same way, I promise you that there will be translation problems coming across.
The only way to get out in front of these problems is to run a pilot project early. Take a subset of content and migrate it, no matter how early in the process it is, and even if you have to alter your development project plan to deliver a prototype of the finished site earlier than planned so you have something to migrate content into.
Remember, at some point, bytes on disk will have to move from one system to another. This is the inconvenient truth that gets ignored in too many cases. Do yourself a favor and stare it in the face early, and your chances of a positive outcome go up considerably.