Content migration—moving existing web content to a new website, as well as creating and entering new content—can be one of the most complex and challenging aspects of a website development project.
Unfortunately, content migration is often overlooked at the outset of a web project, and when the effort required is fully understood, panic sets in. However, with good planning, strong project management, and a team of content migrators who are willing to roll with the punches, content migration projects will go smoothly.
Get a sense of the general scope of work
Three factors define the overall scope of work for a website migration project:
The volume of content that must be migrated from the old website to the new site
Many people assume that data can be “automatically” transferred, but aside from large, well-structured data sets—a product database, for instance—this is rarely the case. It’s almost always faster and cheaper to manually migrate content than to pay developers to write and test scripts to automate the process.
The extent to which new content will be created
A new website project is often driven by changes in content strategy (among other things). That means there will be some combination of new and revised content. In many organizations the time needed to create new content and obtain approvals is considerable.
The urgency to launch the new website
Sometimes content migration work must be done at the same time the new website is being built—and this is typically the case if Agile development methodologies are used. This forces the content migration team to work with the CMS while it is only partially complete. Under these circumstances, content migrators may need to revisit partially built web pages as new components are released, which makes the entire effort more complicated.
Obtain detailed page-level information
To be able to calculate resource requirements for content migration, detailed page-level information is needed. Three key tools can be annotated to provide this information:
The sitemap is an incredibly useful tool to understand the big picture of the migration effort, and can also provide some granularity on a per-page basis. Pages can be labeled or color-coded based on the amount of new content on each, etc. Print out the sitemap as a large poster that can be hung on the wall—the bigger the better—so the team can attach post-its, make notes on it, etc. as work progresses.
Every page of the wireframes should specify the CMS templates and components required to make that page. This assists the content migration effort in two ways: determining resource requirements, and telling content migrators how to build the page. (Bear in mind in an Agile development scenario, wireframes and components may change as development progresses.)
This spreadsheet should list every page on the new website (as the sitemap rarely shows every page) and contain information about the extent of content changes. This can be as simple as “all-new,” “some-new” and “no-new,” but it may make sense to use additional categories if more nuance is required for images, video, information graphics, and other assets.
Prepare a process chart and RACI
With specific page-level information at hand, the process to create content and enter it into the CMS can be articulated with two documents:
Content migration process chart
The process chart should be as straightforward as possible and identify each key step to create a new web page. For simplicity, process steps and roles can be combined and approval loops can be ignored.
Process chart for a fairly large website migration project that combines process steps and roles.
“RACI” stands for “responsible,” “accountable,” “consulted,” and “informed.” Use the RACI matrix to identify every participant in the process (including content creators and approvers) and their role and responsibility. Map the RACI matrix to the content migration process chart.
Agree on content migration tools
Assemble key members of the content migration team to agree on the tools every member of the content migration team will use. Cloud-based tools are ideal for these documents because they allow for a single shared version with revision history.
An asset sheet contains all the information a content migrator needs to create one page in the new website—all the copy, layout and image instructions, metadata, page titles, Open Graph copy, URL, etc. Asset sheets can also include instructions for multivariate testing and personalization (but it's often best to not implement this functionality until after all the content migration work has been completed). Google Suite, Office 365, or Confluence are all good choices for asset sheets.
Dedicated project management tools like Jira or Trello can be used to track the progress of content migration work, but unless the entire team knows how to use them it will be problematic. Everyone, however, is familiar with a spreadsheet such as Google Sheets or Excel.
The content spreadsheet can be expanded to include tracking information. Be sure to get the input of senior team members since they may require particular information to report progress to management.
Write an internal Statement of Work
A Statement of Work (SOW) is an ideal way to create a shared understanding of the work to be done, how long it will take, project team members, and the level of effort required. In many cases, organizations hire outside contractors to help with the content migration effort and the SOW can be used to explain to management why outside help is needed, what they will do and how much it will cost. Bear in mind the typical content migration project will require 4- to 6-hours of work per page—possibly much more if a lot of new content will be created.
Use the content spreadsheet to estimate the level of effort for each person involved—and pay special attention to the amount of work that will be asked of the senior team members.
The SOW should also include:
- The CMS training required for each person on the RACI matrix. Some participants will require extensive training on the entire CMS while others can be trained on just a few components. (Try to involve a senior executive in the training, with the goal of giving them an overall sense of the work required to create and revise pages in the CMS.)
- A request for a dedicated space for the duration of the project to collaborate, conduct regular meetings and generally map out the “plan of attack.”
Content migration projects can have so many moving parts that they can appear chaotic to stakeholders outside the core team. These tips, tools, and techniques provide valuable information everyone can use to understand the scope of the project and their role in making it successful.