Migrating to Azure, Stage 1: Assessing your environment

For all Microsoft customers still using SQL Server 2008 or SQL Server 2008 R2, here’s an important reminder: You’re getting closer to the end of extended support date – July 9, 2019.

After July 9, Microsoft will no longer provide free security updates on-premises, non-security updates, free support options, and online technical content updates.

Even with the deadline fast approaching, you still have options to ensure you don’t put yourself in harm’s way. You can either upgrade to the latest on-premises versions, or you can migrate your workloads to the Azure cloud.

If you’ve opted to take the latter path, we have you covered.

In our four-part series on Azure migration, we’re going to examine what steps to take – and when to begin them – to ensure a successful migration. And it starts with assessing your environment.

You should start the assessment stage now, if you haven’t already, as we estimate the full migration process will take up to 13 weeks, and July 9 is closer than that.

Evaluate workloads or groups of applications

You’re interested in migrating some or all of your workloads to Azure. Now what?

First comes an analysis of your environment. You need to know what it takes to run a particular application and what communicates with what so you don’t find out the hard way that you have a disjointed or disconnected application after it’s transferred to the cloud.

The analysis is a thorough evaluation of all your workload groupings – all the interconnected application parts. For example, in a web application, you might have a web front end (a web server), the middleware (the actual application), and the backend database that powers the application.

This gives you a complete understanding of all the interconnectivities among the components that make up a particular workload.

Gather performance statistics

After you evaluate all the workloads or groups of applications, the next step is to gather performance metrics. This allows you to accurately size all the workloads in the cloud.

In traditional infrastructure, most companies are over-provisioned because it’s harder to scale quickly and dynamically on premises. With the cloud’s consumption billing, however, what you use is what you pay for, so your goal is to determine exactly what you need to run the workload in the cloud.

The performance statistics you need to gather include:

• CPU utilization
• Memory consumption
• Storage/storage consumption
• IOPS

Also look at how the network topology is structured, how many different segments the network has, and how many need to be created in the cloud.

Data collection typically takes a couple weeks to get a complete picture of the peaks and valleys of each workload. You’ll have right-sized cloud infrastructure without overprovisioning, which is likely the case today, and a sense of the data growth patterns. One thing to watch out for during this assessment phase: Avoid major changes to your VMs, such as shutting one down, or decommissioning one and spinning up another with the same name – changing out VMs could throw your data off.

Measure important data and uncover the best migration options

You’ve collected the appropriate data, now you have to use that information to determine the best migration course.

Establish “averages” – average CPU consumption on a machine, average memory utilization, average data growth over a particular period of time, and so on. This will help you project data growth into the future and determine the best machine and storage options.

When migrating to the cloud, you have six methods available to you: retire, retain, re-host, re-platform, repurchase, and refactor. Using the data you’ve gathered and measured, determine which of these methods best suits a particular workload.

For example, after assessing performance statistics at a college, we made the following recommendations: 83 workloads re-hosted, 10 workloads retained, 10 workloads repurchased, and two workloads retired. We established these conclusions based on several different metrics.

We retired two legacy workloads that were already being phased out since migrating didn’t make sense. We repurchased 10 workloads where relevant platform services were available – for example, backup services in the cloud run as a marketplace application. We retained print servers and other workloads running desktop services and other local infrastructure on premises.

Everything else was re-hosted, lifted and shifted to the cloud without any complications.

The goal of the first stage

The assessment stage is about getting a better understanding of what you need and what you’re trying to accomplish. Once you’ve collected and assessed all the information, you’ll be able to formulate a plan and make an educated decision on next steps.

Stage 2 involves developing your migration strategy. But we’ll save that for the next post. Take a look at the full migration plan in our infographic to understand where you should be in the migration process and what our next post will cover.

If you have any questions about migrating to the Azure cloud, contact your SHI account executive.