What is enterprise cloud migration?
Cloud migration is about moving your data, applications, and even infrastructure from your on-premises computers or infrastructure to a virtual pool of on-demand, shared resources that offer compute, storage, and network services at scale.
Why do enterprises migrate to the cloud?
Here are three simple but key reasons that enterprises start cloud migrations:
Reason 1: Speed and cost savings
Being cloud-based means you can scale according to your demand, and if managed correctly, you can accommodate any spike and save money when demand is low.
Reason 2: New advantages such as disaster recovery
If your enterprise has a global footprint, the cost and complexity to manage comprehensive disaster recovery for on-premises data centers is huge. This sort of thing is a solved problem when working with a top cloud infrastructure provider.
Reason 3: Constantly-updated new tech and services
Just look at any of the big three cloud providers and you’ll see that they constantly release new technology and services to help provide solutions to customers. This includes basics such as faster servers to nearly plug-and-play machine learning solutions.
Why migrate to the cloud — a deeper dive
Regardless of the industry, just about every company has become a technology — really a software company — out of necessity. Enterprises therefore become more dependent on IT. However, in this new role IT isn’t just support anymore but becomes part of the product itself.
If you’re limited to on-premises servers then you’re likely giving your competitors an advantage when it comes to scalability and being future-proof, that is, thinking 5-10 years down the road. Migrating to the cloud means breaking away from the technologies that are holding you and your enterprise back from the speed, scalability, and cost savings that the cloud has to offer.
Rather than continuing to invest in aging and expensive infrastructure that can’t keep pace with the changes in modern technology, migrating to the cloud is a choice for the future. In addition to the immediate benefits of cost savings and scalability that can be realized, you are essentially laying the foundation to be able to respond more quickly to changes in the market, scale your growth, and drive innovation for the long term.
As you’re planning your cloud migration, understanding how to get there depends on your unique business model and goals as well as your current infrastructure and applications. You’ll need to rely on the skills and experience of your IT teams to understand the ins and outs of your current environment and the interdependencies of your applications to determine which applications to migrate and how.
What are some unique business goals to consider?
- Data sensitivity and compliance needs: Do you need to comply with privacy for governments or medical organizations?
- Vendor lock-in: Do you want to put all your eggs in one tech basket?
- Cost: Time is money, and how long will it really take you to get from point A to point B, depending on what needs to change in your company (both skills and culture)?
What are the 5 Rs of cloud migration?
The “5 Rs of cloud migration” — Rehost, Refactor, Revise, Rebuild, and Replace — from Gartner are a great place to start when considering all of the options for migrating your applications to the cloud.
Whether it’s your initial migration or your fifth iteration, your cloud migration requires a strategy and planning to be successful. Here’s what you need to know.
R number 1: Rehost
Rehosting is the process of moving your existing physical and virtual servers to a solution based on Infrastructure as a Service (IaaS). Also known as lift and shift, the key benefit of this approach is that systems can be migrated quickly with no modification to their architecture. This is often the path that companies take when they’re new to cloud computing. When rehosting, you’re basically treating the cloud as just another data center, which means you’re not getting the most out of the available cloud services.
Consider a web application as a simple example. Imagine you have an ASP.NET application running on Windows and you want to rehost it on AWS. You can create a Windows VM that meets the size requirements and deploy the application. With a change to the DNS record, you’re pretty much ready to go live. In this way, rehosting is an easy way to move to the cloud. However, this solution isn’t highly available, or scalable, and it still requires you to manage OS patches.
R number 2: Refactor
This is the process of running your applications on managed set of services from your cloud provider, also referred to as Platform as a Service (PaaS). Using a PaaS means that developers are able to reuse the frameworks, languages, and containers in which they’ve already invested.
For applications or workloads that can be refactored to leverage cloud capabilities, you’ll be able to take advantage of some cloud-native features offered by the PaaS infrastructure for reduced costs and increased scalability. However, the biggest disadvantages of this option include transitive risk, missing capabilities, and framework lock-in. One of the common issues that developers run into here is that many PaaS options use ephemeral storage. This typically requires a change to the codebase to use cloud storage, rather than the local file system for saved files.
An example of refactoring to use PaaS might be to take an existing Ruby on Rails application and deploy it to Heroku or to take an existing Drupal application and modify it to run on Acquia Cloud or Pantheon. PaaS options will allow you to focus on the application without having to deal with the underlying OS.
R number 3: Revise
Certain applications will need to be modified more extensively in order to migrate them to the cloud. Some will require added functionality while others may need to be re-architected completely before they can be rehosted or refactored and eventually deployed to the cloud.
This can be a difficult option because modifying a large codebase to become more cloud-native can be time consuming and expensive. An example would be taking a complex, monolithic Python-based application and moving it to Google App Engine. The design of your application will determine the amount of changes you’ll require. You may find that you need to break it out into multiple applications and swap out components such as message queues to get the most out of the move.
R number 4: Rebuild
In this scenario, an application is re-architected, original coding is discarded, and it is re-built on a PaaS infrastructure. Rebuilding the application allows you to take advantage of more advanced and innovative features from your cloud provider to improve your application even further. A major drawback of this option is vendor lock-in.
For instance, if the provider makes a technical or pricing change that the customer cannot accept or that breaches the service level agreement (SLA), the customer may be forced to switch back to the previous application, potentially losing some or all of its application assets.
Let’s say you rebuild your application so that it is completely serverless. By using technologies such as AWS Lambda, API Gateway, DynamoDB, S3, and others, you could run your application without having to manage servers for yourself. This sort of cloud-native application would be inexpensive to operate and highly scalable. However, it also means that you’re locked in to using a particular cloud vendor. This isn’t intrinsically bad, but it is a factor that you will need to consider.
R number 5: Replace
In this scenario, you completely replace the existing application(s) with software delivered as a service (SaaS). An advantage of the replace model is that it allows you to avoid IT development costs. However, you may encounter problems in accessing data, unpredictable data semantics, and vendor lock-in.
This can be a great option for minimizing the amount of services and applications that you need to manage. An example might be to replace your local database with a managed option such as Cloud Datastore, Cosmos DB, or Dynamo. This can be one of the easiest ways to bring up your SLA. These services are all known for their scalability and availability. In contrast, running a database yourself and dealing with data replication and failover can be a lot of work.
The Bottom Line: Migration projects of any size require careful planning
A successful cloud migration requires careful preparation and planning. There is no one-size-fits-all approach to migrating to the cloud. Your teams will need a deep knowledge of the infrastructure and applications that your business runs on in order to fully understand the complexity, challenges, and costs involved.