Coming up, if you're considering the benefits
of moving your on-premises VMs or workloads to the cloud,
we'll take a look at how you can discover
and assess your Windows and Linux VMs,
migrate your workloads and optimize them in production.
And what's more, you can also leverage
the Azure Hybrid Benefit for Windows Server
to use your existing Windows Server licenses in Azure
and lower your costs by up to 40%.
Now running your VM in Azure IaaS gives you access
to a global cloud platform.
This translates to a number of advantages,
from freeing up time spent
managing your virtual machine hosts
to now future-proofing your platform for scale
to the ability to take advantage of the intelligent security
in Azure, with its machine learning and global monitoring
to help you protect your apps running in Azure,
on-premises, or wherever.
Of course, there are some prerequisites to get started,
and I'll walk through them.
You'll need an Azure subscription, and there's a free trial
to get you started.
You'll want to start small, to get experience with your apps
and so let's walk through the basics
of the migration process to Azure.
Here, I'm in my VMware vSphere environment,
and as you can see, I have an application
that consists of multiple virtual machines
in a three-tier configuration.
Now we're gonna start with Azure Migrate,
a new service we recently released to preview.
This helps me find my on-premises VMs
and application environments and assess them
for migration to Azure.
I started in the Azure Portal by searching for "migrate"
and creating a migration project.
Now I'm gonna click here on Discover & Assess.
This will launch a two-step process.
First, we're going to the discovery,
which will literally discover your on-premises VMs
using a virtual appliance called the collector.
Once we select Discovery, you'll also be prompted
to download a collector appliance.
This is a complete, preconfigured OVA,
or Open Virtual Appliance, that you import into vSphere.
Azure will generate your unique project ID,
which you'll need to supply when initiating your discovery.
So make sure to copy your project ID and project key.
Now I've set up a collector VM in the ESX environment,
and from a remote browser, I'm logging in to my collector VM
where we'll kick off the discovery
of our on-premises environment.
Keep in mind this is a read-only inspection of your VMs
and their metadata, including performance history,
which we'll use for right-sizing in Azure.
When you first launch the Azure Migrate Collector tool,
you'll be asked to go through three primary steps.
You're gonna set up your prerequisites,
it'll prompt you to accept the terms,
check that you're connected to the internet,
make sure your time is in sync with the internet time server
and of course make sure you have a current version
of the PowerCLI installed.
If not, it will automatically install it for you.
I'm gonna click here on Continue,
and move to Discover Virtual Machines.
Now, under Virtual Machine Discovery,
here is where you're gonna provide your credentials
for the vCenter server that you are attaching to,
and the read-only discover of your machines.
Well, you can see we've done that,
and we'll click on Connect.
Next, we'll select project.
By selecting project,
you're asked to enter the migration project key
that was generated in Azure
when you created your migration project.
From here, once you've clicked Continue,
it will kick off the discovery by reading the metadata
of your VMs and you can watch the progress
and complete collection.
Let's go ahead and do that too.
Now one things I want to point out is
note that there's no agent installed here.
We're simply talking to the vCenter server,
reading the configuration data for the virtual machines,
their virtual processors, memory size,
disk, network configuration,
also collect the performance history of the virtual machines
such as CPU utilization, memory disk networking,
which we'll use for right-sizing later.
Now this will make a few minutes
depending on the number of VMs,
so I'll use the collection I ran earlier.
Back in my migration project in Azure,
I can see that I have 215 virtual machines
that have been discovered,
and I'm gonna go ahead and move to step two,
which is to create an assessment.
I'm gonna click on Create Assessment
for the multi-tier application we saw earlier
in the vSphere environment.
I'll give the assessment group a name, like Mechanics,
and I can choose to select all VMs,
but in this case, I know the ones that I want to migrate,
which all have the word "tier" in the name.
So I'm gonna do a search for "tier,"
and I'm gonna select all of these,
and when I click the Create Assessment button,
this will create the group with these VMs
and compute the assessment.
I'll click on the assessment,
what you can see here called Mechanics,
and then select Azure readiness.
Here, you can see the detailed view of the VMs
and other properties.
You'll see all of your selected VMs
and an assessment of whether or not
the VM is ready to be hosted in Azure.
Keep in mind if the VM is not ready for migration,
it will give you a reason and point you
to documented guidance on the next steps.
Now if we move to Cost details, you can look here
at the aggregate monthly cost estimates for compute
as well as storage,
and you'll see the corresponding Azure VM size
recommended below, based on the performance history
of the VM details and storage requirements and more
for each VM.
If we go back to Azure readiness,
you'll notice that most of my VMs can be migrated
by Azure Site Recovery, or ASR,
which is our primary migration tool.
Now you'll notice here
in this first virtual machine DataTierVM01,
that it's detected that I have a VM running a database.
In fact, let's widen this a little bit.
You can see in this case, My SQL, and it recommends
that I use the Azure Database Migration service.
Now we'll cover this on a future Mechanics episode.
If you click on Edit Properties,
you can tweak things like the target Azure location,
the currency, and you can also factor in existing discounts
like the Azure Hybrid Benefit to estimate the 40% discount
into your migration cost assessment.
Also, one more thing to call out here.
If you're unaware of your application topology
and dependencies, you can download an agent
to a dependency map of the VMs in your group.
We'll also cover this scenario
in a future Mechanics episode too.
So now I'm gonna go back to my assessment overview
and I'm going to export the assessment report.
Now this report gives me the information that I need
to set up my Azure environment,
including Azure VM readiness, VM sizing,
and cost estimates for compute and storage,
and I can drill into this per VM.
And keep in mind, if you need to show the folks in finance,
they really love to see stuff like this
in an Excel spreadsheet.
So now that I feel good about my discovery and assessment,
I'm ready for migration.
For VM replication and migration,
we use Azure Site Recovery in the Azure Portal.
This service is typically used
for disaster recovery scenarios, as the name suggests,
and the same process is used for migration.
You'll also see us streamlining both the ASR
and Azure Migrate tools in the near future
to derive more cohesiveness between the discovery,
assessment, and migration.
Azure Site Recovery will follow four steps.
Number one, set up your target environment in Azure
using the information from the assessment report.
Two, download and import Azure Site Recovery
configuration server and process server
into your vSphere environment.
This is essentially the replication assistant for Azure.
Third, replicating the VMs that you want to migrate to Azure
and finally, switching your production environment to Azure
once you've tested everything in Azure.
So let's start.
If you're new to Azure, you'll need to do a few things
to set up the target environment
that should sound familiar before we start replicating.
First, you'll need to set up a place to store your VMs.
In Storage accounts, click Add and then give it a name.
Choose the kind of storage, performance, and subscription.
I'm gonna go ahead with the defaults.
Then create or assign a resource group
and pick the location.
We'll skip the virtual network here
but we're gonna configure that next.
So now, let's add a virtual network.
In the virtual network's blade, we'll click Add
and then we'll give our network a name,
address space, resource group assignment, etc.
Now I'm skipping the address number assignment to save time
but here you'd need to assign the number of addresses
needed up to 256.
The last step is to prepare to receive replicated data
is to set up the Recovery Services vault.
I'll go to Recovery Services and add a vault.
I'll select Add again, give the vault a name,
assign a resource group
and a location of Western United States number two.
Now we have the area, a prerequisite set up
to start replicating our VMs.
With your Azure target environment set up,
the next step is to prepare your on-premises
VMware environment for VM replication
and test failover and to ultimately migrate production
to Azure.
In Site Recovery, you'll open the Site Recovery blade
to see the steps for preparing your infrastructure.
We're going to select Prepare Infrastructure,
then select the protection goal,
which is to state the environment source, target,
and virtualization details.
Now we're gonna click on Deployment planning.
We did this during the Azure Migrate steps,
so we can select Yes, I've done it.
Here is where you point to the target source.
If you've already done a migration or site recovery,
your existing vCenter environments are listed here.
If not, click on Configuration server
and that blade highlights all of the resources needed
to get replication running.
As with the discovery, we'll download an OVF template
to manage the ongoing replication of your VMs.
This appliance will replace Azure Site Recovery's
existing unified setup if you do not already see it
in your Azure tenant.
ASR uses a configuration server and process server
to coordinate the replication
between your on-premises vSphere server and Azure Storage.
Data is only replicated to your Azure Storage account
and no running components are needed in Azure
until you perform test or production failover
to spin up VMs in Azure.
Now both environments are connected
and ready for the command to begin replicating.
To ensure you only replicate what you want,
you go back to the Azure Portal to enable replication.
Now I've already gone through this process to save time
and you can see there are six replicated items already,
but I'll show you how to enable one VM.
I'm gonna select Replicate to show you how this works.
First, you select your source, your vCenter server,
and this is important as you can have multiple vCenter hosts
that can be set up as the source.
Then you select the configuration of your target environment
in Azure, your storage account that you set up earlier
to replicate your VMs, and we'll configure the network
in just a moment.
From here, you're going to select the VMs
that you want to replicate and in this case,
I'm gonna do a search for "FrontTier"
to pull up my VM that I'm looking for.
There it is, I'm gonna click OK.
And now we can select my storage options.
I can select the disks that I want to replicate
and in this case, I'm just gonna keep the default disks
to replicate and use this account.
Now here, you can set your replication policy and settings
and click here to enable replication.
Now, in the interest of time,
I've already started the process of replicating
my six VMs, as I mentioned earlier.
Now we need to set up a recovery plan to automate the steps
to get your migrated VMs running.
To set up the recovery plan, go to the Recovery plans blade,
select Add Recovery Plan, or plus Recovery Plan.
We're gonna go ahead and give it a name, like Mechanics,
and select the target Microsoft Azure.
We'll use the resource manager model
as we've done throughout the process.
Now we'll select our VMs, and I'm gonna go ahead
and select all of them and Azure will create a default plan
that spins all of these VMs up simultaneously.
Now in my case, I'll customize the plan,
and here is where you can define stages of recovery.
So for example, if you want the backend
of your multi-tier application to come up first,
then the middle tier, and then the frontend,
you'd set up those stages all right here.
So, okay, now everything is almost set up.
Our VMs are replicated, I've created a staged recovery plan,
and now to complete the migration.
I'm actually gonna failover to Azure
and just keep my VMs there.
Now before I complete the migration,
I can review each VM and specify my compute
and network configuration settings for all of my VMs
before I migrate them.
In my Recovery Services vault for the app I'm migrating,
I'm gonna click into the Replicated items
and here, I'll see the status of my replicated VMs.
You'll notice DataTierVMO2 isn't healthy,
but since it's a mirror of VMO1,
I'm okay with that right now.
I'll select DataTierVM01, then Compute and Network,
and here you can see I have a comparison of what I have
in my data center and what Azure has assigned.
You can see how on the right-hand side,
you'll see an Azure VM size selected by default,
but you can change this with the information
from the Azure Migrate assessment we did earlier.
Under Network properties is where we'll attach
the replicated VM to your selected Azure network.
All you need to do is select the target network
that you created earlier,
also we estimated the cost savings
with Azure Hybrid Benefit for Windows Server.
Here is where I'm gonna apply it.
So I'm gonna do that, confirm it, and click Save.
Now you can do this for each of your VMs.
In the future, as we integrate Azure Migrate with (Azure Site Recovery),
the information from your assessment
will be automatically integrated.
Once you save your changes and go back to your recovery plan
you can then do a test migration, test failover,
which allows you to test if your VMs are running in Azure
in an isolated environment.
Once you've tested your failover, you can then
use the failover option to move the production VMs to Azure.
Here, it will make sure, in fact, it will even ask you
and verify that you've tested the failover ahead of time.
In this case, you can choose the recovery point
and whether you're gonna shut down VMs before beginning.
We recommend that you take the source application offline
in the on-premises data center during the migration window
to ensure zero application data loss
as you migrate VMs to Azure.
Now, after clicking OK,
your virtual machines are running in Azure,
and as you can see right here,
the virtual machines from my VMware ESX environment
are now running in Azure.
I'll do one final search here using Tier,
and everything is running.
So that was an overview of how to migrate
your VMware Windows Server workloads to Azure.
You'll see us streamlining this process more and more
over the coming months, and we welcome your feedback
on the Azure Migrate tool,
which is in preview at the link shown.
You can also visit the Azure Migration Center
for more information, but of course,
once your workloads are in Azure,
now you have a vast array of options opened up for you.
In fact, you can learn more at the playlist shown.
Thanks for watching.