Lessons learned: Data Migrations (VMs or otherwise)

Monday, June 20, 2011

imageWhether you are moving files, Virtual Machines or other types of data from SAN to SAN or LUN to LUN, there are a few guiding principles that can help prevent long late nights of troubleshooting and apologizing. Smile 

  • Verify all systems are in working condition – If something (Virtual Machine, OS or Application) is broken before the migration, it will most likely be broken as much or more, after the migration. Verify the working condition of applications and VMs BEFORE migrating so you are not chasing ghosts AFTER the migration.
  • Verify there is enough room to migrate all the data from Point A to Pont B.  Try to determine best practices on distributing data across RAID sets, shared volumes and datastores.  Note whether the source data is thin provisioned, deduped or compressed on the source and that the formatting will remain intact on the destination BEFORE the migration.
  • DO NOT move critical data during business hours. These systems are best moved (even if no perceived downtime is anticipated) later in the day presumably when people are commuting home or sleeping. Things go wrong and it is better for everyone involved when they happen outside of business hours.
  • VERIFY your backups. Verify your Backups. Verify your backups. Try a restore here and there to PROPERLY verify your backups.  You may have successful backup jobs but you do NOT have verified backups until you successfully test a restore.
  • Verify your support contacts (Phone numbers, emails, response times, and contracts) and let appropriate people know the schedule at which you plan to migrate data if possible.  If something goes wrong, it is comforting to know who to call and if they are likely to answer.
  • Create a spreadsheet outlining the systems to be migrated. Size and time to migrate are also useful pieces of information on this spreadsheet. Note any important information that could be lost during migration. (IP addresses, local Admin Passwords for instance).
  • Know the local Administrator passwords for ALL SYSTEMS. This is useful when an Active Directory goes down or a system loses its IP settings and network connectivity.

This list is by no means complete; so please feel free to add your favorites in the comments.

Next Post »