Why Content Migration Is Like Changing A Nappy
On a night like this
I can’t get any sleep,
The air is so cold outside
And the snow’s so deep.
- ON A NIGHT LIKE THIS
Well, it just is. It’s something I’ve been thinking about a fair bit these days, normally in the middle of the night. I’ve been burned a couple of times recently by extremely unpleasant content migrations, and extremely unpleasant nappy changes. For those on the other side of the pond, a nappy is a diaper.
Some of the similarities are:
- The content is often extremely difficult to classify, and the consistency of the content is extremely variable
- Bad content never smells very good regardless of the quality of the repository you try to store it in
- Sometimes the state of the content is a symptom of some other illness
- You never have all the tools you need within easy reach, and it gets really messy if you don’t know what you are doing
- There is always more content than you thought was possible, and if the system is in a bad state, the content export can take much longer than expected
- There is no chance you can completely automate it
- It often involves running scripts throughout the night – it is never just a day job
- You thought it was out of scope until you find yourself doing it
- Shortly after you think you’ve finished migrating the content, you find more content to migrate
Trust me. I’ve migrated a lot of content, and I’ve changed a lot of nappies. Fortunately, there is one big difference – it is much harder to extract the content from the source than to put it into the target repository. Thankfully, when changing a nappy, the content only comes out. And content never pisses in your eye.
RSS Feed
Follow Me
Then there’s understanding the hierarchy. And trying to auto build a navigation! In SA they’d say *YES WELL NO FINE*.
And what’s the point of sweetcorn?
Well put Jon. Despite the fact that I can’t really relate to the nappies, but I can relate to the content of them (as I believe we all produce that except The Queen).
One of my previous bosses told me “Sh*t in, sh*t out” when I was building a fairly advanced CSV to database import. Whilst I agreed with the first part of the statement, I refused to act as a conduit to produce the second part. I could feel he wanted to sack me when the speed of the old and simple import was four times faster as the first version of my import. Funnily enough my import didn’t accept things like obviously faulty email address’.
Another scenario that remind me are the countless “Client DB to our DB” ‘conversions’ that I’ve done. The only thing I can recommend in this are these day (apart from stay away) is to bill by the hour and script everything. Everytime we did it without scripting we ended up with one insanely important gatekeeper person who would then dictate the pretty much everything else in that project – because he was the only one who understood the client’s DB structure and how it was pushed into our DB structure.
Finally, “Sometimes the state of the content is a symptom of some other illness” made me chuckle out loud. Thanks!!
Awesome post Jon.
Yes, there is always more content to migrate, especially in the kind of projects where there is no ‘freeze time’ or ‘cut-over’ period. It becomes challenging to ‘include’ the last bit of live content to the new system.
Yes, there is no chance you can completely automate it. I know few software providers who claims to automatically migrate content from one CMS/DMS to another CMS/DMS, but technically they end up manually doing more than 40% of the tasks, be it XML generation, or writing so called custom scripts.
Yes, the content is extremely difficult to classify, but not always. You are lucky if you get to migrate content from one modern day CMS to another modern day CMS, but it becomes a nightmare if the content is present in unstructured file system and metadata is spread across various tables in the database, and definitely the content export will eat half of one’s life.
I laughed my lungs out on ‘You thought it was out of scope until you find yourself doing it’
Good post, I love the picture – graphic! My only thought is that it is almost possible to script everything, provided that the source data is “clean” i.e. you know what it should look like so you get an oompa loompa from the source db/application to change it all by hand.
You’ve never changed a nappy, have you. The source data isn’t clean. Not clean at all. No siree, ma’am.
Okay, you can completely automate really simple migrations. But most CMS content migrations I see aren’t simple. The source and target repositories have different concepts too and often the data you need for the target doesn’t exist in the source.
I guess I could automate an email to the Oompa Loompa saying
What do you get when you guzzle down sweets?
Wise words.
The only thing about which I disagree with you is that you can’t automate nappy changing.
Oh, thanks for this…very useful as we are advising lately on “best practices” here. I might add:
* You can hire a nanny, but then you can’t be sure it will be done right or often enough (and might not notice til the house starts stinking)
* You find yourself wishing for a period of constipation, but it almost never comes
* Safe, long-term disposal of unwanted objects remains a big problem
You need to change a girl: they can’t piss in your eye unless you’re holding them over your head.
Most important thing to remember:
During a migration, the content is still in nappies and readily disposable. Once you’re potty-trained and in your new CMS, getting rid of the crap is a far messier process.
It’s one of the Big Web Problems. But what, in general, would you think might be a good approach to take in order to avoid some of the nastier issues if you could?
Many of the issues posted about content migration are overcome with good automated content migration software and a migration methodology. Most people still are struggling with Cut and paste, scripts when they should be using a software approach. Still do not understand why people have a blind spot on this subject. Suspect they think it is to difficult and complex for software. 100′s of companies who use migration products would differ. Check out best practice paper at http://www.vamosa.com/knowledge-base/how-to-guides-o43
Hi George,
Thanks for the comments. Actually, I do agree with you. There is a lot of software out there (yours in particular, actually) that can make the task a whole lot easier. However, many people haven’t had exposure to Vamosa and other similar products. How easy is it for prospective customers of yours to get hold of a free/eval version of the software so they can play and test? Maybe a version that will only do X pieces of content, where X is pretty small?
We’re about to embark on a Vamosa project shortly so hopefully I’ll become wise in the ways of your latest versions!
The analogy is pungently accurate, however after a while kids grow out of the need for nappie-changing; content never seems to.
I agree with your Why Content Migration Is Like Changing A Nappy | Jon On Tech, great post.
I have read so many articles on the topic of the
blogger lovers but this paragraph is truly a good piece
of writing, keep it up. https://raleighmurphy6.Joomla.com/485-the-three-steps-to-make-your-vegan-cookies-wholesome
Acostumbro cada noche buscar webs para pasar un buen momento leyendo y de esta forma me he tropezado vuestra web. La verdad me ha gustado el post y pienso volver para seguir pasando buenos momentos.
Saludos
comprar bioeffect https://www.lesecretdumarais.com/es/bioeffect/3410-bioeffect-egf-eye-mask-treatment-5694230071593.html