What if you were able to achieve both efficiency and innovation in all business domains and applications across your entire portfolio? What if you could take advantage of the cloud and all of its resources and features to get a “the whole is greater than the sum of its parts” effect? With a good road map and proven strategies to lead the way, you can. We have done extensive research into what it means to move an enterprise environment with its application catalogue to the cloud. In the recently published e-book “Enterprise Cloud Strategy” by Barry Briggs and myself we provide examples and learning experiences from Microsoft’s own journey, as well as from those of our customers.

Read the eBook that provides strategies to help you build your own road map.

We highlight the different migration approaches and detail their benefits and complexities:

• Re-host. Move a VM or an operating environment from the on-premises datacenter to a hoster or cloud. This model is also known as co-location.
• Re-platform. A legacy environment becomes unsustainable based on cost or operational requirements; a solution is to “retain and wrap” the application without making changes to the code, possibly compromising the integrity and security of the operation.
• Retire and rewrite (or re-envision). When there are sufficient new requirements that cannot be met by the older environment, the best way to proceed is to rewrite the application in a newer, better-suited environment. Often this occurs when examining the portfolio of applications and consolidating several that have similar function.
• Burst out. With all of the new compute, data and service models that are being provided in cloud environments, each providing capabilities and capacities that were never before accessible to an IT environment, many applications are bursting out to the cloud. These applications are doing innovative types of analytics, reporting, high-performance computing, visualization, and so on. Keeping frequently used (“hot”) data locally while aging-out infrequently accessed (“cold”) data to far cheaper cloud storage is another common pattern.
• Expand. Enterprises are now exploring how to expand their older applications and how to add functionality to provide to mobile devices and Web front ends with the same capabilities that previously were limited to a computer screen. They are even moving to enhance the applications with search or video services, as an example.
• Cloud-native applications. As companies begin their investigation of the cloud, they frequently realize that there are new forms of applications like Big Data, new types of analytics, entirely new capabilities such as machine learning, and applications for the Internet of Things (IoT) that are uniquely fitted to live in the cloud.

As an example, the cloud migration plan we recommend will be more of a process than a static plan document, and the particulars of each migration will generally follow this pattern:

1. Analysis. This is the process 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.
2. Application migration. When you determine that a particular workload should be moved to the cloud, a best practice is to create a version of the workload with a minimal amount of data 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. 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 non-relational (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 to 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.

Adapted from “Enterprise Cloud Strategy” by Eduardo Kassner and Barry Briggs. Kassner is the director of cloud solution architecture in the Worldwide Enterprise and Partner Group at Microsoft. Briggs is an independent consultant with a long history in software and enterprise computing.

Download the e-book now.