How to complete a successful migration to Microsoft Azure

Many organizations succeed at deploying resources in or migrating to Microsoft Azure, but many of those same organizations fail to ensure Azure adoption. Why? It could be losing cost control, a failure to learn lessons along the way, and an absence of informed leadership. 

While the simplest way to adopt Azure is starting from scratch – such as a startup deploying workloads for the first time – it’s more common for a mature organization to decide to enter the cloud with new (cloud-only or hybrid) workloads only.

Often, this is a migration project. Here, the organization takes existing workloads and moves them into the cloud using one of the six Rs of cloud migration: rehost, re-platform, repurchase, refactor, retain, and retain. The movement of these workloads is what we call a cloud migration.

A group of well-informed engineers or consultants can perform such a migration quite successfully and hand over the result to the IT department. That’s great, but cloud adoption is something that can only be measured after a migration has happened. 

Adoption is when the business has evolved:

• The tools that are used are cloud-native instead of being built around on-premises servers
• Processes have changed to adapt to the agility of the cloud
• Skills have been upgraded
• The divisions between the business and the pillars of IT delivery have been broken down

Unfortunately, the above changes rarely take place on the first, second, and sometimes even the third attempt at a cloud migration. The end result? An organization feels that the cloud can’t deliver on the marketed promises. It can take a year, or even two, but eventually, most organizations will realize that adoption has failed.

Relying on informed leadership

Consider what a cloud migration project looks like. The head of IT, either a technical IT manager or a business person who accidentally became the head of IT, makes the call to move to the cloud. Perhaps the business owner ordered it for some reason, or an outsourcing/hosting contract is ending, or maybe a physical/software infrastructure is approaching end-of-life.

In such cases, the person in charge is usually given a fixed budget or timeline and, on paper, the migration project is pretty simple: build something as similar to on-premises as possible and move the workloads and data. The result is a bunch of virtual machines (VMs), operated in the exact same way as the old workloads were hosted on before. 

The IT manager and the people who report to them are focused on technology; changes to people, processes, and organization are neither high on their agenda nor within their remit. If IT is leading a cloud journey then one should expect little to change, other than the location of where the workloads is hosted.

However, this is lazy thinking. I strongly advise anyone involved to read through the Microsoft Cloud Adoption Framework. AWS and GCP have their own versions. This explains that a cloud journey should start with the leadership. 

The motivations of the business must be understood and documented as part of a cloud strategy. That cloud strategy will document exactly how the organization is going to change while it enters the cloud. 

Such a document requires the leadership to have taken the time to understand what the cloud is and what it can offer – and it must be more than “we’re going to the cloud”. Your strategy must then be communicated to everyone to say changes are happening to the organization, processes, tools, and skills.

The skills and knowledge for a cloud migration

Now, as always, there’s a skills shortage in the IT industry, but it’s never seemed so extreme as now. Many organisations are taking a plunge into the deep end of the cloud and they need people with the right skills and knowledge to help. 

Cloud-specific knowledge is vital to any successful adoption. Knowledge of traditional systems is useful, but new skills are required. The trouble is that a migration is usually done by a select few: either consultants or an elite internal “cloud team”. The IT staff that run things on a day-to-day basis are often left out of the entire process: 

• Decide what processes will be used to deliver IT services to the organisation
• Determine how IT staff should be reorganized to break down rigid processes and failures of the past
• Identify the tools that must be used to support the new processes and IT organization
• Calculate the skills gaps between staff and their new roles and immediately organize training

Then, someone will say “we should schedule a handover”. The migration team will perform a series of presentations over a series of meetings and the IT team is given the keys of a rocket ship when all it’s ever driven before was a small car. The cloud adoption framework shows how changes should be brought to the organization before anything is deployed into the cloud.

An informed IT department will be an asset in the cloud migration project. More staff are now available to work on the project. Trained staff can provide better information to the migration team and be participants instead of remote observers. When the migration is complete, the trained staff are familiar with what is being deployed and will be ready to adopt it.

Why legacy IT may seem cheaper than the cloud

When an organization enters the cloud, its top three concerns are often hitting the deadline, security, and compliance. Then something happens post-migration: the person who signs the cheques starts noticing detailed monthly invoices from something called Microsoft Azure and they get a serious case of sticker shock.

The organization doesn’t understand what the cost of legacy IT is. Every three to ten years, there’s a big server purchase. Some hardware and software are acquired for a cost and as far as IT is concerned, that’s the cost of running those workloads. The space that the computer room consumes, the cost of electricity, the price of cooling systems, all that other stuff is someone else’s problem. The cost of IT is simple: some tin from Dell, Lenovo, or HPE, and software.

Once you enter the cloud, things change to a consumption model: the more you use, the more you pay. The inverse holds true too. That cost is invoiced every month, so the cost of workloads in Azure is visible very quickly. However, the cost includes the cost of everything that enables “VM in the cloud” plus the margin for Microsoft to keep the shareholders happy.

The true cost of IT is much higher than some tin and some software. This is why cost management replaces the aforementioned concerns after a cloud migration. The fear of never-seen-before costs can prevent adoption and “cloud repatriation” has emerged to describe the reversal of cloud migration, primarily because of the lack of cost management.

Azure includes cost management features to observe, manage and even reduce costs. The most important tool to learn and use is Azure Cost Management, which lets you observe the costs of resources in your tenant, subscriptions, or resource groups. Coupled with publicly available pricing documentation, you can understand how Azure usage creates the invoice that you get from Microsoft. Reports can be generated. Budgets can be set. Alerts can be set up when budgets are exceeded or when a budget is forecast to be exceeded in the current billing month.

The cloud is a self-service environment. Operators and developers can deploy whatever they want; self-service is essential to deliver on the promise of agility. But a common failure is to “ban” self-service – shadow IT will return and the bills will sneak in another way, along with security and compliance issues. A better way is to control self-service through IT governance. 

The primary tool to enforce governance is Azure Policy. Policy initiatives can be created and assigned to control what can be done. For example, one can block expensive resources, enabling overrides when the business requires them.

Keeping cloud costs under control

So, how can you reduce costs? Start with cloud-native architectures. Traditional IT deploys a few big VMs or even just one huge VMs for big workloads. The cloud implements elasticity by deploying auto-scaled collections of smaller compute instances. When activity increases, the number and cost of instances increase. When activity decreases, the number and cost of instances decrease. Cloud-native architectures aren’t for every workload – some recoding will be required and that’s not possible for old or off-the-shelf software.

Then there’s appropriate sizing. It’s amazing how many oversized compute resources one finds when performing an assessment for a cloud migration project. Once a resource is in the cloud, Azure Monitor can be used to analyze the resource over time. If there is waste then the resource can be reduced in size, resulting in lower costs.

Also, consider reserved instances. Several resource types offer a discount if you commit to using a resource for one year or three years. The discount varies, depending on the time commitment and the size of the resource. Finally, some on-premises software, such as Windows Server/SQL Server with Software Assurance, can be redeployed to Microsoft Azure to remove the cost of the same software in the cloud. 

Cloud adoption happens after the migration completes; it’s a commitment by the business to stick with this new platform and to start consuming new types of services to build workloads. Process, tooling, skills, and organization change to remove the friction of traditional IT and to deliver on the agility promise of the cloud. However, if a cloud journey doesn’t tackle some key challenges, adoption will fail and the same uninformed leadership will start to ask some very tough questions before they start to make some staffing changes.