So, you've decided to migrate to san or NAS? Take back your weekends. (Storage Networking).

For many large IT environments, the question of moving to centralized and optimized storage is not an "if" but a "when." While many will argue about vendors or standards, the positive benefits of managed storage are hard to refute. But what about the nasty problem that immediately follows that technology decision: "How do you migrate the data?"

Over the last several years, I have done several kinds of migrations and can go on record as saying that those projects were the most painful, not only to me but my IT team and also my family. The reason being that a "migration project" always translates as a "lost weekend." There is a reason that "migrate" and "migraine" have similar spellings.

Migration projects may be application-centric, such as SQL7 to SQL2000. It might be operating-system-centric--such as going from Windows NT4 to Windows 2000 Server. It might be server-centric--such as moving from a Dual-Pill server to that new four- or eight-way server. Or, it might be moving from local-storage to a SAN or NAS--but the project requirements are almost always the same:

(1) Starting at 7 p.m. on Friday, confirm that all users are no longer on the system.

(2) Conduct one last backup of the current environment and then verify it via restore. Note, this step often gets ignored in the interest of saving time but at the risk of not being able to recover.

(3) Then, begin moving the data or installing the upgrade (i.e. the "migrate").

(4) If necessary, change client software, redirectors, or settings.

(5) Verify full functionality by 6 a.m. on Sunday, or bring restoration back to original state.

(6) Try to be done by dinner on Sunday night.

The reason for this schedule is two-fold. The data/app/OS cannot be changing during the upgrade, so the users must be locked-out. And there is usually a very definite point of no return where something significant is changed, making a recovery window mandatory.

Thankfully, there is a technology that negates both of these problems, but is usually only associated with disaster-recovery or high-availability solutions--replication software.

The Big Picture of Business Continuity

Actually, both of those approaches are part of the bigger picture of business continuity. Business continuity is really about any and all efforts to ensure that business functions continue and resources remain available. So, eliminating the scheduled weekend outage is a valid business continuity activity.

That said, we should look at the newer replication offerings. Replication works by first identifying data or drives on one or more production servers, and then doing an initial base-line mirror to an alternate server. If the target server is in the same proximity as the source server, and the source server were to fail--the target platform can failover and act in its place. That is high availability of the server resource. If the target server is in a different locale from the source server, the data will now survive any significant outage of the production location--including power failures, fires, natural disasters, etc. That is disaster recovery for the data. Both of these, married to the right processes and people, result in part of any large company's business continuity plans. But these solutions start with the data being replicated in close to realtime, to an alternate platform--and being transparent to the users.

So, if replication software is able to maintain a second copy of the data on a nearby server (a copy that is both current with the original but is done without impacting the users), then why not use it to build the migrated server/platform?

If you are migrating to a NAS, then select one running as a Windows-powered appliance (which includes IBM, HP, and Dell). Then, you are simply replicating from a Windows server to a Windows NAS. If you are migrating to SAN, then you are actually replicating from your original server to a new platform that has SAN attached storage (still server-to-server). Or, to do an inplace upgrade to SAN, you are simply replicating from a D-drive (local storage) to E-drive (SAN-storage). For non-storage migrations (such as NT4 to Win2000 or one CPU to another), the results are the same--it is still just replication of the data between two server platforms.

Consider this project plan, instead:

(1) One evening, install the replication technology on the source server(s). This is usually done after-hours, since it is installing an application on a production resource and also because most replication technologies require a reboot upon installation. Anticipated outage time is less than 30 minutes.

(2) During the business day, set up the new platform (which in the case of this article would be to initialize the NAS or SAN solution) and implement the replication technology on this new target.

(3) Since the mirroring and replication occur while the users are still operating on the production platform, most of the requirements for the weekend outage are nullified.

(4) Once the mirror is complete and replication is keeping up, then the users can be switched, at will, either during the week by department (if they share data) or individually (if they don't).

Recall our two primary requirements with migraines (oops, I meant migrations)--that the users be dormant so that the data is stagnant and that a restore window is possible to recover from the point of no return.

* The data does not have to be dormant with a replication technology, because up until the second that a particular user is switched from the original platform to the new solution, that person's data is current on both technologies.

* A recovery window is not required; since if a problem appears with the new solution, the original platform is unscathed and can be brought back into production immediately.

With neither of these requirements still holding merit--then replication software can be thought of as a weekend protector. Combined with its other approaches for high availability and disaster recovery, more and more companies are integrating replication into their core IT functions.

Perhaps, a better way to think about migrations is as anticipated interruptions of a business resource. From the users' perspective, all that they know is that the resource will be unavailable. And typically, the users look to IT to have answers on how to protect against unavailable resources. And the tool that answers that-high-availability goal is the same tool that answers migrations as well--because it always comes back to the idea of "What if you had more than one copy of the data to work with?"

One of my wife's favorite discoveries of technology is replication software--because it significantly reduced my weekend migrations. Come to think of it, it reduced my migraines, as well.

Jason Buffington is the director of technical marketing for NSI Software (Hoboken, NJ).

www.nsisoftware.com