A 7-step checklist for designing a cloud migration plan
Enterprises want their applications to be portable and able to shift easily among multiple cloud providers. To do that, putting together a good cloud migration plan is a must.
We are no longer wondering if we should run workloads in the cloud. Instead, the cloud has become the default deployment strategy for many businesses. Years ago, IT had to justify the need for a cloud migration strategy. Today, it's the opposite: IT has to justify why it's not deploying applications in the cloud.
Yet, just because the cloud has become necessary does not mean moving workloads is easy. Most of all, enterprises are wary of vendor lock-in. Cloud's promise has always been the ability to deploy outside of the traditional constraints of current infrastructure. But, in reality, once cloud applications are deployed, most businesses are hesitant to change providers.
Making the cloud migration more complicated, some cloud vendors, such as Microsoft Azure, are beginning to offer on-premises private cloud options. These packages enable an easier migration from public to private, but the experience is far from seamless. Application movement might be simpler, but it still remains time-consuming and challenging.
For a cloud application to be portable and move among different cloud providers, enterprises must keep several important factors in mind. With 28% of enterprise IT spending shifting to the cloud by 2022, according to Gartner, cloud decision-making continues to be a critical.
Cloud migration requires careful forethought
To make the cloud migration trouble-free, cloud deployments should be designed with portability in mind. That doesn't mean everything will be completely smooth.
When putting together a cloud migration strategy, consider the following:
Workflow. The application's workflow needs to be understood. If inputs or outputs are tied to another application or business process that is running in the same cloud, then moving to another provider is problematic and ill-advised.
Workload. Is the cloud provider optimizing or architecting its platform around the needs of the workload? For instance, a government application may be easier to run on a cloud foundation specifically designed to meet the agency's security and accessibility requirements.
Application and language. In some instances, such as infrastructure as a service, one might have control of the OS, middleware and runtime libraries. In platform as a service, that control is lost, and the cloud provider will dictate many of these areas. This approach can put constraints on the application and language support.
Tools. This is where Amazon Web Services excels. Its tools and APIs exceed the competition in many ways, making a developer's life easier. But that benefit comes with a cost. A cloud migration that moves from AWS to another cloud provider means potentially rewriting your applications or adding third-party capabilities that were integrated into the AWS offering. Tools are the hook. The better the tool set offered by a cloud provider, the lower the chance of customer defection.
Networking. Often overlooked, networking is an important part of a cloud application, especially one that must communicate with on-premises applications or an app that one day may be repatriated back into the corporate data center. Companies moving applications to the cloud have to maintain two networking stacks: one for their on-premises deployments and another for their cloud-based ones. One vendor, Big Switch Networks, has tackled this problem with its Big Cloud Fabric, which provides companies with a single foundation that looks and acts the same regardless of where the application may reside. An enterprise can deploy the fabric either on site or in the AWS cloud and rely on a standard set of networking management rules and settings.
Data structure. This may be one of the less controversial concerns, as data structure is very much application-driven. But data structure becomes an issue in the complexity of an actual move. At that point, the cost is borne in hours spent debugging applications that don't act the way they should. This glitch can be caused by something amiss in the data structure itself, which keeps the application from behaving as expected.
Storage. A key consideration in a cloud migration is storage. You need to consider the cost and how the data is saved. Also, consider how data is migrated from the old application to the application hosted by another provider. Most cloud providers make it easy and cost-effective to get data into the cloud, but getting that data out -- or acting on it -- is where the costs start to add up.
Portability is key when migrating applications
All of the points in this checklist are not an argument against moving an application between two cloud vendors; they are simply primary indicators to consider when building a cloud strategy.
To make your cloud migration trouble-free, cloud deployments should be designed with portability in mind. That doesn't mean everything will be completely smooth. Additionally, you must consider business and technical tradeoffs in your cloud migration strategy checklist.
If an application lives on AWS, but needs the flexibility to move elsewhere, it could mean not using some of the AWS tools and capabilities. For some organizations, this tradeoff may be feasible. But, in many cases, the long-term value of the application can be best appreciated by taking advantage of these tools and keeping the application where it is -- regardless of the operating cost.
The tradeoff between value and cost will be different for every application, especially with regard to different cloud providers. However, this should be no different than the old build-versus-buy exercise IT has done for years.
Today, though, that is no longer the case. Instead, IT wrestles with several debates, including build here versus build there, stay versus build there, and move versus buy.
The key is making the right call at the beginning of your cloud migration strategy -- and not months or years after deployment.
