Avoid the Pitfalls of Intranet Migration

By Paul Chin

Originally published in Intranet Journal (04-Feb-2009)

back back to portfolio

Have you ever moved into a new home completely free of incident? Unfortunately, few of us are lucky enough to have experienced a successful and uneventful move where everything goes according to plan, where movers are on time, where no furniture is nicked by a careless drop, where fresh paint in your new residence isn't marred by the corner of a desk, and where you're not subjected to the movers' dreaded posterior cleavage.

Most moving experiences are calculated in degrees of frustration and measures of severity. Migration of a large-scale, enterprise-wide intranet is no different. Unlike building a new system from scratch, migrations force you to work within the confines of your preexisting intranet components. And you have to do it without causing too big a disruption on the user community and without breaking the system.

A lot of things can go wrong during an intranet migration, but preparation and foresight can help you avoid some of the most common intranet migration pitfalls:

Team members are unprepared or bump into each other

Many technology-based systems fall under the care of IT and require little involvement on the part of the user community beyond saving all their work prior to the scheduled migration period. Intranet migration, on the other hand, involves the careful coordination of technical personnel, the content owners and managers from each intranet section, and to a lesser extent, end users who contribute content (if your intranet allows for user-generated content).

Every person involved with the migration has his or her role to play in order to pull off a large-scale migration. Without careful coordination among the various intranet section leaders and technical staff, team members can end up bumping into each other during the migration process or even undoing what someone else has done.

When preparing for migration of your own intranet section, it's all too tempting to put blinders on and adopt an attitude of "I've got my own worries, let everyone else do what they have to do." But this attitude is counterproductive. What others do before and during a large-scale intranet migration can affect what you do.

Remedy: Draft a migration game plan, listing what will be moved, where each component will be moved, who's responsible for moving which component, when these components will be moved, and how long each process is going to take. You don't need to know all the minute details of what everyone is doing, but you should at least have a big picture view of the whole operation. Also, if it's a complex migration, you can run some war games, a dry run of the game plan prior to the real migration.

You're racing against the system downtime clock

Large organizations will most likely have mirrored servers or separate development and production environments, and dedicated database or content servers. This will minimize or eliminate system downtime. The advantage here is that the intranet migration can be performed during the working day with little-to-no system interruption. Users don't even have to know that anything is happening.

Smaller organizations, however, might not have the luxury of multiple server environments with which to coordinate this juggling act. Instead they will be forced to schedule downtime in which to perform the migration. You're also going to have to provide ample notice so the user community won't be caught off guard. The problem here is that you're working within a window of opportunity. If something unexpected occurs during the migration and the service interruption extends beyond what was announced, the race is on.

Remedy: It's entirely normal to experience unexpected problems during large intranet migrations. The severity of the problem and your ability to handle the situation will determine whether your scheduled downtime will be affected—and if so, how long the interruption will be extended. In order to minimize the impact of a system migration, schedule the operation during off hours or during non-peak hours. Even though some users might be working late, at least you'll only be inconveniencing a handful of users as opposed to the entire user community.

You end up losing content in the move

If you have the luxury of a dedicated database or content server that's linked to by your intranet, you won't have to worry about this. Users can continue to work on their intranet while the migration team operates behind-the-scenes. They can perform the migration during working hours or off hours without interrupting the user community. Once the migration is complete, all the migration team has to do is update the pointer linking the system with the content to reflect the intranet's new home.

But if your intranet content happens to reside on the same server as the production intranet or embedded within the intranet software, you're going to have to make sure that all operation ceases prior to the migration so that no content is added or changed. Otherwise, newly added or modified content might not make it onto the intranet's new home during the migration process.

You also need to make sure you don't lose any data in the event that a post-migration crisis forces you to restore the system to its pre-migration state. The data most likely to be lost in these system rollback situations is the content that's added or changed in between the time the migrated system is put online and the time of the rollback.

Remedy: Perform the migration off hours and shut down the system completely. Even if you're doing the migration off hours, there might be night owls accessing the system or users traveling and working in different time zones (local off peak hours might be prime time in another time zone). Once the system is pulled offline and no changes to data can be made, make full backups so that you'll have copies of the most up-to-date content in case a system rollback is required.

Closing thoughts...

An intranet migration isn't a simple click-and-drag operation. Your level of preparedness and ability to adapt to unexpected problems will determine how smooth the migration will go. You need to consider the integrity of the system being moved, how the migration will affect the user community (and for how long), and how system unavailability will affect your business. If you don't bother taking these very serious matters into consideration, you might find yourself sitting in an empty house while all your belongings are being shipped to a solitary yurt in Mongolia.

Copyright © 2009 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.