Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure
One of the more entertaining debates in storage today is Replication - whether asynchronous or synchronous, hardware-based or software-based, to-disk or to-tape. And in almost all cases, the goal is for data protection (often referred to as High Availability (HA) or Disaster Recovery (DR)).
The problem is that this actually minimizes the overall benefit of replication to merely "data protection solutions." High availability and disaster recovery are part of a bigger picture - that of Business Continuity (BC), and BC is about continuing business operations in all situations. HA and DR are to address unexpected outages to the computing environment, but what about planned outages like Migration projects?
Over the past twelve years, I have been involved in too many migration projects, and have learned that it doesn't matter whether you are migrating from Windows NT4 to 2000, from an older server to a new one, or from direct-storage to NAS/SAN - the rules of migration still apply:
- The project starts after-hours on Friday (since the users cannot be on the system).
- There is, almost always, a specific step that is thought of as the "Point of No Return," where some non-reversible change will be done. At that phase, you are committed to completion.
- And, if the project is not looking successful by Saturday evening, then the recovery process must begin to ensure that the old system is back on-line by Sunday night.
These conditions are particularly true for "in-place" upgrades (i.e. where the OS is upgraded on the system rather than the data being moved to a new hardware platform) where the point of no return is shortly after starting the upgrade. If it doesn't complete, you better have a current back-up.
When these conditions are considered as a whole, it translates the term "Migration Project" into "Lost Weekend." And if the project is sizable, it translates as "Lost 3-Day Weekend." This reality was my wife's biggest complaint about I/T as a profession (not withstanding the Saturday urgent pager interruptions and the stellar pay).
But, does it really have to be that way?
Replication technology is now widely available as a reliable method for providing a second (and even third) copy of your data - in a non-impacting manner to your production environment. Typically, we look at replication technology (in its many forms) only for data protection. In actuality though, replication can be thought of as a tool.
Instead of starting the migration project on Friday night, why not installing the new platform on Monday afternoon and then beginning replication from the existing platform? If the replication takes two days (in a controlled or throttled environment), then the new platform will be ready for production by Wednesday. Then, simply spend Thursday and Friday redirecting users (via login-scripts or mappings). First, re-direct some test users and when successful, everyone else. If there is a problem, you can find out immediately - and the original platform is still available and on-line.