Even if we have a lot of customers already using a lot of native Cloud services, we still have a lot of servers still running on the private network. One of the potential scenario is to migrate them in the Cloud.

We call Move2Cloud scenarios where we want to migrate the servers in the hyperscale Cloud. There are many reasons to stay on prem, but also a lot of others to embrace the “Cloud model” and Azure is a great plaform for this, also because of the historical licensing model (windows, SQL) and things such as AHUB and ESU.

After running many of these projects in the past 7 years, I think that the key challenge is not just to migrate machines
AS IS, but really make sure that when they land in the Cloud, they are really managed the Cloud Way, and not as we used to do it on the on-prem.

Doing “Legacy in the Cloud” is something we want to avoid, it cost money, and provide low efficiency.

As IT professionals, we also want to anticipate the maximum of things before the migration. During this migration, or after the migration, we don’t have time to speculate and face technical problem.

If we anticipate and fix problems at source (on prem), we can concentrate our effort on the move2cloud itself. As a result of that, the cost of migration will be lower and the global satisfaction, at the opposite will be very high.

To help customers on this journey, years after years, Microsoft has regrouped different tools in one “free bundle” called Azure Migrate.

Azure Migrate helps customers and partners assess and plan such projects.

In this blog Post I would like to share with you some tips, to go far beyond what Migrate can give you, and of course get a higher success.

For that, and after a bit of introduction on the classical way of doing such assessment, I will show you how to boost such project leveraging Azure Arc.

For those of you who do not know Azure Arc, have a quick look at this blog post: <AddURL>

I believe that Azure Arc, when deployed as a step 1, will bring you very important enhancement:

It will go deeper in the assessment, including health, security, network. You will understand more the environment, and better plan the migration
You will be able to identify and fix (anticipate) the maximum of technical challenge, far before the migration
The migration will be quicker as you will focus only on this part, lowering the number of post migration problems
And finally, when the servers will be migrated, they will be managed “the cloud way”, with natural tools and methodology. No “legacy in the Cloud” !

Azure Arc, when deployed the first minute will help you to reach that cost at almost no extra cost.

In order to convince you the benefits of that approach, let’s first have a look at a classical to run an assessment, and let’s enhance this as we progress.

The first Discovery (Envisioning): Should I stay (on prem) or Should I go (cloud)

Moving in the Cloud is not something we must do. It results of different criteria and of course require a qualification project. For this, we will gather a lot of information, analyze them and finally take your final decision.

This is the right moment to leverage that great Azure Migrate. We need to assess the current environment, and analyze the data captured, of technically but also from a cost perspective.

Migrate is deployed very quickly, less than one hour, and will capture relevant data during a few days, to have a clear vision about how your infrastructure works.

For example, it wil look at the real usage of your VMs (cpu, ram, disks) and based on this data, it will simulate what would be the architecture in Azure and the corresponding cost.

This will give us very quickly – at no effort and at no cost a very clear projection of what the future may look like.

Azure Migrate can also can go “inside” the VM, via an agent, and assess the running processes.

Just to give you a global vision of Azure Migrate offer, have a look at this screenshot:

You can see on this screenshot the notion of “check the dependencies, especially network traffic”. We will see that important part later in this article.

Just to summarize, at the end of this phase, we will look at all the data we have gathered, will merge this with our strategic vision and finally decide whether or not we continue.

Let’s assume that GO is the conclusion and see the next steps.

The Second Discovery (deep dive): planning your technical project: we need more information and go deeper !!

When the GO has arrived, we will need to go deeper in the analysis, especially on the technology side. The stage 1 helped to validate the vision, but now we need to talk about planning, cost, and success of the project.

As mentioned, Azure Migrate is a bundle of multiple tools and one is called Log Analytics, especially a subcomponent called Service MAP.

This component is magical as it scans constantly the network activity and can tell you what machine is talking to what machine, and also service/service.

To discover more the power of Service MAP, have a look at this deep dive article: <ADD LINK>

This captured data is super useful when you plan your “Waves of migration”, I mean a bunch of servers that frequently talk to each other and that you want to migrate together (wave) the same night or WE.

Yes, migrating all servers takes some time (and down time) and we don’t want to kill the network or reduce the performance once they are on the other side of wire. Partial migration is what we want to avoid.

So far this is great, Azure Migrate provides all these great services. But I would like to start to put some warnings here to show some limits and start to position the Arc way :

This assessment requires to deploy the monitoring agent in each VM via script, and an extra component called the extension. This has to be done manually or via a deployment solution.
It is free a few months, and only for this Service MAP service, not for all Log Analytics great services . Extract of the online pricing documentation (Pricing – Azure Migrate | Microsoft Azure) :

I think that this approach is sufficient for the first discovery phase, but the second one, where we need to go deeper to anticipate a maximum of challenges, it is in fact quite risky.

And as you will see very soon, why should we need to do 2 assessments, why don’t we do only 1 with all the data we need?

This is where the hybrid story proposed by Microsoft (on top of Azure Arc). It can can bring your more value if you diploy at the first minute.

As you will see later, going Arc the first minute you will :

have a deeper discovery,
you will fix problems before the migration (not during or after),
and you will even your server “the Cloud Way” before the Migration.

Now you have a very good overview of what Azure Migrate, if used alone, can bring to your project.

Also, we have introduced that Azure Arc, if deployed, will bring you more value.

Let’s see now in details each “value” that Azure Arc can bring to you.

Challenge 0: one full assessment, rather than 2 assessments

As time is money, this 2-assessments approach has to be addressed and fixed: we should do only one but definitely more detailed.

It will make our Go/Nogo decision even professional, and then, we can quickly go the planning phase.

As we analyze the environment on more Axis, we will be able to have a deeper understanding on the next steps, reduce the cost, and at the end be more successful.

So Azure Migrate is fantastic and mandatory, but deploying Azure Arc on top is also quite mandatory.

Challenge 1: Deeper assessment

Again, the goal is not to move VMs, it is to be as successful as possible (timing, cost, security, customer satisfaction).

Here is how Arc will help you to reach that goal:

To install Arc, you will just need to install the Arc Agent. Once the machine is registered in Azure Arc back-end, all the configuration required will be deployed automatically by Policies
The policies will deploy all the components we need to reach that goal : log analytics, extensions (network, SQL), others)
Once the components are installed, as each of them has been pre-configured, we will be able to capture all the Axis I mentioned previously:
- OS and Software inventory: assess the OS running versions, service packs, applications. Identify potential problems such as one software running with different versions (security risk). Update our CMDB.
- Patch management: identify machines that are not up to date, os/security/drivers. Update your process, and pilot it from Azure automation.
- Application configuration errors: Assess your running applications such SQL And AD, identify configuration errors.
- Assess network and process traffic (Service MAP) : leverage pre-configured/advances reports provided by my team. Identify your “waves” of migration.
- Even leverage 30days free solutions such as Defender or even Sentinel (SIEM).
- Etc.
Once assessment is done, we also have deployed the natural tools to run these servers in Azure. Monitoring, patch management, security… will be deployed before the migration. No extra work on these important chapters after the migration.
- Your machines will be managed the right way, before the migration.
- You can anticipate the trainings required by your team.

As you understand, once the Azure Arc agent is installed it will register the machine in Arc. Because the logic is called “policy driven” configuration, your policies will trigger and deployed the right tooling, and each application will capture the right data and store it in one central place called an Azure Log Analytics workspace. Then either in the Azure Portal (your machine will be seen as an Azure VM thanks to Arc) or via reports, you will have a 360 vision of your infrastructure.

If you decide to ask a partner to help you, one of the challenges they will have will be to propose the best methodology, so understand your environment, and identify the risks.

By providing such deep dive assessment, you will reduce the “unknown” and the partners will be able to be more accurate, and remove the “cost” of the unknown.

Challenge 2: Fix the health problem before the migration not after!

During the deep assessment you will have a 360 vision of the infrastructure:

Are you 100% accurate on patch management?
What about your event logs, in windows and Linux, are there a lot of errors?
What is the performance (ram, CPU, IOPS, … application)
Do you follow all the performance and security recommendations provide by Microsoft?
Is your CMDB up to date? Do you have a configuration documentation for each of your App? What if we change the IP?
Etc.

The deep dive assessment will give you that strong visibility so you will identify and fix problem at source, when you have time, under low pressure.

Challenge 3: Deeper network discovery

Service MAP will be identical as Azure Migrate’s version, but we bring some extra reporting that will go further.

Also we will correlate such network data with the other components deployed by Azure Arc such as software inventory, patches etc.

To learn more about MAP have a look at this deep dive article: <Link>

But to give you the flavor, this is how you will see your network, based on Service MAP, capturing server/server traffic:

Challenge 4: Anticipate infrastructure management post migration, and do it from day 1 “the Cloud Way”

What we want to avoid in Move2cloud projects is called Legacy in the Cloud. This is a situation where after the migration, we continue to manage the infrastructure as it is on prem, so we don’t get the benefits of the cloud model.

This goes for the VM pricing (not shut down VM at night for dev test), but also for all the software we used to work. Either use Microsoft “Azure” management services, or even sometime, the same application but with the cloud model in mind. A lot of partners (ISV) are present in what we call the “Azure Market Place”.

As you have deployed via Arc the native management solution (for assessment) from the first minute, your teams will be trained and will have extend the experience.

For example, they will create different reports or even alerts, to reproduce what was “good” on the OnPrem, but also leverage the new services provide by the Cloud.

Then, as you migrate the VM, they will land in this new environment called the Cloud, and will be managed the Cloud way without any effort.

Again, you will concentrate your effort and money on the migration, not on pre/post tasks.

Challenge 5: Optimize the project costs

The assessment phase can cost a lot of money. As machines are running application, this is very frequent to spend a lot of money on manual task to finalize this assessment.

This requires time, interviews, notes, excel spreadsheet…

Azure Migrate will definitely help on this part and reduce the cost of professional services, but Azure Arc will accelerate this as it will do a deep dive assessment.

Then, you will concentrate your “professional services” budget on this that require for sure man work, not on tasks such as assessment and CMDB.

Challenge 6: 360 visions of the infrastructure, no silo

Leveraging all the data gathered by all the solutions deployed by Arc will secure your project.

As an example of the material, we provide for free to accelerate your migration, you have an example of a report (we call this a workbook in Azure).

In the report below we have created some sections (overview, cost, network MAP, SQL, Security, Linux, AD.. etc).

Each section then contains the relevant queries.

In other words, deploy Arc, it will install all the services… then put this report, and it will render for you all the available data.

Then you can look at the data, enhance the queries, take notes… and more important take actions (mostly fix problems)

As this long workbook is great material, I have created a dedicated blog post where I provide more details about its logic, and where you can download the latest versions.
Then it takes 30 seconds to install it. Have a look at this article.

Read that post to get more details about this workbook and how to download it: https://blog.esnouf.net/2022/05/10/boostvalue-workbooks-and-kusto/

Let’s take another example: Network MAP (check this article to get more detailed examples for that service: https://blog.esnouf.net/2022/05/10/boostvalue-azure-service-map-network/).

In the “network MAP” section of the report, you have this extraction, in raw data and then via a worldwide MAP visualization.

At the right is all TCP/UDP connections generated by “your internal machines” but with “external/internet machines”.

At the left, you have a graphical representation of where these “internet machines” are located. Is it normal? Configuration errors? of course the report provide more example pour deep dive that status and identify what may require again come adjustments before the migration.

To continue to illustrate this 360 vision, this is the portal that will show your health regarding patch management. You will see the status, quantities, and will know exactly what have to be fixed, especially the process itself.

You will activate solutions such as automation to check if your machines are healthy. Here is an example regarding patch management:

I could add a lot of other visuals to illustrate that, feel free to ask.

Challenge 7: VMWare/AVS

For VMWare customers, it is possible to migrate directly on Azure, or leverage “AVS in Azure”.

In this case, the customer continues to leverage VMWare solutions usually on prem “and” in Azure. This AVS is an extra layer of their product, running in Azure. Great scenario.

When you are facing such a scenario, still, it is the right moment to have a deep analysis and make sure that everything is clean before the migration and rediscover your network.

But it is also very frequent to challenge the current environment, especially “how to leverage Azure native service on top of AVS”. This is again the case for monitoring, health, patch management etc.

In this scenario, the previous comments in this Blog are still very applicable.

What about Zero Trust

I will not define and explain Zero Trust, but it is very interesting to point out that if you review documentations regarding it, you will find also why this “deeper/larger” is important.

As I mentioned previously, the goal is not only to migrate the VMs, but to do it the right way. Reading this document is very interesting: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWJJdT

Below you can see an extract of this document, where they recommend also that multi-layer of approach. The methodology described in this Post cover most of these pillars.

Conclusion

As you can see in this Post, deploying via Arc the right tooling “before” the migration is key, and will help you to accelerate and secure your migration.

Usually deploying the configuration is just an hour of work. Then you just need to deploy the agents, the policy triggers, extra components are installed and start to capture data.

What about the cost: as you know most of the cost is based on the quantity of data ingested by Log analytics (Automation and Polices are priced per machine/hour).

But the good news is:

We know exactly what the valuable components are and how to optimize them.
Part of the report I mentioned earlier, you have a dedicated section focused on cost. Product by product, machine by machine. So, you can deploy 50 machines, look the next day, and incrementally continue the deployment. It is just an agent.
But the killer is this: when you look at the wide range of data collected, and when you look at the corresponding price, it would be totally impossible to do it manually.

I hope that this Port convinced you to include Azure Arc (and Azure-related components) in the beginning of your migration project!

Version 1.0