Azure 101: Understanding cloud migration

Prefer a written format? You can read our insights below:

Sam: Hello again and welcome back to our Azure 101 video series. In today’s session we are going to be looking at the Migration or, what some would call, the Adoption phase of the Cloud Adoption Framework.  

The good news for you is that a lot of the hard work has been done by you already.   

So, this section is simply carrying out what you have detailed. And if you’ve just joined us on this video, it may be worth it to stop watching, and go back to the first episode, so this all makes sense.  

So, Gina how do we start to understand the Migration phase?  

Gina: Thanks Sam, and hello again everybody.  

In our last session, we learned that a landing zone is deployed before migration to form the foundation. The best approach is an enterprise landing zone where platform zones have individual subscriptions for shared resources, and application zones have their independent zones configured from the start. 

However, you can’t simply hit a big go button and wait for the magic to happen.  

No, instead, you are going to be working through a checklist before using a specific replication service to migrate the primary binaries.   

And primary binaries, by the way, are things like the operating systems, files, and security protocols that are already on your servers and that you now want in Azure.  

So, what comes first then: replication of these primary binaries and data transfer, or infrastructure set up?  

Sam: Well, the answer is a little bit of both.  

Let’s run through the start of it now.  

In the last session we saw that an organisation will need to first deploy the landing zone that they will use for their workloads. Remember the Enterprise landing zone is the desired goal here, so we’ll assume that approach.  

However, you can’t deploy the application zone until you have those application resources, which is what you are migrating i.e. your primary binaries on a server.  

Therefore, you would start by setting up the infrastructure for the platform zones, such as management services, security services like Defender for Cloud, maybe even Azure Firewall, patching and monitoring resources and so on.  

You would also apply the policies, roles and templates they each need, which we have covered in the last video. But are there any supporting services to consider here?  

Gina: There certainly are, Sam.  

You’ll firstly need to fully set up your virtual networks so traffic can move amongst your estate. This involves setting up Network Security Groups (NSGs) to define inbound and outbound traffic rules for your virtual networks.   

These NSGs should be in place before migrating VMs or data to allow or deny traffic based on those rules. We don’t want malicious attackers compromising your workloads easily.  

Also, if you need to communicate between Vnets, or with a hybrid on-premises environment, you will need to peer these virtual networks using a peering connection or a Virtual Wireless Area Network (vWAN).  

It’s a really important step to validate you have fully set up these NSG’s properly, and the peering connections since this is an area that can often get often get missed, like an RDP port being allowed to a VM in production for example.  

But what else do organisations need to be thinking of Sam?  

Sam: Well, now you have discussed Vnets, Gina, we can think about resources like load balancers. These can be internal or external load balancers used to distribute the traffic efficiently amongst your servers once they are in Azure. 

You can create these resources in anticipation of your servers being migrated to Azure. However, you would then connect the load balancer to the VM by allocating the IP address to each load balancer backend pool.  

Also, there is not always a need to reinvent the wheel. If you are moving from on-prem, you could use Microsoft Entra Connect.  

This would allow you to synchronise your on-prem identities to Entra so that you have cloud identities to work with straight away. 

This means you could then set up and use these identity services, such as Microsoft Entra business to customer tenants, to hold your customer user identity objects.  This is a great way to allow your customers using your SaaS application to authorise and authenticate.    

Staying with the identities mindset you may also need to deploy a key vault service to hold your keys, certificates and secrets.   

This is important, since recommended best practise is to NOT have your keys and secrets published in your code as it can lead to a security breach.  To mitigate this, you can set up services like Azure Key Vault to hold these keys and secrets so your application can go off and request them securely when they’re needed.  

It’s only once these platform zones have been deployed that you are ready to then look at migrating your estate.  

So, based on that, can we migrate yet Gina?  

Gina: Yes Sam… it is time!  

At this stage, you would migrate your primary binaries. For example, your servers with their operating systems and files as well as data etc.  

To do this, you can use great tools such as Azure Migrate. Alternatively, if you’re already using Azure Site Recovery to protect your on premise VM’s to Azure, you could use the service as a migration tool beforehand as well.   

This would happen by you installing the Azure Site Recovery agent on the servers you are protecting to take snapshots.   

You would have a policy set up to create the virtual machines and disks that will be needed in Azure. 

So, you could simply run a failover and, hey presto, the resources are automagically created for you and the servers with your applications and data ready to go.   

You would then reconfigure Azure Site Recovery to protect the VM’s that were created in Azure.   

Sam: That’s a great consideration, Gina so that organisations can use something they may already have deployed.  

It is, however, worth noting that whilst Azure Migrate will make right size suggestions and modernisation recommendations, Azure Site Recovery will not.   

You will need to understand what resources you need before configuring it.  

So, as we draw to a close, you can use Azure site recovery to migrate your servers, as well as Azure Migrate, which is ultimately an umbrella for a collection of tools that include:  

1. The Azure Data Migration service  
2. The data migration assistant  
3. Web app migration assistant   

These services combine to assess and then right size the infrastructure you have on premise, in a data centre or third-party cloud like AWS.   

The tool itself is free to use for the first 180 days, however, after that there will be charges to use the services.  There may be some other charges for other resources that are needed, such as for log analytics for visualisation on dependencies and storage accounts to hold your data.   

However, these are minimal, and it makes the process to migrate your workloads to Azure quick, easy and safe.  

Let’s now have a look at some of the data services you can use for migrating your data, such as Azure Data Box and Azure Import/Export service.   

Gina: Azure Data Box service allows an organisation to load their data on to Microsoft provided disks. These are transported by courier and then arrive at your chosen Azure data centre and uploaded.  

The second service you can consider is The Azure Import/Export service. This is similar to Azure Data Box; however, you can provide your own data disks should you choose or still use the hard disk drive or solid-state disk drives supplied by Microsoft.   

Each of these services allow you to use between 1 and 5 encrypted disks that you can use to store up to 8TB’s of data on each, so 40 TBs in total. That should be more than enough for most businesses to get their data into Azure.  

Sam: The nice thing here with both of these services is that the uploads are done for you, but most of all, you don’t have to worry about things like bandwidth when transferring the data to Azure.  

Once your application resources are migrated, you can set up the application zones, which, again will be 1 application zone for each workload.    

This is where you configure granular resources like Defender for Servers, Azure Monitor Application Insights or Key Vault, Azure Backup, and Azure Site Recovery for disaster recovery. These can only be set up once you have your data and servers migrated across.  

Gina: So, there you have it for the last in this season of the Azure 101 series.  

We have started to explore the Cloud Adoption Framework, showcasing the Strategy and Plan phase, to Readiness and Adoption phase.  

There really is so much content and considerations that need to be made here that we couldn’t cover absolutely everything. So, I would encourage you that if you are adopting Azure for the first time, or maybe you are already on Azure but looking to add workloads and want to sanity check that you are doing it in the best possible way please reach out.  

Both Sam and I are happy to support, and we have an army of engineers and experts that can support your cloud adoption as well, so you are not alone. 

Sam: Yeah, that’s right Gina, and we are going to be adding other videos to contextual elements of this instalment, so please do subscribe to the YouTube channel so that you get this as soon as its released.  

Gina: Thanks Sam, so for now, it’s goodbye from me goodbye. and goodbye from Sam.  

Sam: Goodbye