4 Tips on Migrating to Microsoft Azure
Chris Kirk
Lead Cloud Developer & Architect
12/04/2021

A few months ago, one of our colleagues bought a new house and went through the process of moving. To anyone that has ever been lucky enough to buy a house, you know that it is never completely straight forward, and you wish you knew certain things going into it that would have made the move a lot simpler and stress free.

The same can be said when you move, or migrate, from on-premises into the cloud. The cloud is a very different prospect to working on-premises, and when you take it on there are critical areas that would be good to be aware of rather than knowing about these things in hindsight.

Because of this, we’ve put together 4 key areas for migrating to the cloud.

Diagram

Description automatically generated with medium confidence

The Foundations

Before any workloads are put into the cloud, you need to get the foundations absolutely right. This is important to get right upfront because it’s incredibly difficult to correct the foundations later on when workloads are in the cloud.  You wouldn’t want to try and fix the foundations on your new house after it’s been built after all.

What do we mean by the foundations in Azure? The main consideration is around your networking – so we are talking IP ranges, connectivity, and security.

You will need to create your cloud network architecture around a “hub and spoke” design, where your core infrastructure and external connectivity back to on-premises exists in the core, and your workloads or environments exist as spokes off the core. The core then acts as your single secure point in and out of the entire cloud environment, improving and simplifying your security posture.

Within the core, you should concentrate on securing inbound and outbound traffic for your workloads with a security device like you would on-premises. This is known in Azure as a network virtual appliance, or NVA. This would reside in the core where all workloads in the spokes either go back to on-premises, or interact with this NVA if their destination is outbound to the Internet.

If you do not have a preference of NVA the Azure Firewall is a great option, where high availability works out of the box.

You will also need to plan your IP ranges carefully.  You’ll need to ensure there is absolutely no overlap not just in the cloud environment itself, but also to any on-premises ranges that will be interacting with the cloud infrastructure.

Diagram

Description automatically generated

 

Bandwidth

If you are migrating workloads to the cloud, you’ll either want to migrate an entire virtual machine as-is or just data from a source.  Either way, you’ll need to take into account how much bandwidth you have available from on-premises. Nearly all these solutions will replicate data over HTTPS to the relevant Azure service, so this will not be over a WAN or VPN circuit, just simply outbound.

If you only have 100Mbps available for example, you will need to take that into account when data or VMs needs to replicate, or how much you can move at the same time. You’ll also need to remember that your outbound connection might be needed for other services, so you will need to be careful to leave some bandwidth available or risk disrupting your other outbound services.

Right sizing

When you run your virtual machines on-premises, there’s no penalty to you where you have a virtual machine using 16GB of memory of 128GB of memory – therefore sizing the resource against what is actually needed is unnecessary and so rarely done - but this is a must for the cloud. When you move to the cloud you are moving into a “pay-for-what-you-use” cost model (operational costs instead of capital expenditure), so a VM in the cloud that is assigned a lot of memory or CPU is going to cost you more, and costs can quickly spiral out of control.

Therefore, it is important to include in your migration plan time to analyse your workload performance requirements and right size them for what they actually need in Azure. We recommend observing 30 days’ worth of performance information at a minimum to get an idea of CPU, disk and memory usage and map these to a relevant Azure VM size.

We recently worked with a customer on a migration where they had a virtual machine with 200GB of memory on-premises. When we delved into it the VM only actually needed 64GB of memory, but the VM had been re-purposed over the years, hence the high allocation. The difference between the two would equate to around 250% difference in cost – a decent chunk of cash.

A picture containing text

Description automatically generated

In Azure it’s also worth noting that right sizing isn’t a one-time activity, and you can resize a VM at any time. So even if you are not confident you have enough resource once you’ve migrated, you can always change it.

Test, test and test again…

Migrating virtual machines that have existed for a long time on-premises can be a daunting task, especially for those critical services, often leaving you praying that everything goes right. When migrating virtual machines into Azure there is the option for you to test your migrations without impacting your live systems. This is an incredibly important step that often does not get enough airtime in migration planning but can save you a lot of pain in the long run.

For this to work effectively, you need to do some planning for your architecture upfront. The key to this is the creation of an isolated part of your cloud networking architecture that you can access inbound, but with limited outbound. The outbound point is very important as it prevents the VMs you’re testing from interacting with your production systems.

You can then perform what is known as a “test failover” – this creates a copy of the real VM and places it into your isolated part of the network in the cloud. You can access the VM, perform any tests required, and then clean this up when you are finished. You can also test multiple VMs together, if you have critical dependencies between them, for a wider testing plan.

From experience performing test runs of VMs should be a key activity in your overall plan and we have certainly seen many examples where doing this has identified quite a few issues before migrating VMs for real.

Conclusion

Migrating to the cloud doesn’t need to be daunting or complicated but there are some key considerations that need to be factored in when starting your journey – considerations that differ from your traditional on-premises environment.  With careful planning and a good target operating model you’ll set the right path for your onward journey. Our IA-Cloud platform can do all of this for you to ensure it’s right from the outset. From initial analysis of your on-premises environment, to architecting and building your target environment, IA-Cloud can have you up and running in a matter of hours – a bit like hiring a specialist removals company to help you move house.

And speaking of moving to a new house, our colleague does not advise doing it in the middle of a global pandemic…

 

IA-Cloud is our automated management, monitoring and optimisation platform for your Microsoft Azure workloads. IA-Cloud’s revolutionary automated build service will create a best practice Azure environment, with detailed and automated technical design documentation, dramatically accelerating the start to your cloud journey.

And once you are in the cloud, IA-Cloud continues to assist you with automated management, monitoring and optimisation services, allowing you to get the best out of your cloud infrastructure.

Why not find out more at https://www.ultima.com/ia-cloud

 

 

 

 

 

 

 


Full Name