Introduction

As many of you may know I have been involved with Azure from its very beginning. As a Microsoft Architect Evangelist, and later as a Consultant, I have helped many Microsoft customers and partners adopt Azure successfully.

Some of these engagements have involved creating brand-new greenfield applications to run in Azure. However, many of them have involved either the migration of existing on-premises applications and infrastructure to Azure or the implementation of a Hybrid approach that spans both Azure and on-premises infrastructure and applications.

When faced with the desire to take advantage of Azure in some effective way most companies are in a quandary as to what to do first and how to go about it. For many of them we have recommended and executed a Migration Assessment Project. That is the subject of this article.  It covers what is in and out of scope for each phase, the deliverables of each phase and the actors involved.

In this article we assume that the project will be delivered by a Consultant (or a consulting firm) to a Client company. Note that this methodology is also suitable for internal use within a company.

It covers everything from the time that an initial Statement of Work (SOW) is signed until the final Assessment Report is delivered. It does not include the procedure for developing an SOW, as that will differ by company.

It also does not include detailed procedures for installing any automated analysis tool like Cloudamize, Movere or the Azure Migration Assistant, although such tools are highly recommended.

It also covers only Migration Assessment. Procedures for detailed Migration Planning and Execution are out of Scope for this document. However, at the end of the Migration Assessment Project a rough preliminary plan may be developed. How far to go with that should be agreed upon prior to the assessment.  Note that Planning involves developing a detailed plan for migrating specific applications/systems/workload to Azure. Migration Assessment stops with the identification and prioritization of the applications/systems/workloads that are likely migration candidates.

We have taken the approach here of just listing bullet points in most cases because explaining every one in depth could result in a book-sized document instead of a blog post. Nevertheless, this should give you a good starting point.

The Procedure

Phases

Every Migration Assessment project has the following work phases:

1. SOW Completion
2. Internal Project Preparation
3. Pre-Kickoff
4. Kickoff
5. Functional Meetings
6. Analysis
7. Engagement Completion

SOW Completion

SOW Development occurs some time before the Migration Assessment project itself. We are including it here for completeness even though it is not strictly speaking a part of Migration Assessment. It covers from the time that an SOW is deemed necessary until the SOW is actually approved by the Client.

Internal Project Preparation

This phase is internal to the consulting organization executing the project. 

• Review the signed SOW.
• Identify and commit the Consulting Resources to work on the project.
• Create a Project file in a plan repository such as SharePoint.
• Determine if an automated discovery tool like Cloudamize, Movere or Azure Migrate will be used.

Pre-Kickoff

• Ask the Client to fill out a Pre-Migration Assessment Questionnaire. This should include questions on business objectives, facility locations, technologies in use, licensing considerations, etc..
• Schedule the Kickoff meeting.
• If a discovery tool will be used:
• Install the discovery tool one to two weeks before the Project Kickoff. Let the tool run for at least one week. 
• Run the tool reports at the end. Format the results in Recommendations Format. Be clear that these are only preliminary results.
• Ask the Client to identify and commit resources from the Functional Areas for each meeting. These areas may include:
• Business stakeholders. (For information on deadlines, mergers, etc.)
• Application Development. (if required)
• Network architecture & operations.
• Server architecture & operations.
• Support. (Help Desk, Tier1/Tier2 support)
• Application Development support. (Quality Assurance, Production migration, etc.)
• Identity. (Active Directory)
• Security. (Chief Security Officer, Security analysts, etc.)
• Storage and/or Database management.
• Enterprise Architecture.
• And if relevant:
• Sales.
• Marketing.
• Line of Business Managers.

Prepare an hour-by-hour Kickoff meeting agenda. Also prepare a presentation deck for the meeting.

Kickoff

Conduct the Kickoff meeting.

• Review the SOW and explain the Migration Assessment process.
• Determine if the Client has any preference for which applications or workloads they would like us to focus on first. Often a Client will have determined preferences in advance.
• Prepare for the Functional Meetings  by reviewing the tool reports (if used) and any  other initial documentation provided in advance.
• Collect existing documentation (Server/Workload/Application inventory) where available. This can be used to determine interview order.
• Identify the stakeholders who must sign off on the results.

Functional Meetings

Meet with the relevant audience, review the Pre-Assessment Questionnaire and confirm responses. Fill in any gaps.

• Review the relevant questions for that audience as well as any additional questions that we need answered to find out what else we need to know.
• Discuss the preliminary tool recommendations (if used). Explain that this is a first look and not final. Form conclusions and/or determine the need for additional information.

Analysis

There are two methods to be defined for discovery and analysis: an optional automated tool, like Cloudamize, Movere or Azure Migrate, and Manual Discovery. Even in the case of tool based discovery manual analysis will still be required to complete the process and draw conclusions from the data. Tool reports will just be used as input to the process.

In the case of Manual Discovery, perform the discovery process manually by collecting architecture and workload data on potential applications and workloads that are appropriate to move to Azure.

• Analyze application/system/workload documentation provided by the Client.
• Develop Current state and Desired State. (What does the tool , if used, suggest?)
• Review candidate applications for Cloud appropriateness (Fit). Evaluate whether the application is appropriate for running in the Cloud.
• Determine Business Criticality of the application.
• Evaluate potential Risks & mitigations.
• Develop a high-level cost/benefit analysis. Identify low-hanging fruit, minimum Time to Value (TTV) opportunities and the Return on Investment (ROI) of moving selected workloads/systems/applications to Azure.
• Determine migration approach such as Infrastructure as a Service (IaaS), Platform as a  Service (PaaS), Software as a Service (SaaS) or a Hybrid approach. 
• Determine the specific techniques to be used:
  • Rehost (Lift and Shift as-is to the cloud. Host in a VM or PaaS Compute platform such as Web Apps).
  • Refactor (Move to Azure with some modification to take advantage of Azure PaaS Services such as Azure SQL Database).
  • Reengineer (Restructure the complete application to take advantage of things like Microservices, Containers, Serverless computing, etc.).
• Identify the physical servers or VMs that support each application/system/workload.
• Develop a preliminary priority list for Migration to IaaS, PaaS, SaaS or Hybrid.
• Review tool data. Look for exceptions that might preclude tool use (disk size, IO, performance, configuration, etc.).
• Determine servers and/or VMs that are related and group into potential migration sets.
• Consider ease of migration and tools/approach to be used.  Consider suggested migration tools to be used such as Azure Site Recovery, Azure Database Migration Service, etc..
• Define supporting infrastructure changes required, if any.
• Identify Backup and Disaster Recovery (DR) requirements.
• Determine Multi-Region strategy if required.
• Rank applications/systems/workloads on a grid. Answer the question: Why this one vs. that one?

Engagement Completion

• Hold Internal Consulting review.
• Hold Post analysis review with the Client.
• Make recommendations on what needs to be done next.  That could include Migration of the top 5 targets.  It may also include a preliminary Migration Plan, although that plan will need to be refined following the Migration Assessment.
• Deliver preliminary cost for the proposed migrations.
• Evaluate the Client’s fitness to adopt Azure. (See  What is your Azure Maturity Level? ) This should include considering Technical and Business considerations, staff skills, etc.
• Determine the required training for the Client to make them ready for Azure and to be self-sufficient afterwards.
• Determine if the migration(s) should include a change in culture to DevOps.
• Hold the project close out meeting.
• Submit final consulting invoice to the Client.

Conclusions

An effective Azure Migration Assessment is critically important to the success of a company’s transition to Azure. No-one should attempt migration without a solid assessment and a plan.

Although the methodology set forth herein may not be applicable in every case or usable as-is for every Migration project we feel that it will be useful in developing your own assessment and guiding you to a successful migration to Azure.

As always we are interested in what you think. Let us know if you agree, disagree or have suggestions for improvement.

Bill