Overview of the Migration Life Cycle in Azure
Updated: February 26, 2015
The migration life cycle is a standard methodology that provides you the step-by-step instructions for migrating your applications and data to Microsoft Azure. The main migration steps are Analysis Phase, Application Migration Phase, Data Migration Phase, Testing and Optimization Phase, and Operation and Management Phase as shown in the diagram below.
This topic explains each phase in detail with links to further information.
Azure also supports Oracle on Azure Virtual Machines. For more informations see Oracle Virtual Machine Images for Azure.
Authors: Kun Cheng, Selcin Turkarslan, Norberto Garcia
Reviewers: Paolo Salvatori, Steve Howard, Stuart Ozer
The goal of this phase is to understand the business needs that require the Azure solution. After identifying the business goals, review the existing application architecture to identify the main differences between Azure and on-premises solutions and determine if you need to re-design the existing on-premises application to meet the business needs of a Azure solution. The following tasks and questions help you create a migration plan:
Define business requirements: There are many potential questions raised by business scenarios when an application runs on Azure:
Is Azure deployment solution targeting new customers and users?
Would it require multi-tenancy to support multiple customers?
Is the application meeting the compliance regulations when the data is hosted in the Microsoft data center(s) instead of customer sites?
Which applications are more suited to the cloud architecturally and strategically?
Which type of migration best serves my application: Migrating an entire application and all dependencies to Azure; or, migrating a portion of application to the cloud while some resources stay on-premises; or, migrating an application to web or worker roles with dependencies that work better on a Azure Virtual Machine.
- Is Azure deployment solution targeting new customers and users?
Determine feature discrepancies: Can you run your existing application in Azure with no changes? For example, Azure SQL Database (SQL Database) does not support all of the features that on-premise SQL Server does. If you want to move an on-premise application that uses CLR (Common Language Runtime) to SQL Database, you need to re-design the application by moving CLR logic from SQL Server to the application layer, or rewriting the CLR logic by using the Transact-SQL statements that are supported by SQL Database. Note that SQL Database currently does not support SQL CLR.
Starting with the Azure 2012 release, new Virtual Machine capabilities have been added to Azure. With AzureVirtual Machines, you can migrate your existing SQL Server applications built on the Windows Server platform to the Azure Platform with minimal or no code changes. With SQL Server in Azure Virtual Machine, administrators and developers can still use the same development and administration tools that are available on-premises. The performance of a relational database in Virtual Machine depends on many factors, including the virtual machine size, the number and configuration of disks, the network, the configuration of the database software and the application workload. We recommend that developers benchmark their application on several virtual machine sizes and storage configurations to select the most appropriate one. For more information, see Migrating to SQL Server in an Azure Virtual Machine.
Prepare a plan for performance and scalability: Many legacy applications were designed to be tightly integrated between the application logic and the data access components. For legacy applications, it makes sense to decouple components of the application in order to perform and scale better on Azure. If the application is too chatty or doing excessive data inquiries, consider using Azure Caching Service or implement your own caching mechanism to batch up data access queries and to reduce roundtrips between your application and data. If the application to be migrated deals with large databases or high transaction volume, migrating to SQL Database is likely to require a re-design of the database model. This is because a single SQL Database instance can handle a limited number of transactions per second and have a limited database size. While dealing with large databases or high transaction volume, consider implementing a scale-out architecture utilizing multiple databases in SQL Database or start using scale out methods instead of expensive scale-up systems in on-premises. Implementing In-Memory OLTP or delayed durability for your tables with high transaction volumes should also be considered as a means to improve performance. For more information on In-Memory OLTP, see In-Memory OLTP (Memory Optimization). For more information on delayed durability see Control Transaction Durability.
For more information on performance considerations when using SQL Server on a virtual machine, see Performance Considerations for SQL Server in Azure Virtual Machines and the whitepaper Performance Guidance for SQL Server in Azure Virtual Machines.
Azure SQL Database has released a limited Premium preview for SQL Database. By reserving a fixed amount of capacity for your SQL Database and its secondary replicas, the Premium service will deliver more predictable performance for cloud applications, relative to existing SQL Database Web and Business Editions. For more information on SQL Database Premium accounts see Managing a Premium Database and Premium Preview for SQL Database Guidance.
Prepare a plan for application life cycle management: It is important to consider application versioning and upgrade scenarios on Azure. Depending on your Service Level Agreement, you might have to maintain multiple versions of your application to support your different tiers of customers. You may also want to minimize downtime when upgrading an application on Azure. We recommend that you carefully maintain the staging environment and the production environment on Azure. Make sure that you are able to roll back upgrades in case of compatibility issues. Your upgrade roll back plan should cover first your application and then your database.
After this phase, we recommend that you build a pilot project as it gives a clear understanding of the Azure Platform services and tools.
Once you decide to migrate your application to Azure, start with a pilot version of your application with minimal data to build a proof-of-concept. First, implement necessary code changes in your application to meet the Azure deployment goals in terms of business and technical requirements. Then, compile and deploy the application code to the appropriate roles on Azure.
In general, most existing on-premises applications can run in Azure Cloud Services with very minimal or no changes but this might create some performance, scalability, and security problems. To optimize performance and to enable future scalability, we recommend that you consider re-designing your application by using multiple roles before migrating to Azure Cloud Services. For more information, see Migrating Applications to Azure. We recommend you first move your entire application to Azure Cloud Services and then the data. Due to security, performance or other reasons, some parts of the application may need to live on-premises. This requires hybrid solutions. For more information, see Building Hybrid Solutions with Azure.
If you decide to use SQL Server in a Azure Virtual Machine (VM), modify your existing SQL Server applications to connect to the SQL Server database in Azure VM. In addition, follow one of the following migration approaches:
You might have an application already working in an existing virtual machine. You can migrate this virtual machine to Azure. In this case, your application, its configuration settings, and its data are already in this virtual machine. But this might require uploading a large .vhd file to Azure. In addition, there might be some drivers and hardware dependencies on this existing virtual machine and they may not be available in Azure.
You can build a virtual machine in Azure. To do so you can initiate a virtual machine from the Image Gallery, which already contains SQL Server. Then, install your application to this virtual machine. This lowers upload time and removes the driver and hardware dependencies but requires installation of application and uploading data.
For more information on how to migrate your existing SQL Server databases to a SQL Server in Azure VM, see Migrating to SQL Server in an Azure Virtual Machine topic.
If you use Azure Cloud Services, move relational data from on-premise SQL Server to SQL Database and move unstructured data to Azure storage like Blob, Table, or Azure Drives.
If you decide to use SQL Server on Azure Virtual Machines, you might follow one of the following two migration approaches:
You might have data in an existing virtual machine. You can upload this existing virtual machine in a .vhd file to Azure.
You can build a virtual machine in Azure. Then, you can upload data in a .vhd file to Azure. Next, you can attach this uploaded .vhd file or an empty disk to the virtual machine as a data disk. You can use the data disks to store the SQL Server logs and data files. In addition, you can use the tools and techniques that are described in the Migrating to SQL Server in an Azure Virtual Machine topic to migrate your existing SQL Server databases to a SQL Server in a Azure virtual machine.
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-premise and Azure. After that, resolve any feature, functionality, performance, or scalability issues in your cloud application. For more information, see Implementing the Migration Plan for Azure.
After the testing and optimization phase, set up and implement application monitoring and tracing with Azure Diagnostics. Azure Diagnostics enables you to collect diagnostic data from an application running in Azure. You can use diagnostic data for debugging and troubleshooting, measuring performance, monitoring resource usage, traffic analysis and capacity planning, and auditing.
If you need to synchronize data between on-premise and SQL Database or between different SQL Database servers, set up and configure SQL Data Sync service. In addition, we recommend that you set up and configure data recovery plan in case of user errors or natural disasters.
Other ResourcesMigrating Data-Centric Applications to Azure