I’ve worked on a number of website migration projects over the past decade. At a certain point, you get really good at understanding the pitfalls and developing a roadmap for moving projects forward across the various stages. Most of the time, web migrations — to a new content management system or just a redesign of site architecture — happen with people who are onboard for the entire length of the project. Whether it’s the staff working in a company, a consulting firm or some type of collaboration, the folks involved with making the project launch get to assess the landscape and make key decisions as the process goes on.
My experience has fit this traditional stance, but it’s also involved a number of times walking into a website migration already in progress; some of the scenarios include:
- A half-built website waiting to be completed and migrated.
- The planning stages of a website migration, but with key tactical decisions mapped out and a lack of flexibility on making critical changes.
- A new site designed & built, but with no new content to migrate.
Doing research about web migrations already in progress or even the content migration process in general is dicey because every organization works differently. Editorial workflows, governance and staffing for managing technical capabilities are all different and depending on those quirks, advising people in general ways can be difficult.
Common challenges to migration
There exists quite a bit of information about managing things like information architecture or the mechanics of the migration process. But what happens after those parts are complete? Who is responsible for what?
Thinking a lot about the ways that we structure our organizations, the issues with project management of content migration is a lot of responsibilities fall in-between roles. Often, the people leading these initiatives do not the authority in their organizations to execute much of the clout necessary to agitate people in other divisions to handle their responsibilities.
The problem with showing up mid-flight in a web project is a lot of they decisions have already been made. Time is the one thing you can’t buy more of; everyday you waste is another day the project which was behind before you showed up can be launched.
1. Your Project Manager probably has another job.
Website migrations are often hybrid affairs where an in-house staffer is tasked with melding all of the internal resources around the project. This would be fine if this person didn’t have other responsibilities that often overlap with the project itself or in another area entirely. In the odd chance you have people whose responsibilities are only project management, you’re faced with a PM who might have a good handle on the scope of each of the moving parts of the project and thus, ill-equipped to move the ball forward and light a fire under people when necessary.
2. Amok with content debt
If you ignore content long enough, you get a progressive rot of content on the website that can be seemingly impossible to get a handle on. When you’re about to migrate is the best time to revisit processes & come up with a governance structure that makes sense. In a lot of organizations, this is easier said than done, because convincing the right people to allow the focus to be on content can be a battle. Does this mean we ignore the content? No. It’s just worth being aware of the difficulties many organizations face with making sense of their content, much less migrating or being willing to invest resources into make it better.
3. Identify each stage of the process
Every workplace is different. Within those organizations are a variety of complexities that make each phase of the migration process difficult. Much like a maze, it can be easy to get stuck on one aspect of the process to the exclusion of the big picture. If you can target your laser on getting content migrated, you’ll have an easier time later of focusing on the other tasks that might be important to you like improving various aspects of design.
Once you’ve reached the stage where you’ve:
- selected a CMS
- have an approved design, coded and templates implemented;
the best thing you can do is focus your energy on developing a strategy for all of the moving parts left.
How do you identify those stages? By deciding what’s important and targeting the specific barriers to getting content refined and migrated to your new website. In our example above, the stages are outlined based on the specific areas that need to be tackled by the organization.
Your case might be different, the keys are ensuring that information is presented in an action-oriented, simple fashion that allows anyone viewing the project to understand what tasks will be completed and a rough estimate of how long it should take. If you’re working with multiple staff assigned to tasks, creating an “owner” section of the sheet could be useful.
Not every organization can afford an army of help mounting a content migration. If you’re faced with a situation where you have a small team focused on the task of transferring content, the best skill in your arsenal is going to be an ability to document a roadmap & plan with simple deliverables that get you closer to actually achieving the task at hand — migrating your content.
Keeping organized and establishing ground rules for the various aspects of your project, whether through existing guidelines or new ones you propose, will ensure the smoothest ride until you land on the ground with a new site in tow.