This article can also be found in the Premium Editorial Download "Storage magazine: Tools for successful data migrations."
Download it now to read this article plus other related content.
|Why migrate data?|
Testing requirementsMigration testing should include both storage and applications. Storage-related testing ensures that the data was moved from Platform A to Platform B. If the migration is completed offline, the testing should include a comparison of pre- and postmigration volumes, number of files,
number of database records and so on. Running a checksum is optional, but it could take a long time depending on the volume of data. If the migration is completed online, it's harder to measure these parameters. It's helpful to perform a mirroring migration in phases by dividing the volumes to be migrated into a series of smaller, sequential migrations.
App testing requirements will vary depending on the applications. For environments under regulatory control, a more detailed level of testing is probably required. The team should consult with the internal QA staff or compliance officer to determine the exact requirements. At a minimum, it's prudent to develop and document pre- and postmigration app tests. Running tests on the original and migrated data ensures the successful operation of the app prior to "turning off" the old storage. Some key testing milestones include:
- Developing test scripts to run pre- and postmigration
- Comparing pre- and postmigration test results
- Verifying the ability of the app to read from the target storage
- Verifying that pre- and postmigration reports or analyses are identical
- Explaining any differences that might be expected
Back-out planningTo minimize downtime, adequate back-out planning is recommended. At each Go/No-go decision point, the team should determine if the migration can proceed and, if it can't, execute the back-out plan. Go/No-go points may occur at the completion of the migration and storage-related testing, at the end of app testing or other logical points in the migration plan. Depending on the migration method, back-out actions can include tasks like not disconnecting the old array, not exchanging mounts points, reactivating source volumes groups or restoring from tape if data becomes corrupt.
PostmigrationWhen the migration is complete and all apps have tested satisfactorily, disconnect the old array's cabling or break the mirror as soon as the postmigration testing is complete. If required, the storage array may be repurposed for other roles such as another tier of service or development. Finally, complete the paperwork for the migration and testing documentation, and obtain the necessary sign-offs. A postproject review can be helpful in identifying areas that can be improved to reduce risk, improve the user experience or reduce the cost of the migration effort.
This was first published in September 2005