May 26, 2011
Ok, you and your organization are finally moving away from that legacy outdated website management system to a real state-of-the-art Web Content Management system! Everyone is excited about seeing the old system retired and is looking forward to a much better life with the new CMS. Maybe it even involves a redesign or maybe your moving the website over just as it looks today with some minor tweaks. Either way, you have a lot to consider in the project plan. But whatever you do… don’t overlook the content migration plan!
When it comes to a redesign and/or a redevelopment of your website, the other phases of the project (discovery, design, specification, development, QA, deployment) get a lot of attention, but whenever you move from one system to another, the content migration can be absolutely critical. In many situations this can be the “x-factor”, the “black box”, the “unchartered waters” as you have a unique combination of the specific legacy CMS, the specific new CMS, and your specific organization’s content. But, if handled correctly and thoroughly, risks can be mitigated and expectations can be kept in check resulting in a successful migration and all of those day dreams of not dealing with the previous system anymore can become true.
Where to Begin?
The content migration strategy should be represented in the overall project plan from the start. But depending on the systems involved, you should begin detailing your approach once the new CMS content model and architecture has been completed so you can clearly see the structure of the new system you must migrate to. You and your team should scrutinize the content model of the two systems and consider the feasibility and logistics in choosing an automated migration, a manual migration, or a hybrid approach. First off, if the site is small, a manual migration may be best simply because the overhead of architecting an automated approach may equate the effort to get it done manually. That aside, assuming we’re talking about websites with a significant amount of content (over 500 pages), you’ll want to determine if the source content model can be mapped to the destination content model and if the two technologies will play nicely. For example, migrating a .NET/SQL Server based CMS to another is much easier than starting with some proprietary system or one from a different platform. Think about the ramp-up involved in the automated approach and what the level of risk may be due to unknowns in the legacy system. If the amount of content is massive, it may still be worth the risks. Or perhaps outsourcing temp staff to divide-and-conquer a manual approach is best. Or, yet another option may be to manually migrate the content except for some structured, consistent, high quantity content (i.e. press releases) that can be automated.
As you can see by the length of this post so far, there is a lot to do! So, I’m going to outline some other key points for you.
Content Inventory and Process Management
Each migration project should include a content inventory. Typically just a spreadsheet, this should list the existing content’s name, URL, type (i.e. HTML, PDF, etc.), destination (content type and what part of the new site it belongs in) and who it’s assigned to. This will help you manage your progress and ensure nothing gets left behind. It also aids in the management of a manual migration where you may have 4, 5 or more individuals working in parallel on content. Also, use this as an opportunity to clean house! If you don’t need it, don’t migrate it! Many websites get overburdened with outdated content that only exists because nobody wants take the accountability of being the one to discard something. But it really should be done – keep your site lean.
Beware of Broken Links and Images
When you move to a new CMS, most likely the organization and paths to other pages and assets like images and documents will be completely different. That means, if you have a lot of HTML content, there will be a lot of images to relocate and links to re-associate. This effort can be reduced significantly, if the legacy file structure (like image paths and downloads) can be retained and slowly phased out as content editors add or modify content down the road.
Keep Your SEO Rankings
Once you retire the old site, there will be a lot of URLs that will be dead – they won’t exist. That could spell disaster for your hard-earned SEO rankings unless you include a process for mapping old URLs to their new counterparts with 301 Redirects. This tells the search engines where your new page now resides and retains the ranking. It’s typically a good idea to ensure there is a simple management tool in place during launch for content owners to manage these 301 redirects as they go as well. Your Meta data should be closely reviewed as well. Primarily, this is “content” that should be migrated just like the visual content.
Quality Control – The More the Merrier
This may go without saying, but you can’t be too careful. Plan on a significant QA phase – the more content, the more QA needed. Be sure to have a clear process of testing, remediation and verification using an issue management system.
Project Management is Crucial
Bottom line, a lot of your success will ride on the thoroughness, planning ahead, identifying risks and clear communication. Great project management is essential as you’ll be dealing with multiple software vendors (the legacy and the new), multiple content owners, a team of developers for CMS development and automated migration, an outsourced staff for manual migration, and the typical set of stakeholders. So start planning your Content Migration strategy to ensure all of those day dreams of your new CMS come true.
comments powered by