(dramatic whooshing)
- Welcome to Azure Essentials.
I'm Matt McSpirit, and in the next few minutes,
I'll give you an overview of your options for migrating
and modernizing almost any workload
as you move it to the cloud in Azure.
In fact, the sheer act of migration,
whichever path you choose,
whether Infrastructure as a Service
or Platform as a Service,
this opens the door to the modernization of your workloads.
But more on that in a second.
The good news is we have numerous programs
and tooling experiences for migration and modernization
that come together in the free Azure Migrate Tool.
It's the hub for large scale migration of your servers,
databases, web apps,
and even virtual desktop infrastructure.
This includes streamlined discovery
of the resources you want to migrate,
assessment of their readiness for migration,
along with the act of migration itself.
Additionally, built-in extensibility with popular
existing tool sets help to ease your learning curve.
Now, the Azure Migrate experience is designed to be
a central place to track your progress
as you move to the cloud.
In fact, in the next few minutes,
I'll go through some of the essential things to know
as you go down your migration and modernization path,
and share a few real world examples along the way.
So, let's start with virtual machines.
Migrating VMs means moving their operating systems,
installed applications, and any data contained in them,
intact into Azure Infrastructure as a Service.
This is sometimes referred to as lift and shift.
And once you've migrated to Azure,
you'll continue to have control over how you manage your VMs
in a similar way to how you're currently managing
your VMs on-premises.
Now, there are other options I'll get to later
where the contents of your VMs,
like your web app front-ends, can be extracted and directly
migrated onto our managed Platform as a Service options,
like Azure App Service or Azure Kubernetes Service.
And the contents of your VM back-ends can be moved
to PaaS databases or managed instances in Azure.
But before I go there,
let me explain how the virtual machine migration process
works and some of the basics of Azure Migrate.
So here, everything starts with a migration project.
Within that project,
you have a discovery and assessment phase
that's followed by a migration phase.
For the discovery phase, bringing this back to our VMs,
in most cases you'll be using a virtual machine appliance
to find or discover your virtual machines.
And there are specific appliances or scripts for VMs
running on VMware, Hyper-V or physical servers,
along with virtual servers running in other clouds.
The appliance is granted access to read details
about server size, as well as running processes.
And this information, including software inventory,
dependencies, and more is then logged
up into the Azure Migrate Service in Azure.
And under the covers, the appliance measures
utilization over time for VM sizing recommendations
as part of the assessment.
Speaking of which, once the discovery period is complete,
from the Azure Migrate Experience in the Azure Portal,
we'll then create an assessment.
And the assessment comprises a few things;
Azure readiness, which is a measure of which servers
are suitable for migration to Azure.
Sizing recommendations for the appropriate
virtual machine type if you bring your VM over to Azure,
which helps to right size your VM and avoid paying
for more than what you need.
And finally, monthly cost, to estimate how much compute
and storage costs will be post-migration.
You'll then use the information from the assessment phase
to target the machines to migrate into Azure.
When you're ready to migrate, the process then starts
by replicating running machines into Azure storage.
Once the initial replication for a VM is complete,
the service will continue to replicate those delta changes,
and this process is block level and near continuous.
When you're ready to cutover and put the migrated
virtual machines in Azure into production,
to prevent any data loss, the final process will shut down
your virtual machines on-premises
and do one more replication sync into Azure.
And once that's complete, the Azure hosted VM is started up
and it's migrated.
You literally just have to point your network traffic to it.
Now, while I walked through the process of migrating
a handful of VMs, organizations all over the world are using
the same tools and processes at scale.
For example Celcom, a telecommunications leader
in Malaysia, use this process to assess more than
800 machines and migrate 50 VMs per week,
while maintaining business continuity.
You can find out more about Celcom
at aka.ms/CelcomMechanics.
And the American Cancer Society were able to
cut their number of provisioned VMs by nearly 2/3,
from 900 to 350, using the information
from the discovery and assessment process.
They then used Azure Migrate to move
those 350 servers to the cloud.
And you can see their full story at aka.ms/ACSmigration.
Now that you understand the basics of Azure Migrate's
discovery, assessment and migration process,
let's move on to database migration.
Now, of course, using the options I just highlighted
for VMs, you can migrate a database running in a VM
in the same way, except there are additional options
with SQL Server to migrate just a single database
or a database instance to Azure without bringing over
the operating system.
And this move to PaaS has a lot of benefits.
So, here the assessment process begins by downloading
the Data Migration Assistant or DMA,
which is a Windows application that connects
to your SQL Servers.
Once you connect it to your source servers
and your target in Azure,
DMA helps you assess your database migration
and find potential compatibility issues.
It also logs discovered information into Azure Migrate's
database assessment, so you can manage migrations at scale.
And from the Azure Portal,
you can see all the details about each database instance,
all the way down to individual databases,
with any migration blockers, breaking changes,
readiness evaluations, and compatibility levels.
Now, when you're ready to migrate your database
or managed instance to Azure,
you start by creating the service in Azure
as an empty vessel to receive your data.
And from there, you use the Azure Database Migration Service
or DMS, to migrate your SQL database or instance.
You can migrate the data while it's online or offline.
And once you've securely connected your source server
to your target in Azure and selected which databases
you want to migrate, DMS will then access database
backup files and replicate those into Azure Storage.
Similar to the VM replication process from before,
DMS will continually replicate new backup files.
And once you're ready to cutover,
you'll stop incoming traffic to your database,
perform one last backup,
a tail log backup in SQL Server Management Studio.
And once that's complete,
you perform the migration cutover,
and then the production database will be running in Azure.
And then you just need to make any required database
connection string changes, and you're fully migrated.
And using this process versus lifting and shifting
an entire VM running SQL Server
means you won't need to worry about managing, patching,
or securing the underlying host OS.
So, you can just focus on the data.
And again, this process is proven to work
at a massive scale.
Capita Reading Cloud in the UK,
helps manage 8,500 school libraries,
and they use these processes to migrate
more than 100 databases per day and 10,000 total,
with just one person at the helm.
Hard to believe?
Well, you can check it out at aka.ms/CapitaMechanics
for more details.
Similar to the process for SQL Server migration,
your web apps are likely running on servers
as either .NET apps running on Windows Server
or Java apps running on Apache Tomcat.
So, let's walk through that process.
Starting in the Azure Migrate Portal,
you use the same discovery process for VMs to inventory
your on-prem servers, .NET web apps,
it'll look for Windows servers with
the Internet Information Services or IAS roll installed
and log that information into Azure Migrate.
From there, you can create an assessment to find
which apps are ready to migrate,
and any issues or conditions to correct before migration.
It also gives you a detailed cost estimate
to run targeted apps in the Azure App Service.
Now, for the migration itself,
you have two primary options to not only migrate,
but also modernize your web apps for the cloud.
The first option is to use
the Azure App Service Migration Assistant.
It automates the creation of site resources,
and then extracts and migrates web app content
into the Azure App Service.
And from there, it configures the required connections
to backend data services, whether they are located
on-prem or in the cloud.
The second option, as mentioned earlier, is containers.
Take for example, Eltes, a digital risk management company
in Japan that modernized their server-based
app infrastructure with minimal downtime
by shifting their app front-end to containers in AKS,
so they could easily add new functionality
and scale more dynamically without having
to manage the underlying infrastructure.
In Azure Migrate, you can containerize
your current web app servers running Windows Server with IAS
or Apache Tomcat on Linux,
using the App Containerization Tool
to repackage them as containers.
And once you've done that,
you can then easily bring them into AKS to take advantage
of the broader orchestration
and scaling capabilities it provides.
So, that was a quick overview of your options for migrating
to Azure, with help from Azure Migrate.
Whichever path you choose,
whether Infrastructure as a Service
or Platform as a Service, this opens the door
to the modernization of your workloads.
Now, to go deeper on all the options I presented today,
along with guided tutorials,
check out our migration and modernization playlist
at aka.ms/MechanicsAzureMigrate.
And for hands-on assistance from experts for your project,
check out our Azure migration and modernization program
at azure.com/ammp.
And keep watching Microsoft Mechanics
for the latest updates.
Bye for now.
(dramatic whooshing)