In part 1 of our blog series on data migration, we discussed the considerations for BEFORE the move. Now it’s time to talk about how to make the move. There are many options to choose from, whether you choose to handle the cloud migration yourself or enlist the help of a CSP’s professional services team. The following are some of the most common.
Manual Data Migration. This cost-effective data migration method can be performed using tools built into your operating system or application. Data is transferred over the internet, so distance to the new cloud environment isn’t an issue. However, even if the bandwidth is 1 Gbps pipe, it would likely take more than two hours to transmit 1 TB of data. If you have a lot of data, the process could take months.
Manual data migration is best for one or two simple applications that don’t have many dependencies or require custom configurations. The biggest risk you’ll face is that your data will be in flight, leaving it vulnerable. With this or any other migration method, always encrypt your data.
Offline Media Transfer Using Portable Media. This is a good option if you are close enough to your CSP that shipping via courier is faster than transferring data over the internet. Simply perform the data conversion. Copy the information to a USB drive. Then, ship it via a reliable carrier. Take care of DNS, VPN, certifications and other patch items associated with the move. Import the virtual images and test.
This cloud migration method works well for transferring native format systems, such as VMware source to VMware provider, or for converting systems to your CSP’s format. It is best suited for moderate size workloads.
Some conversion tools may require that systems be offline. If systems remain online, however, data changes made during the conversion process will not be captured.
Internet Transfer of Virtual Disk Images. Use this method for migrating smaller data files and virtual machines over long distances. You can transfer workloads in your native format, so you don’t have to rebuild your application environment. You also can convert over to your CSP’s format. Either way, the CSP will import the virtual images to its cloud via the internet after you upload to a SFTP server or similar system. There will be only negligible latency.
Most of the costs will be for bandwidth at the source and target. Test runs will help mitigate risks. If you encounter problems during a maintenance window, back out and try again at the next window.
Software Agent-based Data Replication. Consider this method for migrating large data sets, when time isn’t an issue and the CSP is located far away. Latency is negligible.
Install data replication software on the old server and new destination server. Let the data trickle through during business hours when internet usage is at its peak. During slow periods, it can flow freely. All the while, production servers continue to run. You can maintain this sync state indefinitely.
When the new server catches up with the old server, stop the replication and test the new server. Restart the synchronization until the new server catches up with the old server again. When replication and testing are complete, you can failover to the new environment.
Risks are low because you can stop the replication process and test any time. However, unexpectedly large changes to source-system data, as can happen with disk defragmentation programs, will restart the process.
Full Server Failover Using Software Agents. With this data migration method, you capture everything installed and configured on the source system and move it in its entirety to the CSP’s environment. You can replicate to a shell VM, agent to agent or to an aggregated target such as a VM appliance.
There are similarities between this and software agent-based replication. A key difference, however, is that the target server is a complete duplicate of the source server. No rebuilding or reconfiguring or dependencies should be expected, and you don’t have to worry about missing installation media or configuration work-arounds. The complete server package is there. This method is particularly good for large numbers of servers, and it scales well.
The fun part lies ahead: the actual data migration. In the final blog of this series, we’ll discuss developing and executing your cloud migration work plan and the tests to ensure the migration works.