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?

Ph a se 4: 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.

Phase 4: Content migration and migration tracking

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

Let’s define a migration path

Migrating a live system means downtime. This is not really a problem if all your users are in the same building, but if your intranet extends to an extranet and your users are geographically dispersed and work in different time zones, scheduling an off-peak time in which to perform the migration can become tricky. Local off-peak hours might be a satellite office's prime time.

Ideally your intranet would consist of three separate yet closely mirrored environments: Development, pre-production, and production. The purpose of this is not only to isolate the production environment from R&D, but also to allow for smoother migrations with minimal downtime and impact on the user community. By maintaining separate environments, a lot of the migration can take place behind the scenes—even during the working day.

But not everyone is fortunate enough to have all these resources at their disposal. Unless new servers are purchased specifically for the intranet, existing servers will have to be offloaded and migrated themselves before your intranet migration can take place. It's crucial that you carefully map out the migration path of all components—from their current home to their new home—and the order in which they need to be moved.

But not everyone is fortunate enough to have all these resources at their disposal. Unless new servers are purchased specifically for the intranet, existing servers will have to be offloaded and migrated themselves before your intranet migration can take place. It's crucial that you carefully map out the migration path of all components—from their current home to their new home—and the order in which they need to be moved.

Let’s define contingency plans and procedures

Hope for the best; plan for the worst. This isn't pessimism; it's being prepared. Regardless of how well we plan something, there's always a possibility that something unexpected will happen. Without contingency plans and procedures in place, intranet team members can be caught off guard and become panicky if something goes horribly wrong during the migration. When this happens, survival mode kicks in and the ability to make logical decisions is diminished. Some team members might end up doing things haphazardly and make matters much worse, causing a minor problem to snowball out of control.

Contingency plans and procedures should include, but are certainly not limited to, the following:

Step-by-step instructions on what to do in various situations.

Contact lists of all key migration team members.

Performing full content and system backups prior to the migration.

Rollback procedures to bring the intranet back to a previous state in the event the migration can't continue.

Let’s clearly define and assign roles

With so much going on at one time during an intranet migration, the intranet overseer—or someone appointed as an overseer specifically for the migration—must ensure that team members don't bump into each other and compromise the activities of other team members. A steady stream of communication between the teams is vital. Unfortunately, it's far too easy for teams to put blinders on and see only what's in front of them. But a lot of times, their actions will affect the migration activities of other teams' components.

Your migration plan must explicitly state who is doing what and when. This coordination of personnel and effort is especially important for complex intranets. It might even be a good idea to do a dry run before the actual migration day. As is often the case with intranet migrations, the migration of one component might be dependent on the successful migration of another component. If all of this isn't carefully coordinated, there could be huge traffic jams where teams are waiting on the outcome of another's work.