Data Migration: Tools and Methodologies//

// // // // <![CDATA[
function bb2_addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {

bb2_addLoadEvent(function() {
for ( i=0; i // // //

By Prashant Shah, , ,

A blog post about data migration in 2014?!? Isn’t everything virtualized and Storage vMotion the way to go? And these days, if the topic doesn’t have the word “cloud” in it, is it even worth talking about?


It is true that VMware Storage vMotion has greatly changed the data migration landscape. We simply stand up the new array and present the LUNs to the ESX cluster and the VMware dudes take over from there. What used to require a lot of planning and create a lot of anxiety has been reduced to a few clicks and no downtime! Data migration projects I’ve been involved in have declined significantly over the years, and I’m not complaining—because doing data migrations is not how I like to spend my nights and weekends.

However, there are still plenty of clients with physical hosts, and they need to figure out how to get the data from an older array to the new one (VNX/VMAX). Many of these clients are implementing Unified VNX models and we also need to have a data migration strategy for NAS (moving from another NAS platform or a physical file server to a VNX/Isilon). At any given time I’m involved with a couple of migration projects. It’s definitely not as crazy as it used to be, but plenty of migration work is still done regularly. Many of our clients have legacy systems and applications that cannot be virtualized. And even if they can be, they are critical enough that the whole “if it ain’t broke, don’t fix it” thing comes into play. If it weren’t for tech refreshes and the need for better performance, it’s doubtful they’d even consider doing a data migration, let alone pursue virtualization.

What methods can we use to migrate? Host based? Array based? Combination of both? We have quite a few proven and solid tools to choose from. Obviously, the tools discussed here are not the only ones, but these are the most commonly used. Let’s look at them in more detail:

Host Based

Open Migrator

This is a free program that works with variety of operating systems. It has been out for quite some time, meaning it is a proven tool with much good documentation, but is also a little outdated. The source can be a non-EMC array, but target must be EMC. You can migrate to a target volume that is larger. Byte copy means it takes less time than block copy tools. A major drawback to this tool is it requires two to three reboots during the whole process.

PowerPath Migration Enabler (PPME)

The go-to tool for migrations these days is PPME. If you own a licensed version of PowerPath, you can get a PPME host copy license at no charge. It supports a variety of operating systems and is completely online. No downtime required in almost all use cases. With the recent release of 5.7 version, it makes MSCS cluster migrations easier as well (no need to shut down the second node).

UNIX logical volume manager

Until recently, most UNIX flavors were best migrated with an array-based tool. However, I have, thankfully, not been involved with the UNIX side of things in my last few migrations. Client UNIX admins have been using host-based volume manager mirroring tools to simply copy over the existing array volume groups to the new array volume groups. In theory, very similar to the PPME approach.

Array Based

SAN Copy

SAN Copy is one of the most familiar tools to migrate from any source to EMC target. It is also supported for migrations within EMC platforms. Since there is no host involved, set up is simple and copy process over FC is very fast. The only drawback is that it has to be kept in-sync by doing incremental sync manually.


When migrating from a CLARiiON to a VNX or between VNXs, MV/s is the tool of choice for array-based migrations. Simply zone the two arrays together, establish the source-target pairs, and let it go. Once it finishes the initial sync, it will continue to replicate synchronously. The actual downtime when cutting over is brief. It’s a block-by-block copy, so the target is absolutely identical to the source and it works across all OSs very well.


Although RecoverPoint is primarily a replication product, many clients have successfully used it to migrate LUNs between data centers. Recently we had a client that was physically moving servers from one data center to another. Since the RecoverPoint environment was already there, we leveraged it to copy all the LUNs to the array at the new data center location and then moved the servers to the new data center. Similarly, it can be used during array refreshes to migrate from old to new.


Like RecoverPoint, VPLEX is also a multi-purpose solution. It can be used to migrate during tech refreshes and we have successfully utilized it for numerous projects. VPLEX encapsulates the new array and then mirrors data from the old array LUNs to the new array LUNs. Once the copy is done, you simply dis-associate LUNs on the old array and you’re finished!

NAS Migrations

VNX IP Replicator

When moving from a Celerra or VNX File to a new VNX File, this is the way to go. It’s easy to set up and fully supported by EMC. There is no need to run manual incremental sync process as it continually replicates changes to the target file systems. Also, since it’s file-system based and not tied to a protocol, CIFS and NFS both are migrated with this same tool. The actual downtime is relatively brief when cutting over. As long as you prepare the source properly (and there are some special considerations), there is no need to recreate the CIFS servers/shares/quotas/etc. once you migrate. Everything stays intact.


Both of these are free tools and work well for CIFS migrations. Robocopy is a Microsoft utility and EMCopy is EMC developed. We almost always use EMCopy. Since it’s an EMC-supported tool, if you run into issues you can open a ticket and get professional help. It is also very reliable and fast, with multi-threaded operation. You can adjust the number of threads to take full advantage of available resources. Both of them are highly customizable, with many switches to preserve share permissions, time stamps, propagate deletions, etc.


For NFS exports, we use Rsync to copy files from the current NAS to the new file system. Like the CIFS tools mentioned above, there are many switches to customize the options to suit your specific environment.


When architecting a data migration project, we do plenty of planning and analyzing to make sure the right tool is chosen and that the source and target environments are at supported levels. There is always some remediation required on the hosts or switches or even the arrays to match the latest support matrix. Even then there is risk involved—and a rollback plan, in case we can’t get the work completed in the given downtime period.

At AHEAD we have experts across all the tools mentioned here and more. Please contact us at for further information.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: