How we cut our client’s Azure migration costs by 48%

Azure migration of more than 200 virtual machines

Our client is a medium-sized software house, which had nearly 250 people on its payroll and more than 200 on-premise virtual machines in the lead-up to the migration. Importantly, the client’s original environment was highly complex, divided into many smaller projects and dedicated infrastructures that were not integrated with one another, and the model had to preserved even once the IT infrastructure was replaced and modernised.

However, it was the outdated infrastructure that caused the greatest problems for the client. Many solutions were no longer supported and the infrastructure could not keep up with the business needs of the company as it grew. This is why the software house decided it had to replace all of the equipment or shift to a completely new technology and use cloud services. 

New IT infrastructure. In the cloud or on the premises?

At the outset, the client asked us to analyse the costs of three alternative transition scenarios: 

1. Sticking to the in-house model, but buying brand-new equipment from scratch – network elements, disk matrices, servers and a new backup solution; 
2. Hiring an external company and leasing all of the equipment; 
3. Migrating the entire infrastructure to the Azure cloud. 

We prepared a three-year cost analysis for each scenario, including future changes in electricity prices and server room costs, as well as the cost of replacing relevant devices. Of course, for Azure, important factors also included subscription and cloud network traffic costs – initially, the traffic was calculated on the old infrastructure (we will talk about that later). Our estimates also analysed how labour-intensive each migration scenario would be in man-days*, i.e. how much human labour would be needed in each of the three scenarios. 

Once we added up the costs of the three options, the software house decided in favour of Azure migration and hired our team for assistance.

How to estimate the costs of cloud vs in-house infrastructure?

When estimating the costs of two different scenarios, it is important to always compare apples with apples, and not apples with pears, for example. We took a conscious decision not to include the latest Azure features in our cost estimate whenever they went beyond the  specific requirements of the client. 

For example, if the in-house infrastructure (physical hardware) were to be limited to a single location and backup, we did the same for the cloud scenario. In another version, we included the option of switching between two different locations. Our role was not to force Azure and its features on the client. The client had listed very clear requirements as to their in-house SLA functionalities; we respected these guidelines and mapped their costs 1:1 in the cloud.

Azure migration – new architecture and optimisation

Let us linger a moment more on our cost analysis of the scenarios. Before we delivered our final estimates to the client, we took one more important step: we analysed the client’s machine usage. More than ten years old at the time, the infrastructure included many redundant resources and had an outdated architecture. We wanted to find out how the client used that environment so as to clean it up a little before the Azure migration would begin. 

Our work paid off: we optimised more than 50 machines that were scarcely used or not used at all. As a result, their functionalities could be moved to other environments and the client would need to purchase ¼ less equipment (of course, that also affected our cloud migration cost estimates). After the successful clean-up, we got down to designing the architecture of the target environment from scratch, introducing big changes to network and server architecture before we estimated the costs of each of the three scenarios.

Outdated VMware version

Azure migration scenarios also had to take into account aspects that were characteristic only of one or two variants. This was true of scenario 1 and 2, where we estimated the costs of migration to the latest version of VMware. The version in place was no longer supported, which made automated migration impossible. So, if the client opted for any of the non-Azure scenarios, everything would need to be migrated 100% manually, which was reflected in the estimate.

New architecture and ISO 27 001

Another important challenge was that, during the project, the client was undergoing the ISO 27001 certification process. We had to take that into account and apply all the necessary guidelines in the new architecture. Among other things, we had to ensure a complete separation between production and non-production environments, as well as between different project environments. What we did is we made sure projects would be invisible to one another on the network level and introduced separate permissions to guarantee adequate security. Before our intervention, projects were visible to anyone with network access.

Azure migration – cutting costs: first by 48%, then by 20% more

As we said at the beginning, the client approached us with a preliminary cost estimate of their migration to Azure, which they obtained by using a simple calculator: they typed in the number of machines with specific parameters and the calculator returned a cost estimate. Our interventions, including machine optimisation and architecture improvements, allowed that amount to be reduced by 48% to begin with. A further reduction had to do with network traffic. 

In the cloud, you obviously have to pay for virtual machines, i.e. for CPU, RAM and STORAGE; a common mistake is to forget about another element that is very energy-intensive and, as a consequence, expensive: network traffic. Before the migration, we estimated traffic costs based on a monthly scan performed on the client’s old infrastructure. At that stage, the new architecture was no more than a plan, so we adopted what seemed a sensible point of departure and assumed that the traffic would not change. In practice, however, our architecture changes reduced network traffic, which resulted in a further 20% cost optimisation after the migration.

New scenarios for the client’s environments

Many companies believe they are using their environments 24/7. In practice, however, some environments only work at night (night processing), while others go live only when developers are at work, between 7 am and 6 pm, and nothing except backup is done outside of this time window. We analysed the way in which our client actually used the environments in place and proposed new operation scenarios. 

We wanted to demonstrate which environment should go live at what time and when it can be safely switched off to avoid unnecessary expense, or at least reduce the costs, because a machine generates costs just by being kept on, as we explain below. 

Optimising STORAGE to cut costs

When a cloud-based virtual machine is off, you don’t need to pay for CPU or RAM, but you still have to cover the costs of STORAGE. This is why another important task we faced was that of optimising the use of these resources and cleaning up anything redundant (that had accumulated over many years). We changed the structures related to document and file storage, cutting off many outdated elements. A STORAGE clean-up is a necessary step in any conscious migration, because whether you want it or not, this is really the only resource you pay for 24/7.

Post-migration support and maintenance

The client decided in favour of cloud migration but lacked the relevant in-house expertise, not just when it came to Azure migration and deployment, but also maintenance and usage analysis. We stepped in to provide that support so that the client would not be left to their own devices at any stage. To wrap up the project, we set up the necessary alerts and instructed the client on how to take care of the new infrastructure to prevent the costs from spiralling out of control. 

Even though we shared so much know-how, which the maintenance team assimilated under our guidance and now routinely uses to monitor usage, the client decided to continue our cooperation. In a sense, we took on the role of a big brother who works daily to analyse costs and tell the client whether everything is going according to plan. It is worth adding that the Azure platform keeps growing, adding architecture improvements and new features. By staying in contact with the client, we are able to react to these developments in real time; whenever an interesting feature comes up, we suggest further changes to boost infrastructure security and cut costs.

Azure migration – how long does it take?

It took us more or less a quarter to analyse costs, suggest optimisations and design the new infrastructure. When the client got our estimates and decided on a scenario, they set one condition: the migration should take one year even if it could be done faster. A migration of this kind can be pulled off in 2-3 months, but, as per our client’s request, we extended the process to make sure it would not affect the client’s business growth and projects. As a result, developers and other teams hardly noticed the migration as it happened.