Lessons Learned: The Balancing Act Of Migrating To The Cloud

Cloud computing is perhaps not as headline-grabby as blockchain or machine learning, but it's just as revolutionary. Plus, it's getting better all the time, advancing in speed and agility across the IT services supply chain. As a result, more and more organisations have undertaken the process of migrating from IT infrastructure that uses on-site storage and in-house software to cloud systems. This is generally recommendable, and spells certain advantages like having a faster, safer, and more scalable IT system for the company's employees—however, the process of implementing such a system also brings challenges, some less obvious than others. In this article I've endeavoured to catalogue the most common errors that companies make in their cloud migrations.

1. Teaching a new dog old tricks

   There is a tendency for companies to design their future cloud environment based on their current infrastructure footprint. But this one-to-one mapping of on-premise infrastructure to a cloud system can lead to an unrealistic (and less effective) cloud design, mostly because the old system was often intentionally built to be too big—since enlarging it takes great time and effort. However, the resulting inefficiency does not need to be reflected in a cloud system, because cloud systems are far more scalable by design.

   Similarly, on-premise systems often had a safety buffer in place to handle data overflow, again since the capacity couldn't be changed quickly. For the same reason, their design also frequently overlooked features relevant to downsizing. With the cloud, the opportunity for an updated design taking these factors into account should be taken.

2. Neglecting the little things

   Many questions surround the process of moving all the programmes and apps that the old system accommodates. Should all these programmes be moved onto the cloud, or is there an opportunity for housecleaning? Which should be moved first, and which last? Should some of them be moved in clusters?

   The cloud architect must have an overview of all the programmes and apps—and sometimes there are hundreds—to find the optimal design. Gathering information on them can also pose challenges, especially if programme owners have left the company, or explanatory documentation is lacking. The information about each programme or app should, roughly, include:

   type of application business continuity requirements data dependencies sensitivity to latency compliancy and regulatory requirements...