2/4/2008

Go to page: 1 2  Printer Friendly Version

Every first of July, Canadians from coast to coast celebrate the establishment of Canada as a self-governing country, but for residents in the province of Quebec there's also another longstanding tradition: Moving Day.

Moving Day has become an annual tradition. Narrow streets are bottlenecked by convoys of moving trucks and trailers, and sidewalks are littered with discarded belongings that movers tossed out simply because they don't want to move any more than what's absolutely necessary.

Intranet owners, like these migratory tenants and homeowners, must occasionally go through the very similar and unavoidable process of system migration. Intranet migrations are undertaken for a variety of reasons, the two most common being site consolidations and modifying or upgrading system architecture . But before packing up all your digital belongings and carting everything from one location to another, there are five key questions intranet managers need to answer:

More From Jupitermedia

10 Open Source Apps for Enterprise Users Why Ubuntu Linux Tops Debian IDM Dreamweaver Tutorial Creating a PHP-Based Content Management System Top Intranet Trends: Usability, Access, Personalization The 2008 IT Salary Guide If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor. FREE IT Management Newsletters bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet HTML DRM Watch HTML

1) 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. A migration can include one, several, or all these components. 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, you'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.

2) What is your 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.

The importance of this coordination and planning is heightened if full intranet consolidation and standardization hasn't taken place yet, and you're dealing with a motley collection of hardware, software, and technologies. Or maybe consolidation and standardization is your migration. Whatever the case may be, an intranet migration plan needs to spell out:

What will be moved.

Where each of the various components will be moved to.

Who is responsible for moving which components.

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

What re-coding and/or re-configuration, if any, will need to be done to complete the migration.

It's never fun having to migrate a live system because doing so 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.

Go to page: 1 2  Printer Friendly Version