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
Hi Bart, thanks for the provocative post.
You are right that a manual migration provides a great opportunity to improve your content. Still, an automated migration doesn’t imply no improvement at all. There are ways to “enhance” content through metadata enrichtment, for example.
In my experience, when choosing between manual or automated, a lot depends on how many pages we are talking about. How big is your new and improved website?
Also consider, with a manual migration you will need a “content freeze” (or maintain the same content in several places). Many businesses cannot afford their website to ‘stand still’ for longer than a day. How did that work for your company?
In the end, a hybrid option can also work very well. Automate what is best done by machines, to leave more room for improvement by hand. And don’t forget: an important human part of automated migration is telling the machine what to do 😉
@Bas, to reduce the content freeze you can simply hire more people, just like you would upscale a migration tool. But also maintaining the content in two places is something worth considering, it basically all depends on the exact requirements. I don’t agree that size is something which changes these parameters, automated migration might seem cheaper on large volumes (certainly when you have a proven and well developed tool and not something which is a one off custom build), but still there is no automated tool that can fix content like a human interaction can. So agreed when the input content is clean, fault free, and ready for its destination, then maybe it can prove to be more cost effective.
Hybrid solutions are certainly possible yes, but there it also still comes down to how well suited is the original content for its destination. You mention to “enhance†content through metadata enrichment, that does require you to have this metadata available somewhere. The simple thing of a link to something which doesn’t exist anymore, a tool can at most remove the link or flag it for manual action, while the manual process can directly start looking for the new link.
My main point is, automation often only seems faster and comes at a price (certainly taking into account the hours of manual labor to investigate, plan, tune, test and validate your automated process).
Thanks for your reply, Bart. I see that you’re not easily convinced 😉
There’s one important misconception I’d like to challenge: at Xillio we can add missing metadata by analyzing the content and the context. So even when you don’t have metadata available yet, there are ways to add them. (We don’t use one-off systems, but software which we have been working on for years.)
Which is what gives an automated migration added value: you shouldn’t just use the machinery to get from A to B; you try to make B better. Same as you’re doing by hiring a good copywriter, we can do in your content management system. And at a large scale.
The ROI of automation doesn’t depend on the volume of content as much as it depends on the number of different migrations to support; having 10000 pages doesn’t automatically make a project “more suited” to automatic migration than having 1000 pages; worst case scenario every “migrateable type” covers only a few pages which is often the case due to years of code quality neglect on the template side (recently have been in a situation where a single content type could result in over 10 different kinds of output depending on the configuration of fields in the component; this makes for >10 migration types and not one).
Automation only makes sense if you are going to do it very often (or you cannot recover from doing it wrong).