Cloud migration: How to avoid getting burned

While migrating to a public cloud is not trivial, it is undoubtedly appealing. The cloud can scale dynamically, and it has built-in high availability, backup and security features. For many people, the main attraction is that it removes all the hassle associated with running their own hardware and software. 

The cloud can do all of that because it differs, in many respects, from on-premises infrastructure. It operates on a massively scaled and often rather remote platform, owned by the cloud provider and shared by many customers. These characteristics, however, also come with their own specificities, difficulties and challenges. 

There are four risk factors to consider before making the move:

1. Performance. Applications that are sensitive to even a small deterioration in computing resources could have issues in the cloud. Storage performance could be a particularly difficult point. 
   For example, a single database server that acts as the irreplaceable heart of your architecture and requires high disk throughput at all times could suffer in a shared storage system. The best practice here is to transform this type of unique server into a load-balanced group of cloud “pets” that can scale as needed.
   
   
2. Connectivity. The cloud is remote. Although most applications are fine with the latency and bandwidth provided by Europe’s public internet network, there are some exceptions. Virtual desktops with interactive user applications require low latency, for example, while large backups need massive bandwidth, especially in recovery scenarios.
   In cases like this, a dedicated private line is recommended. Needless to say, then, that it’s a huge advantage when your cloud provider happens to be a telco company.
   
   
3. Architecture and licensing. Some applications have trouble migrating to the cloud due to their architecture. Clouds usually do not support older versions of operating systems, or those that are not mainstream, such as BSD or HP-UX.
   
   Specific hardware setups, like two servers accessing the same storage, which are commonly used in high-availability server clusters, may not be supported in a cloud environment. Custom hardcoded specifics, such as IP addresses written directly in application code, will need to be rewritten.
   
   Cloud migration may also face licensing issues when the relevant software license is tied to an on-premises hardware configuration, or when it is licensed differently in the cloud. When in doubt, consult the software vendor.
   
   
4. Access control. On its own, the cloud is safer than what a vast majority of customers could build themselves with just the resources, knowledge and time they have available. Nonetheless, it is left up to customers to ensure the security of their cloud access mechanisms, such as federated Active Directory servers. That is far from being straightforward, as any mistake in this area carries significant risk.

The decision of whether or not to migrate should be made by weighing the operational and transformational benefits of the cloud against the associated difficulties and risks. That is precisely the core of developing a well thought-out cloud migration strategy.