Home | GestaltIT | Enterprise Computing: Data Migration Strategies – Part IV

Enterprise Computing: Data Migration Strategies – Part IV

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

This is a continuing series on Enterprise Data Migration Strategies.  Previous posts:

Enterprise Computing: Data Migration Strategies – Part I

Enterprise Computing: Data Migration Strategies – Part II

Enterprise Computing: Data Migration Strategies Part III

So far in this series of posts I’ve discussed the pre-work required in order to get to a position to execute on actual data moves.  In this post, I’ll discuss the migration scenarios and how to ensure data integrity is maintained throughout this process.  The final post in this series will talk about some of the migration tools which may be utilised.

Maintaining Integrity

Migrating data is a pretty simple task.  You could simply copy the files from one volume to another; you could use replication tools like SRDF, TDMF or even the host native volume manager.  However during this process, it is essential to ensure that data integrity is maintained.  If something goes awry during the data move stage, the last thing you want is to be unsure of the position of the last valid copy of your data.  Here’s what could go wrong:

  • The copy process itself fails.
  • The server crashes/reboots.
  • The target storage device crashes, or becomes unreachable.
  • A minor datacentre issue occurs (array failure for instance).
  • A major datacentre issue occurs.
  • Replication or access to a remote datacentre is lost or disrupted.

In addition, consider that a more complex migration plan will be required for hosts which have replicated storage and/or point-in-time clones or snapshots.  If these form part of the business processes on the server, then chances are they will all need to be up and synchronised before the server can be accepted as migrated successfully.

Get The Business Involved

At this stage it may be a good time to re-emphasise something I’ve mentioned already, and that’s making sure you have a good relationship with your server owner.  Obviously they will have been in previous discussions regarding migration, however you need to know from them exactly how the storage on their server is used.  You need to be aware of any business processes which rely on snapshot or other point in time copies of data. In terms of the migration process, you should be developing a business-centric view of the migration steps, which shows at each stage of a complex migration, exactly what the currency of each instance of data is.  Obviously this isn’t essential for every single server within a storage environment, but will certainly be important for the most complex configurations.

Some Typical Examples

Here are some typical migration scenarios:

  • Synchronously Replicated Data.  Host data is mirrored between a primary and secondary array.  Replication is used for disaster recovery.  Here, the migration process must maintain the DR position for the data.  If it’s possible to take an outage then the mirroring can be split re-established to a new replication pair, perhaps by making the new local copy a snaphot clone.  If no outage is possible and the application/server must be kept running then this won’t be an acceptable solution.  In this case another method is required, for example host-based mirroring.
  • Asynchronously Replicated Data. Host data is mirrored between a primary and secondary array.  Replication is used for disaster recovery.  In this scenario, the same issues apply as with synchronous replication, however there’s the added complication of maintaining write order/consistency during the copying or only accepting a checkpoint of the completed copy. 
  • Replicated Data With Local Snapshot.  Data is replicated remotely with a local snapshot for instant data recovery.  This option adds the extra complication of retaining a local snapshot.  If the snapshot has to be retained from a specific date/time, then the snapshot itself will also require copying.  Obviously the snapshot can’t then be associated with its source volume until a new copy is required as it would potentially overwrite the contents.  Where possible (for example with daily snapshots), it may be possible to tie the migration to creation of the snapshot and complete the snapshot recreation after data has been moved to the new location.
  • Three Site Replication.  Data is replicated through an intermediate site.  Here, specific vendor technology is being used to create a multi-hop configuration, perhaps for enabling a mixture of synchronous and asynchronous replication.  The process in which the intermediate copy is used needs to be examined to ensure integrity can be maintained during the migration.  The same previous comments apply, however consideration needs to be given to where any data recovery would take place – so if the intermediate site it not used for data recovery, then the final location needs to provide an acceptable recovery point.


Where complex replication techniques have been used then data migration needs a little extra thought to ensure consistency can always be maintained.  Hopefully most servers won’t fall into the complex category, but having a list of migration scenarios to meet each configuration type is essential to making sure migrations run smoothly.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • http://www.smablog.org Laurence Davenport

    Hi, this series is an interesting read, thank you. I wondered did you have any view on using storage virtualisation technology for aiding the migration process as this has helped out hugely on a number of projects I have been involved with.

    However the decision to go down that route needs to be nailed right early on in the project so that every design decision takes the virtualisation into account.

    Interested to hear you view.

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×