Content Migrations: Not Just for Developers

Note: This article originally appeared in the Bulletin of the Association for Information Science and Technology (ASIS&T).

Content migrations are hard. They’re complicated, expensive, detail-intensive, and can take a long time. To appropriate a well-used metaphor, a migration is like moving all your possessions from one house to another. If the proper planning isn’t done up front, you can end up with a jumble of broken, misplaced stuff at the other end. Taking the time up front to analyze and plan and involving a multi-disciplinary team in the effort pays off in the long run, helping the migration go smoothly and achieving an end result that satisfies both the business owners and the site users.

It Takes a Team

Site migrations are often staffed as IT projects. After all, there are software programs to be installed and configured, databases to be mined, scripts to be written, templates to be developed, and data moved from one system to another. These are all critical tasks, to be sure, but if done without analysis of the content, architecture, and functionality of the site—both the current version and the new—these tasks lack the necessary context.

The ideal makeup of a migration team includes the developers, of course, and a project manager to keep it all organized and running smoothly. A business analyst helps create the technical requirements and specs that the development team will build from. But just as important are the information architect and the content strategist, who carry the mantle for user experience and form a valuable bridge between the business owners and the end users.

Taking Stock

Before anyone starts planning how and where to move the site, and ideally before the new content management system or platform is selected, the information architect and the content strategist should inventory and audit the current site. The goal of the inventory is to understand in detail what content exists, what type it is, how it’s structured and why, what characteristics it has (is there metadata? are there naming conventions for assets?) as well as what functionality exists (forms, feeds, interactive elements like reviews and comments, transactional elements like registration or purchase) so that the new site can support all those current needs (we’ll get to future needs later).

Although many migrations are done as part of a larger redesign effort, it is seldom the case that every bit of content and every functional or design element of a site is replaced—and organizations rarely have the budget or organizational appetite to throw away everything and start fresh. Thus, it’s important to assess what is and isn’t working and what can be salvaged from the current site, perhaps polished up a bit, maybe moved to a different place in the overall architecture, but retained. Removal of what isn’t working and can’t be salvaged helps ensure that the new site is of uniformly high quality. Audits also create the opportunity to do a gap analysis, which assesses that current state against the desired future state and finds what’s missing and needs to be created.

While the initial inventory is an essentially quantitative exercise, the audit moves into the qualitative analysis. The content strategist will assess how much of the content is still current and relevant, how well it represents the organization’s brand and messaging goals, how well it supports user tasks, and, in some cases, how it stacks up to competitors’ content.

The outcome of the content audit is a strategy for how content will be structured and managed going forward; what content will be migrated as-is, what needs to be revised, and what to remove; what content needs to be created to meet the new site goals and who will create that; and a set of content requirements for the new system to support. Those requirements might include a content model that allows for content to be structured and tagged in a way that it can be reused and published in multiple contexts on multiple devices.

As the content strategist is auditing the content quality and developing content requirements, the information architect can in parallel be auditing the site structure, taxonomy, navigation models, and how well the functional elements work.

Both the CS and the IA may also be looking at site metrics and analytics data to learn how users are interacting with content and functionality to see what’s working and what’s not, where users are dropping off or hitting dead ends.

Conducting stakeholder interviews with content owners and authors is important at this phase of the project too. These interviews should garner insights into content ownership, publishing processes, lifecycle management, and governance as well as elicit the pain points that need to be addressed in designing the future state.

Building for the Future

The above activities, often referred to as a discovery phase, provides a solid basis from which the team can begin to plan and scope the project. The business analyst can begin to document requirements, the technical team can estimate the migration effort, and the project manager can track migration and design tasks against the budget and schedule.

Setting up the new content management system offers several opportunities for the information architect and content strategist to provide input and ensure that what gets set up supports the other important user group, the actual content authors and publishers.

Taxonomy is usually mentioned in a web project in the context of the overall site hierarchy and the structure of the terms with which content is tagged to support management, dynamic content generation, and search. Unless an organization is fortunate enough to be able to have a dedicated taxonomist, a content strategist or information architects generally manages this task. This is instantiated in several ways in the content management system. The first is the actual content tree or structure within which content is stored, which has implications for URL structure and downstream, search engine optimization. The second is the tagging management itself—the hierarchy of attributes and the vocabularies of their values. Building out that structure and creating the lists of terms, as well as defining rules for governing and applying the tags, is an important step in the design process and one that, if not done carefully up front, can be painful and difficult to fix later. The third way that taxonomy and metadata are built into a CMS is in the authoring templates. Depending on the organization’s workflow, authors may be creating keywords and descriptions in the content input templates and applying tags from the taxonomy. All of this structure needs to be defined and requirements provided to the technical team for optimal implementation.

Templates, both the front-end presentation versions and the back-end content input versions, are another area in which content strategy and information architecture play a key role. They are the experts in what the different content types are, what the requirements for componentization are, how many templates need to be created and what they need to look like and do, what  metadata needs to be present, how digital assets like images and video will be presented. The information architect creates the wireframes for the presentation templates, based on the content requirements provided by the content strategist and to support the necessary user flows and interactive elements. Development of the content input templates likewise needs to be informed by the content and user experience strategies. Most modern CMSes support modularization—content and other assets stored and managed at a granular level that enables published pages to be assembled from components that are tagged for reuse. Decisions about what the appropriate level of granularity is and what triggers the pieces to be assembled and presented (and how that differs on different devices) are the realm of the content strategist and information architect—and most developers will be more than happy to not take responsibility for design at that level.

In addition to the CMS design work, at this stage the information architect is also designing new or improved navigation and user flows, creating the overall structure of the site. The content strategist is managing the actual processing of the content—creation, revision, and tracking through from the old system to the new, making sure that the right content is moved and that it is placed correctly in the new system.

Workflows and governance round out the migration planning picture. With the understanding of how content is created within the organization, how often it is updated or replaced, and what level of review and approval is required, the content strategist can design authoring workflows and write governance guidelines. The information architect, likewise, can stipulate a review and approval process for changes to the site structure, taxonomy, and template design.

Conclusion

Content migrations are generally undertaken with the goal of creating a more capable, robust system that supports current needs and can scale to handle future growth. They provide the opportunity to clean out the old and non-useful and to retain the best of what exists and put it all into a shiny new context. Ideally, they are done when necessary to support business needs, but as seldom as possible. Making the right decisions at the start and calling on the collective talents of the whole team, including the information architect and the content strategist, helps ensure a successful migration and an efficient, user-oriented, easily managed web site.