Migrating Legacy Content: How to Improve Content Usability and Quality Through a Migration Project


Published on

Presented by Laura Melcher at the CM Pros Fall 2007 Summit on Web Content Management, November 26, 2007.

Is your company looking to undertake a major content migration project in order to implement a new content management solution and/or retire a legacy tool? If so, you’re in luck – this session includes everything you need to know to make your project a success, from getting a handle on a possible “Wild West” content situation to stakeholder identification and management, migration strategy, success metrics, launch communications and more. Future-state content management, standards and governance will also be covered.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Migrating Legacy Content: How to Improve Content Usability and Quality Through a Migration Project

  1. 1. Migrating Legacy Content How to Improve Content Usability and Quality Through a Migration Project Presenter: Laura Melcher CM Pros Summit Nov. 26, 2007
  2. 2. Presentation topics <ul><li>Overview of migration projects </li></ul><ul><li>Planning a migration </li></ul><ul><li>Conducting a content inventory </li></ul><ul><li>Developing a migration strategy </li></ul><ul><li>Defining workflows and access controls </li></ul><ul><li>Creating content standards </li></ul><ul><li>Implementing a governance model </li></ul>
  3. 3. Overview <ul><li>How migration projects start </li></ul><ul><ul><li>Ideally, as a result of strategic planning for site improvement </li></ul></ul><ul><ul><li>Realistically, out of necessity </li></ul></ul><ul><li>The good news </li></ul><ul><ul><li>Migrations are terrific opportunities for improvement </li></ul></ul><ul><li>The less-good news </li></ul><ul><ul><li>Migrations are often very labor-intensive and can be politically and culturally difficult </li></ul></ul>
  4. 4. Migration planning <ul><li>Understand the project mandate (the “why”) </li></ul><ul><li>Identify stakeholders and political barriers </li></ul><ul><li>Determine any budget/resource/time constraints </li></ul><ul><li>Work with technology and other stakeholders to confirm roles and responsibilities </li></ul><ul><li>Get content inventory/analysis activities under way as soon as possible - this is by far the most time-consuming aspect of your project. </li></ul>
  5. 5. Migration planning (cont.) <ul><li>Migration team resource models (the “who”) </li></ul><ul><ul><li>Centralized </li></ul></ul><ul><ul><ul><li>Web team (usually, IT and communications/marketing) with involvement as needed from content owners </li></ul></ul></ul><ul><ul><li>Decentralized </li></ul></ul><ul><ul><ul><li>Individual content owners/stakeholders with some direction from Web team </li></ul></ul></ul><ul><ul><li>Outsourced </li></ul></ul><ul><ul><ul><li>External team with involvement of individual content owners and oversight of Web team OR </li></ul></ul></ul><ul><ul><ul><li>External team to augment your staff resources </li></ul></ul></ul>
  6. 6. Migration planning (cont.) <ul><li>Work with IA/usability team to determine future-state site architecture based on user research (the “what”) </li></ul><ul><li>Decide on information architecture and desired level of functionality (static vs. dynamic) </li></ul><ul><li>Determine appropriate CMS “microsite” architecture to support section-specific security, navigation and templating, taking into account the following: </li></ul><ul><ul><ul><li>Number and complexity of templates </li></ul></ul></ul><ul><ul><ul><li>Expected reuse of content across site </li></ul></ul></ul><ul><ul><ul><li>Amount of dynamic or personalized content </li></ul></ul></ul><ul><ul><ul><li>Volatility of content (how often it changes) </li></ul></ul></ul><ul><ul><ul><li>Desired security and workflow model </li></ul></ul></ul>
  7. 7. Content inventory <ul><li>Five key content analysis factors: </li></ul><ul><ul><li>Volume </li></ul></ul><ul><ul><ul><li>What you can delete? </li></ul></ul></ul><ul><ul><li>Complexity </li></ul></ul><ul><ul><li>Quality/reusability </li></ul></ul><ul><ul><ul><li>How much work will be required to update “old” content? </li></ul></ul></ul><ul><ul><li>Delta between current and future-state content structure/information architecture and overall CMS functionality </li></ul></ul><ul><ul><li>Content owner availability and skill level </li></ul></ul>
  8. 8. Content inventory (cont.) <ul><li>Develop a “migration map” showing old-to-new file structure, directory structure and permissions (“where”) </li></ul><ul><li>Make sure to note which content sets are not to be migrated </li></ul><ul><li>Note where content owner permissions and usability of authoring environment necessitate changes in CMS administrative structure/folder hierarchy </li></ul><ul><li>Incorporate any changes to file and directory naming into migration map </li></ul>
  9. 9. Migration strategy <ul><li>Automate it - unless your site is very small </li></ul><ul><li>You may need to manually migrate pages that are anomalies or are highly complex </li></ul><ul><li>Allow extra time for honing migration scripts and checking/re-checking content quality post-migration </li></ul><ul><li>Involve business owners in approving quality of content post-migration; IT likely defines success differently than the business! </li></ul><ul><li>Allow time for migration script “hiccups” and manual movement of some files within new directories </li></ul>
  10. 10. Migration strategy (cont.) <ul><li>Plan for some amount of content clean-up post-migration, and have resources available for: </li></ul><ul><ul><li>Reformatting </li></ul></ul><ul><ul><li>Checking links </li></ul></ul><ul><ul><li>Verifying styles (i.e., if style is not correctly applied to content, either manually correcting or flagging pages for recoding) </li></ul></ul><ul><ul><li>Reviewing content location (in CMS) and file names </li></ul></ul><ul><ul><li>Applying metadata as needed </li></ul></ul><ul><li>Content “QA-ers” may be in-house or relatively inexpensive contract/temporary labor </li></ul>
  11. 11. Workflows and access control <ul><li>Post-migration, double-check that your new structure meets the needs of the business and content editors. </li></ul><ul><ul><li>Does everyone have access to their sections? </li></ul></ul><ul><ul><li>Have roles and responsibilities changed for any departments? </li></ul></ul><ul><ul><li>Are additional approvals required for certain types of content? </li></ul></ul><ul><li>Ensure that content managers are trained on the system and understand how/where permissions are applied. </li></ul><ul><li>The system should provide intuitive access to various workflows - if these are many and varied, personalized presentation may be required. </li></ul>
  12. 12. Content standards <ul><li>You will need standards for presentation (design), information architecture and writing. </li></ul><ul><li>Ideally, you have defined standards in advance and communicated these to stakeholders and publishers. </li></ul><ul><li>If not, figure out which standards are supported by built-in style sheets and supported by limited authoring template capability. </li></ul><ul><li>All other standards will need to be clearly documented and communicated - keeping in mind the resources you have available for education and enforcement. </li></ul>
  13. 13. Governance <ul><li>Work with stakeholders to establish a flexible governance model that is specific to your business </li></ul><ul><li>Identify key resources to be involved in an oversight group or committee </li></ul><ul><li>Determine how your existing staff will manage and communicate with the publishing community and oversight board </li></ul><ul><li>Clearly document roles and responsibilities with IT and other relevant groups, for budgeting and project prioritization purposes </li></ul>
  14. 14. Governance (cont.) <ul><li>Develop a process for prioritizing CMS projects, including template development, new sites and new functionality, taking into account: </li></ul><ul><ul><li>Benefit/impact of project (number of customers, revenue potential, etc.) </li></ul></ul><ul><ul><li>Size of project - cost, time, resources </li></ul></ul><ul><ul><li>Complexity of project </li></ul></ul><ul><ul><li>Competing efforts </li></ul></ul><ul><ul><li>Other factors (upcoming site changes, emerging technologies, etc.) </li></ul></ul>
  15. 15. Governance (cont.) <ul><li>Develop model for making decisions for home page management </li></ul><ul><ul><li>Content organization on home page - determined by user preferences and metrics as well as business strategy </li></ul></ul><ul><ul><li>Additions/changes to navigation elements on home page </li></ul></ul><ul><ul><li>Day-to-day oversight of content submissions and editorial features </li></ul></ul>
  16. 16. Governance (cont.) <ul><li>Strategy and long-range planning </li></ul><ul><ul><li>Involve your stakeholders in determining your vision for the site </li></ul></ul><ul><ul><li>Agree on a time line for longer-term changes (often three to five years) </li></ul></ul><ul><ul><li>Determine your funding model for larger, long-term projects (often either a chargeback or capital expense) </li></ul></ul><ul><ul><li>Include a plan for review, updating and modification of your plan as business conditions will change </li></ul></ul><ul><ul><li>Make sure IT strategy is in line with business strategy </li></ul></ul>
  17. 17. Lessons learned <ul><li>“ You don’t know what you don’t know” </li></ul><ul><li>“ Breathe into the bag” </li></ul><ul><li>“ The offshore team went over budget” </li></ul><ul><li>“ We did it!” </li></ul>
  18. 18. Conclusion <ul><li>You can do it, too - just don’t underestimate the effort. </li></ul><ul><li>Get the support you need early on - both from stakeholders and management. </li></ul><ul><li>Above all, remain flexible - this is not the “end,” just a stop along the way. </li></ul>
  19. 19. Questions/contact <ul><li>Laura Melcher </li></ul><ul><li>E-mail: [email_address] .org </li></ul><ul><li>Office phone: 312-329-8572 </li></ul>