The cloud migration plan

Your mapping exercise leading from the current state to the desired state is the root of your cloud
migration plan. The migration plan takes the map and adds specifics such as priorities and sequencing.

You should set priorities within your plan based upon a combination of business factors,
hardware/software factors, and other technical factors. Your business liaison team should work with
the operations team and the business units involved to help establish a priority listing that is widely
agreed upon.

For sequencing the migration of your workloads, you should begin with less-complex projects and
gradually increase the complexity after the less-complex projects have been migrated. As with running a pilot project, you will gain valuable experience while migrating applications with lower complexity and lower business risk, which can help prepare you for the more complex and more business-critical migrations.

Your cloud migration plan will be more of a process than a static plan document. In its essentials, your plan will actually be a compilation of a number of smaller plans that deal with the migration of each departmental workload, based upon the sequence you establish. The particulars of each migration will generally follow this pattern:

1. Analysis This is the process illustrated earlier in the discussion of mapping the current state to
the desired state. This process will help you to identify the gaps between what you currently have
and what it will take to migrate that workload to the cloud. Those gaps might involve changes to
the architecture of the workload or might require a complete rewrite of the program. Additionally, many legacy programs will require significant work to make them more performant and scalable, and you should identify this work during your analysis of the workload.

2. Application migration When you determine that a particular workload should be moved to the
cloud, it is a best practice to create a version of the workload with a minimal amount of data in
order to get the application working on the cloud or to build a new version of the application there.
If the application is already running on a VM, it might be possible to simply migrate the VM to the
cloud without further changes. In general, many on-premises applications can run on Microsoft
Azure with minimal or no changes, but this does not mean that the application will be optimized
for performance, scalability, and security. So, you might need to redesign and rebuild the
application, to some degree, by using modern service-oriented principles.

3. Data migration This is somewhat similar to the application migration in that the data structure
can be moved as-is to either a relational (Azure SQL Database, SQL Server in Azure VM) or
nonrelational (blob, table, queue, Azure DocumentDB, and so on) location on the cloud. Several of
these kinds of migrations are extremely easy, and you can conduct them with the help of a wizard
such as the SQL Server Azure Migration Wizard. However, you might want to consider rebuilding
the data model as a new Azure SQL Database to gain performance, scalability, resiliency, and
security improvements. If you need to synchronize data between on-premises and SQL Database
or between different SQL Database servers, set up and configure the SQL Data Sync service. In
addition, it is a best practice that you set up and configure a data recovery plan in case of user
errors or natural disasters.

4. Optimization and testing After you migrate your application and data to Azure, perform
functional and performance tests. At this phase, test your application in the cloud and confirm
that it works as expected. Then, compare performance results between on-premises and Azure.
After that, resolve any feature, functionality, performance, or scalability issues in your cloud
application.

5. Operation and management After the testing and optimization phase, set up and implement
application monitoring and tracing with the Azure Application Insights, which enables you to
collect and analyze telemetry from your application. You can use this data for debugging and
troubleshooting, measuring performance, monitoring resource usage, traffic analysis and capacity
planning, and auditing.

You can use the Microsoft Operations Management Suite (OMS) to manage applications running
both on premises and off premises. OMS provides a single view of all your applications, regardless
of where they are hosted.

These five phases of migration will be conducted for each workload that you want to migrate.
However, there is also an iterative process that is greater than any one migration, by which you can
begin moving applications that meet your initial minimum standards, based on priority and sequence.
When the initial group is migrated, you can then begin to work on making more applications and
hardware eligible by upgrading operating system/SQL versions, getting current with all security patches, moving applications on physical machines to VMs, addressing issues caused by multiple IP
addresses, and so on.

Source of Information : Microsoft Enterprise Cloud Strategy