Take Control of Cloud Migration in 5 Steps

Reading time: 7 min.

Cloud migration is a process where you have to invest before you start saving. Migration to the cloud is complicated, resulting in many difficult decisions and sacrifices to make along the way. Some of them are completely out of your control, like data protection laws that you have to simply be aware of but cannot affect in any way. Other aspects are in your control, and you should factor them in as much as possible. Here are the five steps you can take to control your cloud migration:

1. Find out how much computation power you are utilizing

Traditional web infrastructure providers don’t sell computation power. They sell resources, i.e. servers that run 24/7, even when you don’t use them, and that you pay for on a monthly basis. In most cases, your application or system is not fully loaded 100% of the time you prepay for, wasting your budget away on server idle time. Depending on the type of system, resource idle time will vary.

Without nighttime operations like reporting or maintenance, a national company with headquarters in one country faces 12 hours of downtime, where 50% of your infrastructure budget goes right down the drain. An international company with geographically dispersed offices has to deal with less idle time, but it’s still a waste. Even a global public or entertainment system like a media-heavy popular social network will have two or three hours of slow or nearly non-existent traffic and can benefit from balancing its payload.

Buying a very powerful server based on abstract high traffic predictions may be too optimistic and buying a small server may backfire if you go viral and the system crashes under the pressure, sending users away never to come back. The right approach is opting for the cloud with auto-scaling functionality or using serverless backend systems based on AWS Lambda, Azure Functions or similar specialized services which enable automatic backend scaling where you benefit from pay-as-you-go and pay-as-you-use schemes.

But it’s not all black and white. 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 mission-critical factor, cloud may not be the best idea. Having system components spread across the datacenter and connected via extra switching nodes you deal with network latency. Network attached storages are also not so efficient as local drives. This leads to a situation, where being still open for scaling, you’re limited in reaching the minimum response time per single request. If it’s your case, it may be worth considering staying with the local datacenter.

2. Change architecture and choose the right cloud service

If you migrate your system as is, the cloud will always be more expensive. You need to change your architecture prior to migration and choose services that facilitate the process. Clients moving to the cloud must be warned that initial calculations will clearly demonstrate that the cloud is twice more expensive, according to Forbes. That happens because migrations are often planned as cloning of the current infrastructure with its current capacity to the cloud. Also you have to add the cost of cloud provider management and scalability overheads to the cost of your current infrastructure, since cloud providers offer you a fully managed service. The only correct approach to migrate to the cloud is to start with deciding which system components to leave on premise 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 dividing the system in such a way that the heavily loaded services are located in the cloud separately from the partially loaded ones.

Then decide which parts of the system 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 architecture first, the cloud will turn out to be cheaper than paying for the operating time of a dedicated server. To help you with that I’ve prepared a list of the most typical out-the-box recipes you can use for this purpose:

  • Move static resources to CDN — this will take some load off your application servers.
  • Use platform-provided infrastructure components like load balancers, message queues, caching services instead of deploying extra server instances for them.
  • Replace rarely used routines and services by serverless handlers (from AWS Lambda or Azure Functions) – this will make you pay for computation resources they consume rather than idle time. This may include:
  • Data batch processing operations
  • Scheduled / background routines (sending of emails, SMS, messages to external systems, etc.).
  • The same can be done for simple backend services with sporadic load and / or tolerant to response time.

For more services, check out these resources:

AWS: https://aws.amazon.com/products/

Azure: https://azure.microsoft.com/en-us/services/

3. Calculate infrastructure costs in the cloud

The notorious price question is hard to answer with calculations easily swayed both sides, depending on which “party” you are voting for, on premise or cloud. Infrastructure costs include the costs of the servers used, resources costs, equipment wear and tear, equipment failure and disposal, and many others. To estimate your costs use tools like the AWS Simple Monthly Calculator.

Don’t be surprised if your calculations show a 3 times drop in costs. If you follow the steps in the sections above, that’s exactly what you should get. Let’s take an example where it’s easy to see how this happens. Imagine you have a system that was initially designed as on-premises. Let’s even say this is a very busy system with the data volume of 10+ TB, an 8 000 000+ events/day update rate and a 30 000 events/min throughput. You need to migrate this system to the cloud. You will migrate in two steps: first, you will rewrite infrastructure components to benefit from serverless services; second, you will choose the best out-the-box cloud services. By optimizing and reengineering infrastructure, you will be able to implement with fewer languages. By using serveless services, you will see a dramatic cut in costs. Automated scaling, simplified development/support and resources optimization will be other perks of the migration.

4. Protect your data

For security reasons certain economic sectors are not ideal for cloud migration: bank and finance, government, insurance, health and so on. However, many startups that work with any kind of sensitive data do host their systems in the cloud. Since their budgets don’t allow them to hire top security experts on premises, they make deals with cloud providers about a certain level of services focused on security.

Not only struggling businesses are favoring the cloud. Even big budget players are migrating, but not without taking certain precautions. For instance, more and more government agencies as well as other large organizations are warming up to the cloud, opting for a hybrid model where they store parts of their data in the cloud, safeguarding their organizations from attacks by observing strict user access limits and using government firewalls. Even with multiple security concerns, it’s possible to move to the cloud if you observe the distribution of client/provider responsibilities in this complicated process:

Your responsibility Provider’s responsibility

Choose the cloud provider based on security controls track record.

Analyze security risks and your architecture for loopholes.

Write an effective SLA that covers not only the provider-client relationship, but third parties and cloud brokers.

Write a case-specific threat management plan with a clear incident resolution roadmap.

Choose hybrid models where you keep ERP or CRM solutions and other mission critical and personally identifiable information on premise.

Counteract security risks posed by BYOD and IoT with the help of virtual machines, hypervisors or containers for data and access management separately from the corporate network.

Follow a flexible security model that always evolves with the expanding and evolving threats.


6. Choose cloud services based on open source components and standard communication interfaces

Many businesses’ concern is the potential need to leave the cloud or change the cloud provider and not being able to do so because of vendor lock-in. Interoperability and portability of applications when switching vendors are also other concerns. Enterprises are afraid that having invested already into changing their infrastructure, they might have to spend more money again, if they need to switch providers.

In Itransition’s experience, clients never switched cloud providers, provided the migration had been 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, because you can easily take your database to another platform or on premises. Discover what’s behind the brand name of the service by researching documentation or asking an expert. Off of the top of my head, here are some examples from AWS cloud services stack:

  • AWS Elasticache — caching service, which uses either Redis or Memcached on backend.
  • Amazon Aurora — database service, compatible with MySQL.
  • Amazon Redshift — data warehouse service, initially built on top of Postgres (though with notable modifications) and still compatible in most of SQL features.

Another thing you can do is choose cloud services that use standard / open protocols, enabling you to design your system in a way that allows you to leave the provider for a different one. Open protocols make room for equipment interoperability without having to use proprietary gateways or interfaces.

In the case when cloud services offer their own propriety protocols as well as open protocols, always opt for open protocols. Like Azure Service Bus provides its own API as well as supports AMQP – an open messaging protocol. By choosing the open standard, you remain flexible and can switch the provider or even deploy your own service instance, which supports the same protocol without significant changes in client components.

If still in doubt if you are making the right choice of service for your system, don’t hesitate to double check with the vendor.


  • Optimize resources utilization
  • Change your architecture prior to migration
  • Choose the right cloud services
  • Carefully calculate infrastructure costs
  • Honor your security responsibilities
  • Opt for services with open protocol options

Cloud migration is complicated, resulting in difficult decisions to make. Some of them are out of your control, some are in your control, and you should factor them in as much as possible.