For those who didn’t have a glance at my first post on content migration, you may find it “here”. I have been surfing around to get some insights since I’ve been a part of a big content migration project 8 months ago. And I touched base on the key factors to take into consideration “not” during the migration process, but beforehand. Today experiencing the most of goods and bads on the list, it’s no surprise that not all enterprises are having content migration smoothly.
In this article you will find elaborations and “Why?”s.
Timestamps for all processes which will take place in migration
First of all, all milestones and deadlines should be realistic, even with an extra margin of “just in case”. It is not always possible to estimate even major issues coming across during content migrations where you usually have over 1000 pages when migrating an enterprise content.
Considering the parties: business managers, stakeholders, project managers, content team and IT team , only the communication and status reporting chain itself needs “huge” amount of time and effort. If you include the actual workload of each party, among all other things because life goes on, unrealistic deadlines will just result in delayed launch and will make it look like a failure, where it actually was a miscalculation.
New designs/templates before it kisses the content
This step is crucial and should be managed by crystal clear communication with business side. New content strategy should fit into the new templates, therefore all new features, or eliminated features from old CMS should be communicated in detail even before any content enters to the new CMS environment.
There’s no doubt that it will go wrong when design/template development and content entries happen at the same time.
Most likely what will happen is:
– Lots of content losses due to IT issues, means lots of re-work and waste of time
– Lots of delays because each change should be tested by IT, so you can expect downtimes oftenly
– Business will start to complain, and you have to spend additional effort to explain everything in detail, and a simple e-mail is never enough to describe
IT configurations to have stable review and production environments
Review (Acceptance) environment: This is the server which is not publicly available, and used for quality assurance of the content change. Usually review servers are only accessible via internal networks or VPNs.(Virtual Private Network)
Imaginary example: http://review.emregokalp.youngsday.com
Production environment: This is the server which displays the page visitors see, a.k.a “live”.
Imaginary example: http://www.emregokalp.youngsday.com
There might be a few ways to enter content into a CMS.
1- If the enterprise is selling products rather then services, then in most cases there’s a “product database management system” where product data is stored. And it is connected to the content management system. In another saying, you don’t go and directly add the content in the content management system, instead you do updates in another environment and then click “SEND MY CHANGES TO THE CMS”
2- Pages which are either sub-pages of product related content, or pages like “homepage” or other kind of pages which has unstructured content. (About Us, Contact Us, Topics, Promotions, Campaigns, Events etc.) So you modify these pages directly from the new content management system.
Without a proper IT configuration and guaranteed stability, it is definitely a good way of torturing editors and business who eagerly waits to see the “new perfect working site to present to stakeholders.”
Related to previous subject of design/template readiness, there’s no way to migrate content smoothly when there’s still environmental issues popping up. To give some examples:
– Updates are not effective on review environment.
– Updates are effective on your screen, but someone in the US cant see. And when you refresh your page, you don’t see the updates. When you do another refresh, you see it again. Another refresh? Then you see the updates but this time images are broken.
There are more to come, but I will carry further subjects to next week – please see below.
– CMS configurations to make it author friendly as possible for the new home of content
– Finalize website sections, page hierarchy, metadata before you migrate content
– Finalize content for those will not be copied, instead will be generated by brand new copy
– Tasks of adjustments by doing some future thinking
– Steps to be taken to decommission your old website
Happy Youngsday everyone!
Image source: http://ameexusa.com/uploadedImages/Resources/Blog/Business_Blogs/tackling-the-question-of-content-migration.jpg?n=6849