Overview of the Migration Life Cycle in Azure
Updated: April 16, 2014
The migration life cycle is a standard methodology that provides you the step-by-step instructions for migrating your applications and data to . 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.
also supports Oracle on 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 solution. After identifying the business goals, review the existing application architecture to identify the main differences between and on-premises solutions and determine if you need to re-design the existing on-premises application to meet the business needs of a 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 :
Is 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 ; 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 Virtual Machine.
- Is deployment solution targeting new customers and users?
Determine feature discrepancies: Can you run your existing application in with no changes? For example, 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 2012 release, new Virtual Machine capabilities have been added to . With Virtual Machines, you can migrate your existing SQL Server applications built on the Windows Server platform to the Platform with minimal or no code changes. With SQL Server in 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 . 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.
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 . 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 . We recommend that you carefully maintain the staging environment and the production environment on . 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 Platform services and tools.
Application Migration Phase
Once you decide to migrate your application to , 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 deployment goals in terms of business and technical requirements. Then, compile and deploy the application code to the appropriate roles on .
In general, most existing on-premises applications can run in 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 Cloud Services. For more information, see Development Considerations for Azure Cloud Services. We recommend you first move your entire application to 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 Virtual Machine (VM), modify your existing SQL Server applications to connect to the SQL Server database in 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 . 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 . In addition, there might be some drivers and hardware dependencies on this existing virtual machine and they may not be available in .
You can build a virtual machine in . 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 VM, see Migrating to SQL Server in an Azure Virtual Machine topic.
Data Migration Phase
If you use Cloud Services, move relational data from on-premise SQL Server to SQL Database and move unstructured data to storage like Blob, Table, or Drives. For more information, see Migrating Data to Tables and Blobs in Azure and Migrating SQL Server Databases to Azure SQL Database.
If you decide to use SQL Server on 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 .
You can build a virtual machine in . Then, you can upload data in a .vhd file to . 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 virtual machine.
Testing and Optimization Phase
After you migrate your application and data to , 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 . After that, resolve any feature, functionality, performance, or scalability issues in your cloud application. For more information, see Implementing the Migration Plan for Azure.
Operation and Management Phase
After the testing and optimization phase, set up and implement application monitoring and tracing with Diagnostics. Diagnostics enables you to collect diagnostic data from an application running in . You can use diagnostic data for debugging and troubleshooting, measuring performance, monitoring resource usage, traffic analysis and capacity planning, and auditing. For more information, see Diagnostics and Debugging in Azure in the MSDN library.
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. For more information, see High Availability and Disaster Recovery Considerations with Azure SQL Database.
Other ResourcesMigrating Data-Centric Applications to Azure