Guest Blog: Data Migration – The Cut-Over

This is the third and final part of a three-part series in which we will discuss the “cutover” phase of data migration. We will cover what needs to happen with each server in your environment to move them from old to new storage.

The cutover typically involves the following:

1. Submission of change control requests for maintenance window approval

2. Remediation

   • Removal of old multi-path software and installation of new multi-path software

   • Updating of HBA drivers/firmware

3. Installation of vendor-recommended host-based software and/or tools

4. Re-cabling of servers (if migrating to new SAN)

5. SAN zoning to new storage

6. Post cutover verification of storage and application viability

7. Re-establishment of replication

8. Optional shredding of old data

9. Before we take a closer look at each of these items, lets do a quick re-cap.

In Part 1, we discussed the elements of Planning and Discovery which includes:

1. Documentation of the environment

2. Migration event planning and POCs

3. Replication considerations

4. Remediation

In Part 2, we discussed the “mechanics” of data migration, covering two main topics of discussion:

1. Host-based approach to data migration

2. Appliance-based approach to data migration with the Data Migration Server (DMS) from Cirrus Data Solutions

The Cutover Process

Now we are in the final phase of the data migration process. It is assumed at this point that data has been initially copied to new storage and that periodic delta updates are occurring. The DMS appliance will show the migration session in “Pending Complete” status, meaning that the appliance is applying delta updates and waiting for the administrator to complete the migration session by applying the final delta synchronization.

The cutover process should be a highly orchestrated effort between the project manager, the system administrator(s), storage administrator(s), DBA(s), and application owner(s). It is vital to have everyone on a conference call and to step through each step of the cutover process, item by item, with verbal acknowledgement of completion of each step.

Change control requests

Prior to cutover, you will need to request an outage window in order to take down and move servers from old to new storage. Most sites will attempt to do this in an already designated maintenance window. Regardless of whether the outage will be a special one-off or somewhat planned, you should follow your normal change control process to seek approval for the cutover and to notify all those involved of an impending outage. You should allow time for multiple server reboots during the outage window, with a minimum of 4 hours per server as a safe starting point.

Once the maintenance window opens for each server, you should proceed with the following steps.

Remediation

Using the information gathered during the documentation phase, the first step is to follow through with any remediation that is required for the new storage. This would entail removal of previous vendor’s multi-path software and installation of new vendor’s multi-path software. If the old and new software involve the same vendor, then multi-path software is usually updated to the latest version. In the case of Linux with dm-multipath, it is advisable to make copies of any current configuration files for safe keeping, then making new copies with the required modifications ahead of time.

You will also need to install the new vendor’s recommended drivers and firmware for your fiber channel HBAs. In some extreme cases where server hardware is 5 or more years old, you may need to replace 2 and 4 Gb/s HBAs if the new SAN no longer supports them.

Installation of recommended vendor software

This typically includes additional, optional software from the vendor that assists with administration of storage. Examples include HPE’s Host Explorer software for 3PAR and the EMC Unisphere Host Agent for VNX. Some of these optional server software items may require additional pre-requisite software items, especially on older operating systems such as Microsoft Windows Server 2003. Installation of these items may require reboots.

Re-cabling

If you are also replacing SAN fiber channel switches as part of the migration, cables will either have to be moved during cutover, or new cables should be run ahead of time. Once the server is shut down, the server is re-cabled to your new SAN by unplugging the old cables and plugging in the new.

Zoning

SAN zoning is changed or added to include new zones for the servers to access the new storage array. Single initiator / multiple target zoning best practices should be followed.

Verification

Once the server is booted on the new SAN and storage, you must run through verification to make sure all LUNs and file systems are mounted in the proper place, multi-pathing is working, and all applications successfully restart. If modifications are made or problems are fixed, it’s highly recommended to do one more sanity-check reboot to make sure the server comes up cleanly. The application owner should also verify that the application is responding and working as expected.

Replication

If you also have new storage at your Disaster Recovery (DR) location, this would be the time to re-establish replication. If you have very tight RPO requirements, the replication could be re-established prior to the completing of the DMS migration session (when in Pending Complete status). Just keep in mind that the initial synchronization between the primary and DR array will be a full copy. Some sites will initially install the DR array in the local data center in order to use fast connections between the two arrays, suspend replication, de-install the DR array, move it to DR location, then re-establish replication. Obviously, doing this is only an option if you can tolerate the extended RPO/RTO that this method requires.

Optional data shredding

The DMS appliance has the ability to “shred” the data on your old storage array. This is an optional step using the appliance. If you are disposing of the old storage array, you should consider data destruction, either using the DMS appliance or by some other means so that access to that data is rendered impossible.

Conclusion

The cutover process is the final step in completing your data migration. It involves multiple steps and should be a highly orchestrated event. Allow adequate time for the cutover of each server and try to do things in a concurrent manner. You should complete any remediation items as outlined in the first phase of the project, do any software removal/installation/re-configuration as required, make the necessary infrastructure changes (re-cabling and zoning), and verify that everything comes back up as expected.

Be sure to re-establish replication according to your RPO/RTO requirements. Also consider how you intend to destroy data on the old storage array before it is removed from the data center.

This post – Data Migration: The Cut-Over [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.