Cloud migration is one of those processes where you have to invest first before you start saving. This process is complicated and requires making many difficult decisions along the way. Some of these are completely out of your control, such as data protection laws that you need to be aware of at all times yet cannot affect in any way. But others are within your power, and you should factor them in as much as possible.
This guide below provides the five steps you can take to control your cloud migration project.
Traditional web infrastructure providers don’t sell computational power. They sell resources, that is, servers that run 24/7, charging you by the hour even when you don’t use these resources. In most cases, your cloud-based application or system is not fully loaded during the prepaid time, thus wasting your budget away on the server idle time.
Depending on your scale of operations, the numbers will vary. Without night-time operations like reporting or maintenance, a local company will face 12 hours of downtime. That means 50% of the infrastructure budget going right down the drain. A company with geographically distributed offices will have to deal with less idle time, but there will be a waste anyway. Even highly popular social media have two or three hours of slow traffic, and thus could benefit from balancing their payload.
Buying a large server based on abstract traffic predictions may be too optimistic, while buying a small server may backfire if you go viral, and the system crashes under the pressure.
The right approach to your cloud migration strategy would be to opt for the cloud capable of auto-scaling, or using serverless backend systems based on AWS Lambda, Azure Functions, or similar specialized services. Such services enable automatic backend scaling, so that you can benefit from pay-as-you-go and pay-as-you-use models.
But in some cases going to the cloud is not a good idea overall. When hosting in the cloud, you don’t know on which physical servers your components will be deployed. In the specific case of high-loaded systems where response time is a critical factor, the cloud may not be the best option at all.
Spreading your system components across the data center and connecting them via extra switching nodes, you will be dealing with network latency. Network-attached storages are less efficient than local drives. This means that while still being open to scaling, you get limited in reaching the minimum response time per request. If it’s crucial for your business, it may be worth considering staying with your local datacenter.
If you migrate your system as is, the cloud will always be more expensive than local storage. To optimize your costs, you need to adjust your architecture before migration and choose services that will facilitate the process.
Despite that cost saving is among the strongest motivations behind cloud migration, it often turns out to be more expensive. That happens because migrations are often perceived as the cloning of a current infrastructure with its entire capacity to the cloud. Yet, you will also need to add the cloud provider management costs and scalability overheads, since cloud providers offer fully managed services.
Taking into account these factors, the only correct approach to cloud migration is to decide which system components to leave on-premises and which ones to migrate to the cloud.
Before you do anything, analyze which services are fully loaded and which ones are underutilized. You can minimize underutilization by separating the cloud storage of heavily loaded services from those loaded only partially. Then, decide which system components can be realized based on the existing service platforms, since there are many out-the-box services perfectly suited for standard solutions.
If you optimize the architecture first, the cloud will turn out to be cheaper than a dedicated server. To help you with that, here’s the list of the most typical out-of-the-box steps you can take:
The notorious pricing question is hard to answer as the calculations easily sway to both sides, depending on what you vote for—on‑premises or the cloud.
Infrastructure costs typically include the costs of the servers, resources, equipment wear-and-tear, equipment failure and disposal, and many other points. To estimate your costs, you can use a tool like the AWS Simple Monthly Calculator. Don’t be surprised if your calculations show a three-time drop in costs. If you follow the recommendations from the previous step, that’s exactly what you should get.
Let’s take a straightforward example to illustrate this. Imagine you have a system that was initially designed to run on-premises. Let’s assume this is a very busy system with 10+ TB of data, an 8,000,000+ events/day update rate and a 30,000 events/min throughput. Now, you need a cloud migration strategy for this system.
For this, you will be migrating in two steps: first, you will rewrite the infrastructure components to benefit from serverless services; second, you will choose the best out-the-box cloud services. By optimizing and re-engineering your infrastructure, you will be able to migrate with fewer languages required. By using serverless services, you will see a dramatic cut in costs. Automated scaling, simplified development, and support, as well as resource optimization, will be other perks of migrating this way.
For security reasons, certain industries can’t fully consider cloud migration: for example, banking and finance, public sector, insurance, and healthcare. However, many startups that work with different types of sensitive data do host their systems in the cloud. Since their budgets don’t allow them to hire top security experts in house, they make deals with cloud providers about a certain level of security-focused services.
It’s not only because of cost cutting that businesses are favoring the cloud. Even big-budget players are migrating, but not without taking certain precautions. More and more highly regulated organizations, including government agencies, are warming up to the cloud. They opt for a hybrid model where they can store only parts of their data in the cloud, thus safeguarding themselves from attacks by observing strict user access limits and using government firewalls.
Even if you have multiple security concerns, it’s possible to move to the cloud if you share and meet responsibilities in this complicated process:
|Your responsibility||Cloud provider’s responsibility|
Choose the cloud provider based on their security acknowledgments.
Analyze security risks and scan your architecture for loopholes.
Create an effective SLA that covers not only provider-client relationships but also third parties and cloud brokers.
Create a case-specific threat management plan with a clear incident resolution roadmap.
Choose hybrid models where you can keep your ERP, CRM, and other mission-critical solutions with personally identifiable information on premises.
Counteract security risks posed by BYOD and IoT with the help of virtual machines, hypervisors, or containers for data and access management that are separate from the corporate network.
Follow a flexible security model that keeps evolving to respond to emerging threats.
Many cloud-adopting businesses fear the so-called vendor lock-in, that is, being unable to leave the cloud or change the cloud provider. Interoperability and portability of applications when switching vendors are also among the biggest concerns, along with the fears of having to pay more for changing the infrastructure.
In Itransition’s history of providing cloud computing services, clients have never switched cloud providers, taking into account that the migration was thoroughly organized and planned in the first place. If you are still worried, choose cloud-managed services built on top of well-known open-source components. This way, you will be able to easily take your database to another cloud platform or an on-premises solution.
To address lock-in concerns, discover what’s behind the provider’s brand name by researching documentation or asking an expert. For example, here are some services from the AWS stack that are open-source and/or interoperable:
You can also choose cloud services that use standard or open protocols, thus allowing you to switch providers when needed. Open protocols make room for equipment interoperability without having to use proprietary gateways or interfaces.
If cloud services offer their own propriety protocols alongside open protocols, the advice is to always opt for open protocols. For example, Azure Service Bus provides its own API as well as supporting AMQP—an open messaging protocol. By choosing an open standard, you can remain flexible. This means, you can switch your provider or even deploy your own service instance that supports the same protocol without significant changes in client components.
If still in doubt when choosing a service for your system, don’t hesitate to double-check with the vendor.
Cloud migration is a complex, multi-level process that requires a good deal of advance planning. This guide outlined the critical steps that can help you minimize your infrastructure costs, avoid vendor lock-in, and address common fears of cloud adopters.
Now, here’s your final checklist to reiterate the points above: