Do you have a web content migration in your future? How do you know? What do you need to do to be prepared? How do you do it? What will it take to be successful?
Web content migrations are a unique type of project that has a broad effect on business and technical stakeholders. I have been involved in several migrations, some more successful than others, and want to share my experience. This first part of the blog reviews the dimensions of web content, identifies the types of content migrations, and helps you prepare for a migration. The second part of the blog will go in detail through the steps required.
Why Are You Migrating Web Content?
Here are three of the top reasons for migrating content:
- You are replacing your existing Content Management System (CMS) with a new one or consolidating web content into a new CMS.
- You are upgrading your CMS. The latest and greatest version of the CMS now not only has enhanced features, but also a new subset of tools and applications that treat a specific subset of content such as digital media differently.
- You are changing the structure of your content. Whether you are making modifications to a single content type or rolling out a new framework, the existing content needs to be migrated to fit within this new content structure.
What is Web Content?
Before we get to the migration, let’s review what we mean by web content. Any information that appears on the website of an organization is web content. This can be static files such as images, documents, multimedia files such as audio, video as well as content that is created and stored within the CMS. That being said, your CMS may also host content that is not displayed but supports how content is served up. Web content also includes the way the content is organized in the CMS, metadata about the content, and data about how and where the content will be displayed.
How Big is Your Migration?
Next let us size up the various aspects of content we need to factor in to the migration.
- Volume of the content, measured in number of content instances and the byte count of the data.
- Variety of content, measured in number of types of content such as text, imagery, video, audio, documents etc.
- Number of internal content references and dependencies. There are content instances that are referred to by other content instances within the CMS.
- Rules associated with content.
- Number of delivery channels served (web, mobile, tablet).
- Other features (personalization, translation, A/B testing, analytics etc.).
- CMS specific customizations.
Understanding these dimensions will help you make the right choice for how to approach your migration.
Planning for Migration
Content migration is a joint exercise between the business owner of the CMS and the IT organization. Content migration needs to be treated and managed as a separate project, and not as an addendum to the existing projects. There are two aspects from a management perspective – Project Management and Change Management. Let us take a quick look at them.
There is nothing different or specific for a content migration from a typical project management standpoint. The problem is how it is being conceived and treated. Sometimes content migration is thought of as ‘yet another development task’. Pitfalls such as those can be avoided by considering content migration as a separate project by following the guidelines below:
- Identify and establish web content migration as a specific project task quite early in the project life cycle.
- Allocate a project manager to champion the content migration initiative.
- Create a project plan (by the project manager) that needs to include time for scope, requirements, design, development (the migration), testing and deployment.
- Allocate time, budget and resources appropriately and in timely fashion.
- Involve the content management team from the begining. One of the major concerns I have faced is the lack of involving the actual content management team in the decision making and execution process. The content management team brings to the table not only their knowledge of the content management system, but a lot of operational details and the processes involved. They have a good idea about the team, their project schedule etc. Their involvement is very important when decisions are made around the new CMS such as the Content Types/schemas, workflows, folder structure, security etc.
I would like to highlight some of the major aspects of change management that needs to be considered as mentioned below:
Establish an open and clear communication channel
Something as simple as communication is one of the critical areas where a lot of slipups and mismanagement occurs. Clear, apt and concise information drafted and sent at appropriate time periodswould allay stake holder fears and reduce a lot of chatter and chaos around it. The audience is varied – we have the IT team, the Business Sponsors, Content Management team, and sometimes users external to the organization who use the CMS. A solid project plan will have the communication timelines drawn across the various milestones of the project
Co-ordination with the Stakeholders
A typical migration project consists of at least 3 different teams working in tandem – the IT team, the content management team and the business sponsors. There are always a myriad of activities planned and executed which makes co-ordination among the various team members and stake holders very important. This can be accomplished by holding regular status meetings or briefings and an open line of communication to keep everyone informed with regular updates. Communication and co-ordination go hand in hand. I have worked in projects where the migration was successful from a technical perspective, but an absolute disaster from a communication and co-ordination perspective, which ultimately led a lot of people involved to think that the project was a failure.
Schedule & Conduct Training before the rollout
Training can be any of the following:
- Training users to the new CMS
- Training users to the new content design or paradigm
- Training users to the new features of the existing CMS
The key here is to make sure that the user base is given appropriate training before the rollout. The user base also should be given sufficient time to get acclimatized with the new setup. Depending on the number of users and geographical distribution, this can take place over the web or on a specific geographic location.
Plan for post rollout content updates
No matter how careful you are, there will be always some changes or updates that need to be applied to the content after the migration. In a lot of cases this is a planned activity wherein updates to the content are tracked and maintained in a separate list so that the changes could be applied after the rollout. Post rollout updates are usually time consuming, cumbersome and sometimes a pain, but they can be managed by adopting the following guidelines:
- Establish a freeze period after consulting with the stakeholders. A freeze period is the time during which no changes to the content are allowed. This is usually done a few days or sometimes a week before the actual production rollout. The freeze period needs to be strictly enforced and followed. A freeze period that is too long or too short is counterproductive as it may cause further complications.
- Try to include as little content as possible for post rollout updates. What I mean by this is that we need to squeeze in as much as content as possible for the regular migration and leave only real exceptions to be taken up for post rollout changes.
- Establish a proper tracking procedure to ensure that the appropriate content is tracked for updates and changes.
I would like to conclude by saying that content migration projects vary in scope and complexity depending on what you are trying to do. The basic steps to be followed are not complicated though, and can be implemented as described in the above sections. In spite of careful planning and execution, there will be always some surprises and the project team should be prepared and ready to handle them. It does not hurt if people who are well versed in content migrations or anyone who has worked on similar migrations are bought into the team as SMEs (Subject Matter Expert) or in other roles to aid in planning and execution.
UPDATE: See my next post in this series, Web Content Migration – Part 2.
Also, consider reading my colleague Will Thayer’s post specific to migrating to a *new* CMS, Migrating content to a new Web Content Management System.
Felix Simon is a Senior Consultant for Avalon Consulting, LLC