Guest Blog: Data Migration – Failing to Plan is Planning to Fail

Data Migration: Failing to Plan is Planning to Fail [Step-By-Step Guide]
So, you’ve purchased a shiny new data storage array, and you’re now faced with the often-times daunting task of moving your data and servers from the old to the new array with the least disruption possible. Compounding the problem, data migrations are typically high-profile, high-visibility projects with “C-level” interest due to the risk involved and the sensitivity to the business application owners and end-users, even more so when there are revenue generating and budget concerns.

So where do you begin?

The old axiom “failing to plan is planning to fail” is especially true for data migration projects. In fact, devoting plenty of time to the planning and discovery phase of the project, gathering information, and understanding the existing environment, is critical to your success.

This is the first of a three-part series in which we will discuss this very topic and how to appropriately prepare for and execute a data migration plan/project that will bring you success.

Planning and Discovery – Key Elements to Consider

Documentation of the Environment
Documentation at this phase of the project serves multiple purposes:

1. Serves as a reference for checking compatibility with new SAN/storage

2. Serves as a communications tool between members of the project team

3. Used as validation during the setup of the actual data migration phase of the project

4. Ultimately becomes an as-built deliverable for the project

The following items should be examined and documented during the planning and discovery phase of the project:

1. Server operating system type and version

2. Fiber channel HBA model and firmware/driver versions

3. Multi-pathing validation

4. SAN switch software versions and general over-all health

5. Existing SAN zoning information including world-wide port names and aliases

6. Identification and list of source array LUNs and their sizes for each server

In addition, the documentation should also include place-holder entries for the following items:

1. For the destination storage array: target ports, storage pools, and LUN identification

2. New zoning information

Migration Event Planning and POCs
Once discovery is completed and documented, it is then time to discuss and agree upon the individual migration “events”, or “waves.” Consider including test and/or development servers of each operating system type in the first migration event as a proof of concept (POC) exercise. Doing a POC gets the everyone on the team familiar and comfortable with the entire process without affecting production servers and data. Make sure any change control processes are considered and addressed prior to any scheduled migration event and server cut-over. Maintenance windows need to be scheduled ahead of time and the user community needs to be notified well in advance of downtime.

Replication Considerations
Be sure to consider any existing local and remote replication requirements. Do you have Recovery Point Objectives (RPO) and/or Recovery Time Objectives (RTO) that must be strictly adhered to during migration? If so, remote replication must be configured on the destination array BEFORE post migration and server cut-over is executed. Local replication such as snapshots and point-in-time copies will need to be reconfigured on the new array.

Remediation
The planning and discovery documentation is used to check the existing infrastructure against the new storage array manufacturer’s support and compatibility matrix. Any part of the data path that is not in compliance with the new array must be remediated, either before or during the server cut-over phase. The recommended software, firmware, and driver versions should be communicated as part of a remediation report and reviewed by the entire data migration team.

Conclusion
Discovery and planning are paramount to the success of a data migration project. Invest the time up front to get the existing environment documented. Determine what and when will be migrated by agreeing on the migration events. Don’t forget replication! Make sure the team agrees and understands what remediation of the data path may be required. These steps will help turn the transition of your data to the new storage platform from stressful into successful.

This post – Data Migration: Failing to Plan is Planning to Fail [A Step By Step Guide] – originally appeared on the Headwaters Group blog and is reprinted here by permission. Headwaters Group is an authorized Cirrus Data Solutions Inc. Partner. To learn more about the CDS Data Migration Server, visit the DMS Product Page, or contact Cirrus Data Solutions Inc. or Headwaters Group.