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.
Data migrations are becoming a more frequent part of a storage administrator's workday. A data migration is a complex operation, whether undertaken to improve performance, merge data centers or simply to refresh storage gear. And because they're so complicated, many migrations run into issues that delay or stop the process. The following steps will help you to avoid hidden issues and prepare for a successful migration.
Most migration projects kick off with a feasibility study to determine if the project will reduce cost, risk or improve the user experience. At this stage, the project's concepts are articulated to relevant staff members and, in some organizations, the project is officially sanctioned at this time.
The planning process is next. During this time, the project team determines the best approach for the migration and addresses any risks. At this stage--or earlier if possible--it's important to identify the appropriate level of sponsorship for the data migration. The right level of sponsorship can also help to "grease the skids" for setting up meetings and getting responses to requests. A director from the business side is usually the most effective sponsor to help alleviate the typical issues that arise between IT and business groups. A strong and simple communication plan is paramount to a smooth migration project.
|Checklist of migration activities|
Scheduling the migrationWhile there are several ways to arrange, coordinate and schedule a migration, minimizing the impact on business users should be a primary focus. Scheduling the migration based on business needs rather than on the IT department's desires should be factored into other facets of the migration such as the manpower required for the project.
It's easier to arrange the migration based on the server OS or the volume of data to be migrated. Because there's often little control or process around how apps are portioned out, you may be required to inventory the apps at the host level. This can be a taxing project, so allow enough time to obtain the information and vet it with appropriate business/system users. If the inventory process is painful, it's probably a good time to implement a more effective configuration/change management process. For a data migration effort, the following attributes of a server/application inventory should be included in a list of all affected or source servers:
- OS and version/patch level of server
- Target host (if changing) with OS and version/ patch information
- Current array and associated hardware
- Volume information (allocated, used and free)
- LUN information
- Target array and associated hardware
- User information, including apps/databases, department, department contacts, DBA contacts and end users (especially if a file system with user data is involved)
While not absolutely necessary, other items that might be included include cabling requirements, server IDs, free slots and physical locations of the servers. Don't be surprised if someone from a business unit identifies incorrect information, especially if the business/IT liaison acts as an application administrator. It's difficult for IT to keep an inventory that's 100% correct, so it's good to periodically review the inventory. A final consideration is the criticality of the data to be migrated. Again, the project manager will need to ensure that the business units are the ones categorizing the importance of the data (based primarily on the importance of the application).
The volume of dataOnce the data has been logically grouped by business unit and importance, the volume of data to be migrated should be considered to refine the migration schedule. Volume isn't only the amount of data; it's also the number of files. Block-level copying of data can take longer if there are many small files, as is often the case with unstructured data. Of course, there isn't much flexibility regarding the time allotted for the migration, assuming it can take place only at night or during a weekend. Storage admins can use their empirical data to estimate the time needed to migrate a certain amount of data from Platform X to Platform Y. Each platform has its limits, so consult with the appropriate source and target vendors to gather this information. The transfer rate should also be verified during premigration testing.
Knowing the transfer rate and the amount of data to be migrated will enable the project team to fine-tune the migration schedule. Even using an offline migration process, experience has shown that it can take up to twice as long as the estimated transfer rate. If mirroring is used as the migration method, user access will prolong the migration; users will also see performance degrade. If possible effects aren't communicated appropriately, unnecessary help desk calls or user frustration may result.
This was first published in September 2005