The question is simple: “How to say goodbye to your migration tool?”, the answer could be diverse. Dump it in the trashcan, store it in a safe, pay its bill, but my favorite one is: “with a handshake”. Now some of you might wonder what I’m rambling about, so let me explain myself.
To start of, many customers have asked me in the past to build them a content migration tool. Initially I always answered that question with another question: “Are you sure you need it and are you aware of its costs?”. Mostly the answer from them was: “Yes we see this as the best solution”, and so I started creating yet another migration tool. Being a developer I’ve always been intrigued by modular concepts and reusable tools, however that never seemed to work for the migration tools I, or my colleagues have build. They were always too specific for their task and could never really be reused in another project. Sure there are companies out there that offer migration services with automated tools, but even those need a little tweaking for every job, and the outcome is depending on the quality of its input.
A couple of months ago I started a new project (building the new sdl.com website), the customer (our marketing and communication department) was well willing to listen to my advice. When the topic of content migration came up, I advised against it of course. We were going to build a complete new website with a new content structure and a real BluePrint. None of the existing content would fit the new model, and building a migration tool would be very complex with a limited rate of success. As we all know, when you get low quality input (no matter how good of a developer you are) you can not build a tool that will give you high quality output. For a content migration tool this just means that you need to run and adjust the tool multiple times during the project, and in the end you still have to manually correct some (if not all) of the content. So we started without migration plans, all content needed to be rewritten, and before launch we would have a content creation phase.
It wasn’t long when the topic of our blogs came up, and then the press releases, etc. etc. and of course you can guess, they asked for a migration tool again. This content didn’t need to be rewritten, the content editors didn’t have time to manually copy all the archived press releases. It was time for me to come up with a plan for some content migration after all.
Now that we are nearing the end of our project, I can tell you that the content migration was painless. Before the content creation phase is even finished, we could already say goodbye to our “migration tool”. So how did I say goodbye? With a handshake of course… (by the way, her name was Anouk and she had blond hair). Okay I can’t say I build this “tool” (that was done by her mother and father 21 years ago ;o), but she was the best migration tool I had ever worked with. No matter how low the quality of input was, the output was always of high quality. Spelling mistakes were corrected during migration and links were checked for their existence and relevance. It was a pleasure to check her work, and when she was done early she came asking for more work all by herself.
From experience I can now tell you, there is no better way to migrate content than to do it manually. When you hire so called cheap labor (college students, etc.) it will cost you less and give you a higher rate of success. Plus, who wouldn’t prefer a blond 21 year old sitting across from you, over an old crappy computer which is blowing dust and burning cpu cycles?
Very recognizable. Although sometimes it can still be good to do a technical migration as well, just make sure you really manage customer expectations. especially when it comes to texts with many dependencies and rich text images, etc…
But, one many occasions we have been able to migrate manually as well (no Blond 21 year old, though
Well told, I should have seen it, but did not see that coming.
Scale matters as well–manual creation for 5,000 components might take a few weeks which would be comparable to an import script project. It’s quick to update a few hundred components than it is to hire a resource. And hopefully large projects have enough structure to be importable.
I agree with Hendrik on dependencies and issues with highly dependent (or unstructured) rich text. It’s challenging to capture logic on changing content types into templates, schema, and metadata especially with hand-crafted “artisan” content types.
Software programs can only do so much in terms of pattern recognition. (just ask physicist Michio Kaku http://bigthink.com/ideas/39768 [includes a video]).
Great story Bart. I subscribe to this approach 100%. Your comment about low quality input and high quality output really hit the spot for me. I imagine a low fidelity video trying to be converted into a high fidelity one. I think that’s only possible in James Bond movies and shows like CSI where they say the word “enhance” and the picture magically becomes clear.
Verbal commands would be too easy. Don’t they create GUI interfaces with Visual Basic? http://youtu.be/hkDD03yeLnU