In the past weeks, I was working together with Tiberiu Radu from the Azure Stack Product Group, on a series of videos to show how you can migrate workloads to Microsoft Azure Stack. We wanted to show the different ways they can migrate basic workloads like Active Directory Domain Controllers, file servers and SQL Server databases to Azure Stack. We also wanted to make sure that people are aware of the different benefits that come from the fact that Azure Stack at its core is an Infrastructure-as-a-Service (IaaS) platform, like infrastructure as code using Azure Resource Manager (ARM) templates or extensions.

"The journey to the cloud provides many options, features, functionalities, as well as opportunities to improve existing governance, operations, implement new ones, and even redesign the applications to take advantage of the cloud architectures.

This video series was created in the context of the End of Support (EOS) motion for Windows Server 2008/2008R2 and SQL Server 2008/2008R2, with the target of highlighting some of the migration options. The EOS program could be a good opportunity to start this process - not only to lift-and-shift or move your servers and forget about them, instead it could be the start this modernization journey to the cloud.

As part of the EOS motion, Azure VMs running Windows 2008/R2 and SQL 2008/R2 on Azure and Azure Stack, offer 3 years of free Extended Support Updates. That means you can enable the same operational processes, use ARM templates, and usethe infrastructure-as-a-service (IaaS) platform on both Azure and Azure Stack, to start this journey."

- Tiberiu Radu

Azure Stack Migration Series Introduction

Keep in mind that there are many different options to migrate workloads to Azure and Azure Stack. It really depends on your environment and requirements. We wanted to make sure that you have seen a couple of different ways for this migrationand show you some tips and tricks by using Azure Resource Manager and extensions on Azure Stack.

You can find the full playlist with the complete Azure Stack Migration video series on YouTube.

How to migrate File Servers to Microsoft Azure Stack using Windows Admin Center

To migrate a file server to Azure Stack, we are going to use a new feature called the Storage Migration Service. The Storage Migration Service makes it easier to migrate servers to a newer version of Windows Server. It provides a graphical tool (Windows Admin Center) that inventories data on servers and then transfers the data and configuration to newer servers—all without apps or users having to change anything.

We are using the Storage Migration Service to create an inventory of the file server and the data, then rapidly transfer files, file shares, and security configuration from the source server to the file server running on Azure Stack. Optionally we take over the identity of the source server (also known as cutting over) so that users and apps don't have to change anything to access existing data.

If you want to learn more about how to migrate file servers to Azure Stack or to any other server using the Storage Migration Service, check out the following Microsoft Docs article.

There is more

In the next couple of days, we will publish more blog posts for the other migration videos. If you have any questions feel free to leave a comment.

Thomas, thanks for posting these videos, I'm going to have to spend some time going through all of them. There is one particular nuance with migrating AD to AzS which has baffled me and I was hoping you could explain it. When you promote an AzS VM to a DC, how do you prevent the DNS name from updating itself with it's private IP address when it should be it's public IP. I deployed a DC to AzS some time ago and it had issues replicating to DCs which are outside the VNET because the DNS Host (A) record kept changing to the private IP. How do you prevent this from happening?

@JohnGallucci - that's a bit more tricky because of the way a PublicIP works (the easy answer is "you would do the same as in Azure"). From "inside the VM" you don't really "see" the PublicIP. You would need to use the PrivateIP + a S2S connection to get back onprem (since your DCs would be in a Cloud environment now)...plus, not sure how ADDS would behave not being able to bind to the PublicIP.In the scenario where you still have some services outside of AzStack, you should probably create a S2S between them - something in the lines of https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/identity/adds-extend-dom... (at least for the DC replication part and have the rest of the traffic over Public IPs). Of course, this is a case by case thing and you need to understand the scenario properly, with all the dependencies, in order to design a good solution (so the solutions can vary)