From large financial organizations to tiny health startups, most companies have made significant investments in cloud technology. In fact, 72% of US executives say they are either using cloud based solutions or plan to do so in the future. Many of them have already migrated workloads to the cloud. Nearly 40% of companies are adopting a cloud-first strategy. What’s the
draw?

Agility and scalability are frequently cited as the top reasons for cloud migration. Long gone are the days when you build an application and run it unchanged for years, and “digital transformation”, which often implies a mix of application modernization and cloud adoption, is now a mainstream concept. A cultural shift in favor of customer-obsession and pressure from nimble startups has pushed most industries to adopt cloud technologies relatively quickly, even risk-averse financial and healthcare companies.

Azure has also actively courted risk-averse companies by strengthening security and governance controls that the industry needs. Azure has achieved nearly every compliance standard an organization could want, and there’s reason to believe that they hold themselves to a higher standard than many corporate datacenters. Beyond basic encryption, firewall, and logging services, there are now new services like Azure Security Center, a tool that gives you a high-level view of security alerts and compliance status across your Azure and on-premises deployments.

This is only a preview of our full Azure Migration eBook — download here.

The Migration Process

The process of migrating existing applications to Azure is complex and often involves stakeholders from every part of an organization. Therefore, it’s important to spend time upfront to acknowledge that cloud migration is not just an IT project — it affects many different groups, and often requires a close collaboration between finance, compliance, product, systems, and other teams.

If you are preparing for migration, start by understanding the standard Azure migration process. We divides the process into the following five phases:

Each cloud migration project is unique. But the success of any migration depends on understanding your organization’s current and target state, and the steps required to get to the target state. Armed with this information, you can set the right goals and help your team succeed in the cloud.

STEP 1: Migration Preparation and Business Planning

The first step in any migration project is to bring together key stakeholders to discuss and finalize your goals for moving to the cloud.

After helping thousands of organizations move to Azure, the Azure team created the Microsoft Cloud Adoption Framework (CAF) to provide guidance for each unit in your organization. According to Microsoft, the CAF helps each business unit understand how to update skills, adapt existing processes, and introduce new processes to take maximum advantage of the services provided by cloud computing. The CAF is organized into six focus areas to help organize your efforts:

By breaking down the process into focus areas, each business unit can better plan for the impact of cloud adoption. The CAF is usually delivered in the format of a live, in-person workshop, facilitated by an approved CAF workshop partner like Logicworks.

The ultimate goal of the Microsoft Cloud Adoption Framework is to unify stakeholders and create an action plan designed to move your team from cloud goals to cloud implementation.

STEP 2: Portfolio Discovery and Planning

When tackling a project of significant magnitude, the most challenging part is deciding where to get started. If you already have a project in mind for migration, this step is relatively simple; but if your infrastructure is spread across multiple data centers or multiple teams, without a unified set of metrics for assessing applications, it can be very difficult to identify the set of applications that are best suited for the first wave of migration.

Selecting the right applications for migration is both art and science. A combination of the right data and the right expertise can help you make it through this phase.

UNDERSTAND & DOCUMENT YOUR CURRENT INFRASTRUCTURE.

In order to identify the right applications for migration, you must have a common method for analyzing, documenting, and evaluating your current infrastructure.

This is where using an architecture assessment solution can help collect and analyze infrastructure performance, usage, and configuration from on-premises or virtualized servers. It funnels that data into a single dashboard, and can even make recommendations for the cost of running that application on the public cloud.

Using a SaaS tool is far more efficient than asking individual data center teams to inventory application infrastructure, which can take many days or even weeks. Data collected from various teams may be in a different format, making comparisons difficult. A unified, SaaS-based assessment process helps business decision makers compare apples-to-apples in order to make the right migration decisions.

DETERMINE WHICH APPLICATIONS TO INCLUDE IN FIRST WAVE OF MIGRATION.

Once you have collected data on your current systems, it is time to determine the best applications for migration.

There are many criteria to determine the “best” applications to migrate; hopefully, in Step 1, you have identified your business’ priorities, and can decide whether you are simply looking for the applications with the greatest cost savings on public cloud (determined through a pricing catalog), or the applications whose developers require greater agility.

If you haven’t migrated to Azure yet, the best approach is to begin migrating the workloads with the fewest dependencies. This allows you to ramp up slowly, building expertise and confidence before tackling the more complex workloads. Another approach is to start with the workloads that have the most over-provisioned, or idle resources. Industry research suggests that as many as 30% of on-premises servers, both physical and virtual servers, are zombies (showing no signs of useful compute activity for 6 months or more). On top of that, more than 35% of servers showed activity less than 5% of the time. As long as you rightsize your cloud deployment on Azure, these workloads will see the greatest price/performance improvements once migrated.

CHOOSE A MIGRATION STRATEGY.

Once you’ve determined your end state and which workloads you will begin with, you must decide on a migration strategy. You may have multiple different strategies depending on the workload, application, and business unit, but organizations typically pick one of the following options:

1. Lift and shift. This approach allows you to keep the application mostly as is, and make any necessary adjustments to run on Azure. This is one of the fastest approaches, and there are many migration tools that can assist with the process.
2. Partial refactor. Some aspects of your applications can remain as is, but other parts may need to be rebuilt to operate properly on Azure. A partial refactor may also leave the existing application as is, and build additional supporting services on top of it.
3. Full refactor. A full rebuild of your application is the most time-consuming approach, but it also represents the greatest opportunity to take advantage of the elasticity and availability of Microsoft Azure Cloud. This could also be a good opportunity to break an application down into microservices, or build out a container-based architecture.
4. Transition to SaaS or PaaS. If the workload you are migrating is a commodity application (e.g., email, CRM), or has commodity components (e.g., a relational database), you can incorporate a SaaS or PaaS into the mix. This will help accelerate migration plans, as well as reduce management overhead.

A lift and shift strategy is the simplest and fastest approach, and is the most common method for companies that are migrating their first applications to Azure. However, be aware that you may not see significant cost savings on Azureif you use this method, as you may not be able to use some of the cost saving services of Azure, like horizontal scaling, managed databases, and more.

DECIDE ON THE RIGHT TEAM TO ARCHITECT, BUILD, MIGRATE, AND MANAGE YOUR CLOUD.

A mistake many teams make is to assume that Azure is “easy”. While it is true that you can spin up a new Azure VM in minutes, architecting and managing a growing Azure environment requires the same level of expertise as someone managing any complex system. Your team can choose either to train your existing team in Azure, outsource work to an external team, or to partner with a company like Logicworks that will build, migrate, and manage your cloud alongside your in-house team.

Many companies hire a partner to go through the first phases of migration alongside their team. This allows the internal team to get some experience on Azure, while having the support of an expert Azure team to reduce risks and help you avoid common mistakes.

STEP 3: Design

The last question to consider is tactical, but complex: what will your infrastructure look like on Azure? Which instance types should you use, and in which configurations? Which Reserved Instances should you purchase to maximize your investments?

The ultimate goal of the design phase is to deliver a target reference architecture that is approved by all stakeholders identified in Step 1. This process usually involves the following steps:

• Look at historical performance data across CPU, memory, network, and disk for servers, and across throughput, capacity, and IO for storage.
• Decide how much “headroom” you want to give each asset (typically 25%), and then look at the actual minimum, maximum, and average usage across these metrics to determine which instance type makes the most sense on Azure. A virtual machine is considered undersized when the amount of CPU demand peaks above 70% for more than 1% of any 1 hour. On the other hand, a virtual machine is considered oversized when the amount of CPU demand is below 30% for more than 1% of the time during a 7-day period. Looking at 30 days of history is sufficient, because it is easy to scale up resources on the cloud if you need to. When going through this process, it’s critical to normalize for different generations of physical infrastructure.
• Design a strawman Azure architecture, both in the form of an architecture diagram and a list of proposed services including VMs, block storage, VNs, etc. and associated costs.
• Share with key stakeholders identified in Step 1. If you involve security and compliance teams in the design stage, you will be much more likely to meet your project deadlines than if you involve them after the infrastructure is built out.

Read the rest of this eBook by downloading it here.