paulchinonline.com

Move It on Over: Intranet Migration Basics

By Paul Chin

Originally published in Intranet Journal (10-Jul-2006)

back back to portfolio


Migrating a complex, high-volume production intranet can make developers and content owners feel as though they're trying to make major repairs to a ship's hull while it's sailing through the Bering Sea. A production intranet is in constant motion, involving anywhere from one to several dozen active content managers feeding and updating the system at any given time.

This, in addition to all the in-house and remote users who rely on the timely availability of information contained within their intranet, can make anyone feel a bit skittish about moving a production system. This, however, is unavoidable. As an intranet makes its way through the natural progression of its lifecycle, it will eventually need to be upgraded or migrated to meet new user requirements and technical demands.

With so much going on, how do you migrate a live intranet—whether it be hardware, software, or both—in parallel with ongoing content activities without adversely affecting the user community, or worse, the system itself? It involves an understanding of what needs to be migrated, and having the knowledge and ability to execute the whole operation with minimal impact on the user community.


Determine What Needs To Be Migrated

The effort required to migrate an intranet, as well as the impact on the user community, will depend largely on the size and complexity of the current system. Not all intranet migrations are the same; they can involve just one, several, or all of an intranet's components. Small, single-server intranets with few database applications will obviously be much simpler to migrate than high-volume intranets that connect to multiple application and content servers.

Few organizations have the financial luxury of buying new equipment whenever it's needed. Companies are more likely to recycle its resources. This is usually done by offloading demanding, high-traffic systems and putting them onto more powerful servers, and moving less demanding systems onto the newly vacated machines. In some cases, an intranet migration can't even get under way until another completely unrelated system migration is completed to free up the intranet's new home. Understanding what needs to move in this "dance of the servers," and in what order, will be crucial to a successful system migration.


Intranet Component Migration Examples
Component Examples
Content Offloading content residing on an intranet server and placing it onto a dedicated data server, changing content structure, changing content type (e.g., from plain HTML to a database).
Server software Upgrading to newest version of a particular Web server software, changing server software from one to another (e.g., migrating from Apache to MS-IIS, or vice versa).
Server hardware Upgrading to a more powerful server to handle increased user traffic and I/O intensive database applications, accommodate changes in corporate server and application architecture.
Intranet applications Changes in application development languages (e.g. ASP to JSP, or vice versa), changes in database (e.g. from simple MS-Access to Oracle or DB2).

Maintaining Multiple Environments

If you're a regular reader of my Intranet Journal articles you'll know that I'm a proponent of maintaining several mirrored environments during an intranet's lifecycle. I've repeatedly warned of the dangers of tinkering around with a live system—something that every IT professional should already be aware of.

Ideally, intranet developers and content owners would have three separate environments in which to work with: development, user test (or pre-production), and production. If resources are limited, the development and user test environments can be combined. This will safely shield the production environment from any R&D or debugging activities. These controlled environments are beneficial not only for development and testing purposes, but also for system migrations.

Controlled environments provide developers, content owners, and testers with parallel mirrored systems so that the production system remains unaffected by any migration initiatives prior to the actual day of migration. They also facilitate fail-safe measures such as system rollbacks in the event something should go wrong (this will be discussed a little later in this article).

Intranet Environments
Environment Uses
Development Strictly used by intranet developers and designers. Used for testing usefulness and feasibility of new technologies and tools, debugging the production system, testing alpha and beta versions before handing it off to the user test stage.
User test
(pre-production)
Used for testing purposes by a select control group after the developers have implemented all their upgrades and performed their own tests. This environment's content mirrors the production environment's content as closely as possible. All finalizations are performed here—fixing additional bugs, minor cosmetic changes, resolving issues discovered by the control group—before the system goes live.
Production The live system accessed by the organization's user community and managed by content owners. Absolutely no testing, debugging, or R&D is done in this environment.

Working with Users and Content Owners

Beyond the technical issues I've mentioned so far, perhaps the trickiest part of an intranet migration is minimizing its impact on users. Well-planned and executed migrations will occur behind the scenes and appear seamless in users' eyes. But if things go wrong and you start airing out your technical dirty laundry, they might not be so understanding. Users aren't concerned with anything having to do with servers, migration environments and paths, or parallel systems. They just want to get their work done—and can you really blame them?

If your intranet and content reside on the same server, you'll need to schedule a certain amount of down time during off-peak hours so that content owners don't end up adding new content while developers and system administrators are performing the migration. Otherwise the new content being added during the migration won't be moved along with the system.

While it's typical for intranet owners to perform system migrations during off-peak hours when impact on the user community can be minimized, mission critical intranets with an international user-base scattered across a dozen different time zones (accessed via an extranet) can make the scheduling of a migration a bit trickier.

Whenever an intranet needs to be migrated—mission critical or not—intranet owners must communicate their plans to their users so that they're not caught off guard. They must be given ample time in which to prepare for the service interruption. After all, intranet owners aren't always in tune with everything their users are doing—especially those in remote locations.

A group of remote users in a satellite office in Sydney, Australia, might need their intranet at the time a system migration is planned at the organization's headquarters in New York. Your off-peak may very well be someone else's primetime.


Post-Migration Safety Measures

Regardless of how well planned the migration, there's always a chance that something unexpected will occur. At bare minimum, key intranet migration team members must ensure that:


Rollback Measures

A rollback plan depends on your particular intranet and content architecture. When system and content reside on the same server rollback is trickier because, while you can always rollback the system, the content may be out of synch. You might run the risk of losing the content added in between the time the new system was put into production and the time of the rollback—at the very least, you'll have to move all the content into their respective locations manually.

If, however, the system and the content reside on dedicated servers, you'll be dealing with a single set of content that will always be current regardless of what happens to the system. There are no issues of data synchronization between new and old systems. Updating or rolling back simply involves pointing the respective system at the production data server.


Post-production Support

Intranet migrations can be quite taxing—especially when you're dealing with multiple servers that need to be migrated in a very specific order. On migration day, those involved directly with the migration will probably spend regular business hours planning what needs to be done with their respective teams and after hours performing the actual migration. Some more complicated migrations can take a considerable amount of time to complete, from team coordination to dry run to production.

When all's said and done, it might be tempting to take the next few days off to recoup. After working so many hours straight, most people will just want to go home and sleep. But it's important for key migration team members to be on-site after the migration to ensure smooth operation—at least for the next few days. Testing in a controlled environment with developers and control groups won't always yield the same results as real life usage in a production environment.


Closing Thoughts

Migrations aren't always easy. If you're only dealing with a simple server-to-server migration, you're golden. But more complicated, multi-server migrations involve a lot of pre-planning before the migration even takes place. System migrations are one of those things that fall under the IT precept "We suffer so users don't have to", and should never cause undo stress on the user community. Regardless of what intranet developers and content owners have to do behind the scenes, users' exposure to the migration process should involve little more than a minor interruption of service.

This has been a very high-level discussion of intranet migrations. In a future article I'll get into the nitty-gritty of the migration process from pre-planning to coordinating migration teams to detailed system rollback measures.


Copyright © 2006 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.