Migrating Content to a CMS
Migrating to a new content management system (CMS), or moving from a static HTML site to a CMS for the first time, can be a daunting task. But, over the long-term, it can be the most efficient way for your agency to publish open content using modern publishing tools. A content management system can also automate many tasks, allow different levels of access to authors and publishers, and support open government by organizing and exposing information. Review the Business Case for a CMS, which explains why moving to a CMS makes good business sense.
A migration to a new CMS involves more than just content. You’ll also need to integrate your information architecture, navigation, search, social media, and other tools into the new CMS. In addition, your CMS implementation needs to align with your agency’s overall enterprise architecture and IT systems. The complexity of a migration illustrates the importance of strong Web governance, so a migration can be an opportunity to strengthen your governance model, if needed.
- Plan Your Migration
- Identify the Best Migration Model
- Migrate Your Content
- Launch Website in New CMS
Plan Your Migration
Depending on how large your site is, and how much content you have, a full-scale migration can take several weeks to several months. A clear, concrete plan will help you achieve success.
Develop your Project Plan
A content migration is more than just an IT project; it should be managed as any other large business project. The following articles provide a good overview of the many aspects of a content migration that you’ll need to consider:
Here are some examples of both a very basic project outline, and a detailed project plan:
- Sample Task List for Website Redesign (MS Word, 13 KB, 2 pages, December 2012) shows a high-level project outline
- Sample Website Redesign Schedule (PDF, 249 KB, 10 pages, December 2012) shows a detailed website migration project plan
Identify Resource Requirements
Do you have sufficient resources to successfully pull off a migration? Consider:
- Management support—have you clearly articulated the business value to managers so they are committed to supporting the migration?
- Staffing—do you have enough people available to migrate content quickly, and review content to make sure it’s complete and correct in the new CMS? How will you manage both your ongoing, day-to-day work in addition to the migration work?
- Technical resources—do you have the skills to configure the new CMS, write scripts for the migration, etc.? Note that many agencies outsource much of the technical work.
- Communications—who will keep managers, program offices and content owners informed of progress, and help you articulate benefits and success?
Decide if You Need Contractor Support
Many agencies contract for developer support with a migration, because it’s a lot of work to accomplish in a short time. To help you make this decision, consider:
- Technical skills on your team—do you have people on your team who are experts in your new CMS? If you choose to automate the content migration, do you have developers who can write the proper code and scripts?
- Time—even if you have the skills, do those people with the skills have the time? A migration can take several weeks to several months.
- Resources—do you have funding available to procure a contractor?
- Size and Complexity—are you migrating one small site, or are you migrating a large site, or combining several old sites together into one new site? The larger the project, the more likely you’ll need some help to complete it in a reasonable timeframe.
A Statement of Work/Objectives (SOW/SOO) will help you retain the services of a 3rd-party contractor to assist with installing and configuring your new CMS, and migrating your content. Work with your Contracting Office to execute an SOO/SOW.
- Sample Technology Statements of Work (SOWs)
- Sample Statement of Objectives—Website CMS migration, development and support (MS Word, 53 KB, 14 pages, November 2012)—GSA
- Sample Statement of Objectives—Website CMS consolidation (MS Word, 53 KB, 12 pages, November 2012)—GSA
Once they’re on board, make sure the contractors are in the loop on all the prep work you’ve done up to this point. A migration is a complex project, so it's critical that everyone working on the project collaborates throughout the entire process.
- Share relevant planning documents such as your content strategy and business requirements; see Preparing Content to Move to a CMS for examples.
- Review your content inventory in great detail, so the contractors understand your content, and how it’s supposed to look and act in the new system.
- Review your content types, so they can help you migrate the content into a structured format.
- Institute regular and frequent meetings with contractors, to keep everyone up-to-date, identify and mitigate problems early-on, and ensure everything flows smoothly.
Identify Roles and Responsibilities
Document who’s responsible for every piece of the migration project, so nothing falls through the cracks.
- Identify your project manager, and empower that person to make decisions and assign work.
- Clarify who will lead each piece of the project, such as managing the content inventory, or coordinating development work. Review Choosing a CMS and Preparing Content to Move to a CMS for a clear picture of all the pieces.
- A Project Charter can ensure you have project buy-in from stakeholders across your organization.
Communicate With Stakeholders
A successful migration depends on support from management and buy-in from stakeholders. Articulate what you’re doing, why you’re doing it, and benefits you expect, to make sure you get the resources you need to make your project a success.
- Provide regular updates throughout the migration process, highlight successes and flag potential problems, to keep everything on track.
- See a sample marketing flyer from EPA (PDF, 543 KB, 2 pages, November 2012) about their migration to Drupal. It outlines what they’re doing, why they’re doing it, and how it will work.
Pick the Right Time to Migrate
Migrating to a new CMS can take several weeks or months, depending on the amount of content and resources available.
- Consider what times of the year are busiest for your agency, and avoid migrating during those times. For example, the IRS shouldn’t migrate their website in April.
Minimize the Impact of a Content Freeze
At some point, you’ll have to restrict updates for a short time while you actually move content into the new CMS. To minimize the impact of this “content freeze” on your content owners, set realistic expectations around what will happen, and when.
- Let content owners know in advance when to expect the content freeze, so they can make important site updates beforehand.
- Once you know how long the freeze will last, give content owners an estimate that includes a few extra days, in case you run into unexpected delays. It’s better to wrap early, than to make people wait longer than they’d planned.
Identify the Best Migration Model
The size and complexity of your site will determine whether or not you can automate certain migration tasks. Also consider how much time you need to realistically budget for a content freeze.
Manual Migration
In a manual migration, content is manually copied and pasted from the old system to the new. The amount of time needed for a manual migration depends on the complexity of the site and the number of people doing the work. Small sites (under 1,000 pages) may take a few weeks or months—from initial planning to completion—while larger sites (50,000 pages or more) may take much longer.
If you’re moving from static HTML to a structured content model, you may not be able to simply cut and paste all your pages from the old system to the new. Depending on the type of content, you may need to paste the content in pieces, so you can save it as structured content.
Automated Migration
An automated migration uses software tools to move content from the old site into the new CMS. It usually requires a lot of time upfront to develop migration scripts, but significantly speeds up the actual content migration process, and can reduce the length of your content freeze.
Computer scripts can be written to move entire pages, or move content by fields (such as title, body, meta elements, or other discrete items). Your scripts need to map content properly into the correct fields in your new CMS—and if you don’t already have structured content, you may still have to do much of the work by hand.
While scripts can make the migration process move quicker, the end result still needs to be reviewed by humans to make sure it worked properly.
Mixed Migration
You may use a mix of manual work and automated tools, if you are only able to automate parts of your migration, and have to manually move the rest of your content into the new system.
Content Freeze
Your migration will be simpler if you don’t make any content changes as you’re actually migrating content to the new CMS. If you absolutely cannot freeze your content, you’ll need to make identical content updates on both the old and new sites to keep content in sync, so you don’t lose any updates, or inadvertently migrate old content over new. Note that a manual migration may mean a content freeze of a few days or weeks; an automated migration may lessen the time you’re under a freeze, but requires more up-front code work.
Each website and situation is different, so select the model that works best for your content and business needs.
Migrate Your Content
Once you’ve got a strategy in place, and identified the type of migration you’ll do, it’s time to migrate your content to the new CMS.
Follow Your Plan
Do your best to stick to promised timelines and deadlines, so stakeholders remain supportive. If unexpected delays occur, let people know what’s happening, and how it will impact them, to mitigate any problems.
Inform External Stakeholders
If you have a key group of external stakeholders, and you anticipate the migration may impact them, let people know. Use normal communications channels such as listservs or social media to keep people informed.
Test Design Upgrades with Users
If you’re making any design changes along with your content migration, do user testing early-on, to gather feedback and make improvements before launch.
Plan for Structured Content
You’ll need to structure your content as you move it into the new CMS. If the content is already tagged with metadata, you may be able to automate this. If not, you should tag each page as you move the content into the new CMS. It’s much faster to tag as you go, than to go back and tag everything afterwards.
Back up Everything Before You Start
Make sure you have backed up your site, and coordinate with your IT shop to test the backup, to make sure it works and can be restored if needed.
Do a Practice Run
Test out your migration process (especially if you’ve automated anything) in a sandbox or testbed. It will help you to identify any problems, and fix them before the actual migration.
Consider a Beta Site
Some agencies have launched an early version their new site in “beta,” running it in parallel with the old site. This will give you a chance to test your migration process, and also gather customer feedback on the new site, if you’ve made any design enhancements.
Move Your Content
Once you have tested your migration process and everything works well, it's time to move your content into the new CMS. You'll need to validate that each piece of content was correctly migrated. Use the checklist below to verify each page as you move it.
- Content Migration Validation Checklist (MS Excel, 41 KB, 1 sheet, December 2012)
Create Redirects as Needed
No matter how thorough you are, you’ll be cleaning up and deleting old content and moving your entire website to a new platform, so your visitors may experience some broken links after the migration. If you've changed a lot of URLs during your migration, you may need to create redirects to help search engines re-index your site, and help your visitors find your content. Use 301 redirects to update links that have permanently moved to a new URL, and 302 redirects for temporary moves. Also follow these best practices for 404 (page not found) errors.
Test Everything Once It’s Moved
Before you shut down the old site, run the old and new sites in parallel to test everything, and make sure all your content migrated over and works properly. Check links, test functionality, make sure your search box and any other tools work correctly. Don’t switch over to the new site until you know everything works.
Launch Website in New CMS
If you’ve done your research and followed your plan, you should have a smooth migration. Once it’s all done, and the site is live in the new CMS:
- Evaluate what worked well, and where you ran into problems. Document as lessons learned for future migration projects, and share with your colleagues.
- Consider writing a case study, and send to us so we can post on HowTo.gov, so others can benefit from your experiences.
- Perform a “before and after comparison” to document improved efficiencies and help you measure success. Identify how the new CMS improves your ability to manage information assets, speed up content publication, or other improvements.
- Communicate results to your management team and stakeholders, so they understand that all the hard work was worth it.
Resources
- Five Suggestions for a Successful Migration from WelchmanPierpoint
- Content Migration Plan - Why it’s important and how to do it—discusses the value of a migration plan; written about intranets but concepts apply to public sites also
- Web CMS articles—CMSWire feed of current articles on Web CMS, updated daily
- Content migration—guidance and scripts from Microsoft to automate a Sharepoint migration
- Content Migration group on LinkedIn
- Why It’s Hard to Migrate Content—discusses key aspects of migration, in addition to content
- Web Content Management Migration Planning and Best Practices—references WebSphere specifically but applies more broadly
Next Step
Let us know if you have suggestions to improve this guidance.
Content Lead:
Rachel Flagg
Page Reviewed/Updated: January 24, 2013