>> You've been hearing a lot about migrating to the Cloud.
But what are the migration phases and what are
the various strategies that real-world organizations have taken?
Learn more in this episode of Data Exposed.
[MUSIC].
>> Hi, I'm Anna Hoffman and
welcome to this episode of Data Exposed.
Today I'm joined by Raj,
a former manager on the Azure Data team.
Raj, thanks so much for joining us today.
>> Thank you so much Anna for your time.
Let me introduce myself.
My name is Raj Pochiraju and I'm
a Principal Program Manager in Nagios SQL.
My team score focuses to double
up the database migration tools that really
enable you a seamless SQL Server database migrations
from your own premise system environments to Azure SQL.
>> Awesome. It's great to have you on
the show and I believe we're really kicking off a series.
We'll link to the whole playlist in the description.
But Raj, before we get into
deeper topics related to migrating to the Cloud,
I'd love to get your take on what is the migration strategy
or process or is there
standard guidance on how customers should think about this?
>> Sure, I think at first I definitely want to talk
about the various phases that
are involved in the migration journey.
As you see on the screen,
there are four different phases that
customers really take when they
take lead at the migration journey.
The very first phase is essentially
you go on and discover your environment and then
scan through your application portfolio and really understand
which of those applications are ready to migrate to Cloud,
and then which of these applications are a good fit
for Software as a Service?
Which applications are a good fit for
infrastructure and platform as a service kind of stuff.
You do that analysis as part
of the discovery and assessment phases.
You really also want to understand
which of those applications that you really want to do.
A lift and shift migration also called as a rehost migration.
Depending on the effort that is being involved to do
the migration and there are enough investment.
You really make some art picture
and decisions to see whether you are going to be adopting
a rehost migration or are you going to refactor some of
your workloads to migrate to more modern platforms on the Cloud.
You make all those decisions
in the phases like discovery and assessment phase.
Then after that, there is a phase called migrate phase
where you start migrating your schema
and then you are migrating your databases and as well as you are
migrating any other artifacts
that your applications are dependent on.
Then you also think about,
how much migration downtime that you have
and what type of migration method that you are going
to be using so that you can really enable
that migration to meet your migration downtime SLA numbers.
You adapt some of those tools
that really help you to meet your migration needs as well.
As matter of fact, you also wants to
understand is it onetime migration?
Is it more of a coexistence migration that
you want to make sure that both source databases and as well
as the target databases are going to
be having read and write operations at the same time?
You would come and then do
the migration cutover at some point of time.
Based on how you plan,
you pick the specific tools and
services that really help you to do those migrations.
Once you really migrate,
the next step is to optimize.
The Cloud migration journey did not
stop as soon as you get to the Cloud.
I think the journey starts there.
Well, now that you get used to the Cloud,
the next step is that, how can I start
leveraging the Nato Cloud services?
That you can really use
those Cloud services to deoptimize your customer experiences,
optimize your investments into
the Cloud and then essentially you can really
invest more so that you can
really make your customer experiences much better.
Then the final stage is secure and manage.
Usually, security is not something that you would really
think towards the end of the migration journey.
Security and privacy is something that
you would think through the entire migration journey.
But what I really mean by secure and manage is,
now you can really start leveraging some of
the native capabilities that are built into the Cloud
that you can really start securing using
the Nato Cloud services to start securing your databases,
securing your data, securing your access layers
and everything that you can really leverage
those Cloud Nato services.
Especially Azure has lot
of capabilities that you can really effectively
manage your resources as well, manage access controls,
manage your growth in terms of
the Cloud resources you can really use,
manage your resources and as well as
manager your cost using those management services.
That's a typical migration journey
that the customers really go through.
>> Awesome, thanks, Raj. That's been really useful.
It's nice to see at high level what
the process and the guidance is and that that guidance exists.
That's great to see.
I would love if you had any examples of big customers that
do these big type of migrations
and any tips and tricks or how they did it.
>> I'm more than happy to share with you.
I definitely want to take the MSIT example itself.
MSIT is a large enterprise that you can think of.
The way that they took their migration journey is
that like I mentioned in the previous slide,
where you have discovery and assessment phase,
where they really scan through the applications,
you know you're talking about approximately
more than 3,500 applications.
They really put them into different buckets as you see here.
Their five percent of the applications came
through remain on premises because of
the complexity and legacy nature of those applications.
We did not really find any value migrating
those applications by taking
that complex migration journey and migrating to the Cloud.
That's five percent of the applications reminds on-prem.
Then there is another 30 percent of the applications that
also we decided that
we don't want to pursue the Cloud migrations is because,
either we know that they are going to be retiring at some point of
time or we know that
some of that functionality has been added to
the new applications that we recently built.
That really give us an opportunity to eliminate.
First of all, some of the workloads that we
don't want to migrate to the Cloud to begin with.
That is really important as well at the same time because you want
to prioritize which applications that you want to migrate,
which applications you don't want,
and which applications that you want to migrate at first.
Then there are 50 percent of the applications that
really we decided that
some of these applications we want
to do a lift and shift migration,
migrating to more of a Infrastructure as a Service Platform,
and there are some applications that we
can really do little more investments by
refactoring them and then we can really start leveraging
the Cloud Nato way of migrating past services.
Bunch of our applications really fall into
that bucket where either we migrated to
IaaS or whether we migrate it
to Platform as a Service depending on how
ready those applications and how
much effort that is really involved migrating those.
Then there is a 15 percent of the applications, for example,
some of the applications that are not customer-facing but
they're used for internal applications like e-mail services,
and as well as the CRM applications that we use to
manage our internal assets.
Those are the applications that we started looking at.
Can we use any solutions
that are available on the shared ready device?
So that is where we really started
leveraging Software as a Service.
For example, Dynamic CRM is one thing that we
really migrated our customer management applications.
Then we also migrated our e-mail services to Office 365.
That way we really segregated
all these different application workloads into multiple buckets.
That really helps us to plan migrations really well.
>> This is really interesting. It also gives a good perspective
on how other big organizations are actually thinking about,
what they're actually going to migrate,
how they're going to migrate it,
and even evaluating if
they should even migrate it and continue to sustain it.
From Microsoft's perspective, Raj,
how are we thinking about our migrations as an investment?
>> We are making heavy investments to really
help customer migrations seamless as much as we can.
There are three different areas that we are really investing.
The very fast area is the tools and services that really help you
to take the specific migration journey
that I talked about in my previous slide.
The tools that really help you to do the discovery of
the SQL Server estate of the database estate,
and also find out the application dependencies,
and then do the readiness assessment and help you to do
the actual target fit in terms of what
specific TS and skews that my workload can
fit to render the similar and exceeded performance,
but at the same time also optimizes my cost.
To help you to do all that kind of analysis,
we have tools like Azure Migrate
that really help you to do the discovery and
assessment and then find out
the cost estimates migrating to the Cloud.
Then we also have a DMA tool,
Data Migration Assistant tool,
that really help you to reassess your SQL Server databases.
We have tools like Data Experimentation Assistant
tool that you can really do
a performance validation even before you
migrate how your target is going to respond to you.
Then we also have a tool called SSMA,
SQL Server Migration Assistant tool,
that especially help you to migrate from
the heterogeneous sources like Oracle Sybase DB2,
that you can really migrate to Azure SQL.
These are the tools that we really
invest and then we keep updating
them with the newest capabilities
and everything that really help you
to automate some of your migration journey there.
Then, we also invest heavily in engineering programs.
We know that some of the migrations are complex.
It's not a tools problem, to begin with,
if they're complex and then you need
a lot of guidance in terms of Cloud adoption,
how the Cloud is going to look like in terms
of your policies and everything,
and then take you to the migration journey.
It requires a lot of planning.
We have programs like AMP, Azure Migrate program,
and FastTrack where we really provide engineering vital experience
for those complex migrations with zero cost for you actually.
We really provide that engineering vital experience to you.
Then we also get a lot of learnings through
our tools and as well
as working through the programs with the customers.
We got all the learnings and we
really document all those migration best practices into
the Database Migration Guide and that link is already
provided there which is datamigration.Microsoft.com.
You can really use that link to get that
step-by-step guidance to take migration journey.
>> Awesome, wow, Raj. It seems like there are
a lot of resources available from
a tools perspective as well as from getting
that hands-on help if it's something you needs,
and then this data migration guides which is going to give you
a custom source and target guides for your migration.
This is been really useful episode Raj.
Any final tips for folks that are just
getting into looking at the migration space in their strategy?
>> I'm sure that you are going to provide some references,
resource links into some of this video.
I really suggest that you leverage
those links to understand more about our migration journey.
But if you really run into any issues, obviously,
please consider that Microsoft
is there to help you to take your migration journey.
>> Thanks Raj, that's really useful
and this has been a really great episode for me to
learn more about the different migration strategies
and especially the migration phases,
and it was also interesting to see
a real-world customer or Microsoft IT,
MSIT, how they actually went about
doing it and what they actually migrated and when.
Thanks so much, Raj. For our viewers,
if you like this video, please like
this video and subscribe to our channel.
Leave us a comment and check the links in
the description because we have
lots of references for you to learn more.
We hope to see you next time on Data Exposed.
[MUSIC]