Cloud Integration by MobiLab

MobiLab is specialized on Cloud Integration (bringing together Cloud Adoption and Data Integration). As such we support our customers to transform into a cloud native organization and operate with their full data potential anytime & anywhere.

The vertical I steer and work on at MobiLab covers Cloud Adoption which enables organizations to embrace the cloud quickly and reliably without disrupting their on-going business. In this and subsequent blog posts I will outline how MobiLab adopts the cloud into the customers’ environment and which areas require a special attention and focus.

Cloud Computing

Cloud computing is not a new concept or idea. Since Amazon launched its highly profitable AWS business in 2005, the cloud usage to leverage on vertical and horizontal scaling beside many other advantages, has been rising. However, it has been the current Covid-19 pandemic (the shift to work from home) which has accelerated the rate at which enterprises switch to cloud-based computing. The recent earning calls of Amazon and Microsoft and their cloud related income underline this accelerated pace.

Amazon – AWS


Microsoft – Azure


Why switch to Cloud?

There are many motivations and reasons why a switch to the cloud can be beneficial. At MobiLab we like to measure things, this holds true for the benefits of the cloud, which in turn allows the customer to measure us against the promises we have given. Motivations to switch to the cloud can be to turn CAPEX into OPEX, to get rid of the refreshment cycles which usually kick in every 3-5 years for the on-premise environment, or to offer better Service Level Agreements (SLA) instead of offering a best-effort SLA (some other examples below).

No matter the reason for moving to the cloud, it is always beneficial to translate those into a KPI to know what the customer and the cloud adoption provider are optimizing for. Only if we are able to measure we can truly say whether we were successful at the end of our endeavor. MobiLab offers a holistic approach for the cloud adoption. Our approach is divided into different steps culminating in the transformation of the organization into a cloud-native company.

Cloud Economic Assessment


We run a cloud assessment of the on-premise infrastructure to fully understand the inventory footprint. Through different tools we gather data on the capacity of the on-premise environment, how much the capacity is really used and compare those data points with the recorded book values from IT-controlling (such as depreciated assets, refreshment cycles etc.). With the data collected we normalize the data, establish a baseline and map it to the services which shall be used in the cloud.

The cloud assessment can result in complex and complicated discussions with customers. During the last 20 years IT Operations (IT-Ops) of large organizations have been optimized for costs rather than for speed & delivery. The result is that IT-Ops tries to deliver a bare bone service and reduces the SLA to a minimum instead of fighting for the needed budget to keep up with the mandatory innovation pace. Moreover, the hardware which is in place is usually outdated and running at its limit. With software and cloud computing taking over more and more parts of the value chain, established organizations tend to put off the problem leading to IT related cost increases in the long-run. During this cloud economic assessment phase we work with the customer to develop a common understanding which requires a thorough examination of the cost structures of the IT environment and the accounting methodologies which are in place. This is a painful exercise as it can put the IT-Ops into an uncomfortable spot. However, what seems to be uncomfortable at first turns out to be beneficial for the IT-Ops. By bringing transparency into the IT cost structure, its drivers (usually a result of investment postponement) and the cost measurements, it gives a better argumentation basis for the IT-Ops to justify more budget needs from the CEO or CFO and a potential move to the cloud.

IT cost structure

Once we have established a common baseline and analyzed the on-premise infrastructure as well as the workloads (i.e. application dependency mapping) we set up a cloud migration strategy. Depending on the customer motivation and the findings of the cloud economic assessment, different strategies can be used to adopt the cloud. One customer may have the motivation to migrate as much as possible on-premise workloads to the cloud to reduce the hardware footprint. Another customer may have the motivation to only build new cloud native services on the cloud but needs guardrails for the innovation department (to guide the adoption of the cloud without any fear while doing it). No matter which motivation the customer has, the goal should be to adopt the cloud in short iterations (so called migration waves). However, before any migration can take place a lot of ground work will be needed, such as setting up a clear Cloud Governance Framework (CGF) which maps existing policies into the cloud or defines completely new policies (such as cost controlling and chargebacks). The goal of the cloud migration strategy is to define a timeframe and the best team setup for adopting the cloud. Given the metric driven approach, the targets which have been agreed upon should be the guiding principles.

Cloud Migration

Migration plan

With the cloud strategy in place and the buy-in of the customer we go into the implementation mode. Implementation does not simply mean to migrate workloads to the cloud but to design the CGF as well as the Target Cloud Architecture which guarantee that the migrated or build-up workloads are placed in a safe and reliable Cloud Zone. Working in an agile way, using some elements of scrum supports learning alongside the project and adopting the cloud based on the workloads which are being migrated. It gives some flexibility to measure and benefit from real data before over-analyzing which usually results in endless discussions. There are tons of reasons why working in an agile way works in engineering and we won’t dive into this discussion here. As a a core engineering company, our flexibility to adjust to changing circumstances in a fast way without sacrificing our structured way of working has paid off well in adopting the cloud for our customers.

Cloud migration in terms of lift & shift usually ends with a hyper-care phase which covers a period of 2-3 weeks before the workloads are handed over to the future mode of operation to the OPs-Team. Depending on the customer type and size, we also offer the cloud operation for the customer or the up-skilling of the customer team to pick up the cloud operations fast and reliably.

Cloud Optimization

While we migrate workloads to the cloud we optimize the resources to leverage and benefit best from the cloud. It can happen that on-premise workloads are running at resource usage limits resulting in a bad user experience and SLA for end-customers. When migrating those workloads to the cloud we assign more resources to those workloads. If workloads are running with over-capacity we downsize the resources and hence reduce costs (note: a first degree of optimization takes place when the workload assessment is taking place as we look into usage pattern of the workloads. In forthcoming stages, tools such as Azure Advisor support in further optimizations to avoid over- or under-utilization). Another type of optimization is the re-build and re-architecture of applications. Our approach and recommendation usually is to migrate (with the lift & shift approach) as much as possible to the cloud and work on the re-building and re-architecture of workloads at a later stage. For this part we set up a separate team which looks into the workloads in detail and decides whether those workloads can be re-structured by making use of platform-as-a-services in the cloud. The type of people used and needed in this stream are slightly different from the people which were involved during the migration phase. This phase usually takes much longer as the mere lift & shift of workloads. Customer sometimes like to parallelize this work right from the beginning (i.e. while doing the lift & shift) or even starting with the re-platforming. We usually recommend against this approach because this work takes longer than the migration approach and if the customer wants to see a fast success of the cloud, we clearly communicate from the beginning that re-platforming is not the way to achieve a fast return on investment. Nevertheless, it is this final re-platforming step which results into building cloud native services and finally transforming the organization into a cloud native company.

Cloud Transformation

In Conclusion

This was the first blog post on Cloud Adoption by MobiLab. During the next weeks and months we will delve deeper into each of the phases and provide real-world examples.



Pouya is one of the Managing Directors at MobiLab. His focus is on enabling enterprises to successfully adopt the cloud and become a cloud-native company. If you are interested in Cloud Adoption and what to get more information get in touch with us.