In previous articles, we discussed IT transformation in general, IT transformation and security, and the top-down approach to IT transformation. In this article, we discuss migration as a means to IT transformation. Migration as a means to IT transformation hooks into an organization’s disaster recovery procedures, using these existing mechanisms to migrate workloads from on-premises to in-cloud. At that point, the migration can continue to power on workloads to take over for those on-premises, to run side-by-side with what is on-premises, to run cooperatively with those on-premises, or to just be ready in case a disaster requires their use. The fact is that cloud can be a fairly large cost saver over maintaining a hot site within another data center. Instead, you maintain one in the cloud.
But first, you need to get your workloads to the cloud, automate their configuration based on existing configurations, test their recovery, and determine how much more you want your cloud to do for you. The decision point depends on the organization. Some just want storage of data, others want to run cooperatively, and others want to run entirely within the cloud. But it all stems from getting the data to the cloud. Once the data is in a cloud, IT transformation is possible. Here is the interesting issue about migration: it does not take much investment in tools, time, etc. It takes a desire to save money over more traditional methods such as hot sites and on-premises backup storage.
Cloud is a major part of Disaster Recovery as a Service today. Nearly every backup vendor has a cloud functionality. Some are difficult to use, but others are not. The goal is to move the data around so that the data is where you need it when you want to run the workloads that use the data. Quantum and Unitrends call this their “restore anywhere” approach to disaster recovery; others use different names. Once the data—perhaps terabytes—is in a cloud, it is easy to manipulate for other uses, including running those workloads. However, to properly run many workloads, just getting the data to the cloud is not enough: you also have to minimally move networking and modify procedures for maintenance, further backup, and access changes for customers and employees.
The migration approach starts off with data protection but soon moves into the realm of networking, process, and procedures. Companies like CloudVelox and HotLink provide such migration services, and they have automated much of the networking as part of those migration services. HotLink DR is limited to VMware vSphere and migrates workloads just to Amazon. CloudVelox is cloud agnostic. It will migrate from on-premises to any cloud and even between clouds. The goal of using migration is to have a strategy addressing how, why, where, and when you want to move the data, as well as what you will do with the data once it is moved.
These questions should be answered before you start a migration approach to IT transformation. It is crucial to think not just about the here and now, but also about the future. There is plenty of software that will offer cloud backup, but perhaps not to your cloud or clouds of choice. In addition, data protection rules still call for data to be stored offsite. If you move everything to a single cloud, that cloud becomes your site, and you still have to store data offsite somewhere. Perhaps in another cloud, or just in a storage array sitting in your data center on-premises.
Consider migration as a path to IT transformation. Migration of data is just a small part of this transformation. But it will allow you to move along the path with immediate benefits. It is something that hooks directly into existing practices, namely data protection, but it has a series of questions all its own to answer. As we have discussed, IT transformation is mostly about planning. The migration approach is a mix of doing and planning. Know where you want to go in the short term (data protection into the cloud), but consider using the cloud to run workloads as a hot site as part of that data protection, which implies you still need to consider networks and process.