Intranet Migration Guide by Exponent Logic

4 phases of intranet content migration

With the deployment of a new technology platform for the intranet comes the task of migrating content from the old site. Outlined here are the 4 phases of intranet content migration that we will work with you on defining to insure the success of your intranet. Be mindful there are a variety of related terms, such 'intranet content inventory' and 'intranet content audit' and 'intranet content migration'. Some people use these terms interchangeably, but there are a few key differences that are important to make clear.

Phase 1: Content inventory for the old intranet

The first step is to figure out what content you already have. Usually it lives on your old intranet, though many intranet projects seek to move content from other repositories, such as shared drives, to the new intranet.

Key questions for a content inventory:

Who owns it?

Where is it?

What format is it in?

Phase 2: Content audit

During the intranet content audit phase you will analyze the content and make decisions about how to deal with it. The content audit often overlaps with the content inventory, in which case you may be making decisions as you chronicle the content you find.

Key questions for the content audit:

What do we keep?

What do we delete or archive?

What needs to be improved?

What should be shifted to a more user-friendly format?

What new content do we need?

Phase 3: Content migration mapping

This is the stage where focus fully shifts from the old intranet to the new one. Before you go forward with content mapping you need to solidify the navigation for your new intranet, which we cover later in this article.

Key questions for content migration mapping:

Where does it go on the new site?

What is the most important content?

What should be moved first?

What should be moved first?

Who is responsible for moving the content?

Phase4: Content migration and migration tracking

There are 5 Key areas for components in migration we need to establish:

Define what is being migrated

Intranets are made up of multiple components: Static content, dynamic databases, design elements, applications (possibly developed using disparate computer languages and technologies), server software, server hardware. Perhaps various department databases are being consolidated onto one server; perhaps the entire intranet structure is being ported to accommodate a new security model; or perhaps the current batch of servers just can't handle the increase in user traffic. By figuring out what components need to be migrated, we'll be able to determine the plan and path of the migration as well as the amount of time, effort, and personnel required for the task.

Let's create a migration plan

Intranets are unique in that they're not owned by any one particular group. Unlike other corporate-wide applications that fall under the domain of IT or a specific department, intranets are usually governed by a multi-departmental and multi-tiered committee. As such, intranet migrations require careful coordination and planning among all stakeholders-IT, business analysts, and content managers and an intranet migration plan needs to spell out:

What will be moved.

Where each of the various components will be moved to.

When the components will be moved, and in what order.