Overview of the Migration Life Cycle in Windows Azure

The goal of this phase is to understand the business needs that require the Windows Azure solution. After identifying the business goals, review the existing application architecture to identify the main differences between Windows 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 Windows 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 Windows Azure:
  
  
  • Is Windows 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 Windows 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 Windows Azure Virtual Machine.
    
    
  The answers to these questions impact the way that an application is designed to behave on the Windows Azure platform.
  
  
• Determine feature discrepancies: Can you run your existing application in Windows Azure with no changes? For example, Windows 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 does not support SQL CLR currently.
  
  Starting with the Windows Azure 2012 Preview release, the new Virtual Machine capabilities have been added to Windows Azure. With Windows Azure Virtual Machines, you can migrate your existing SQL Server applications built on Windows Server platform to Windows Azure Platform with minimal or no code changes. With SQL Server in Windows 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 a Windows 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 to perform and scale better on Windows Azure. If the application is too chatty or doing an excessive data inquiry, consider using Windows 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 SQL Database Federations instead of expensive scale-up systems in on-premises.
  
  
• Prepare a plan for application life cycle management: It is important to consider application versioning and upgrade scenarios on Windows 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 Windows Azure. We recommend that you carefully maintain the staging environment and the production environment on Windows 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 Windows Azure Platform services and tools.

Once you decide to migrate your application to Windows 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 Windows Azure deployment goals in terms of business and technical requirements. Then, compile and deploy the application code to the appropriate roles on Windows Azure.

In general, most existing on-premises applications can run in Windows 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 Windows Azure Cloud Services. For more information, see Development Considerations for Windows Azure Cloud Services. We recommend you first move your entire application to Windows 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 Windows Azure.

If you decide to use SQL Server in a Windows Azure Virtual Machine (VM), modify your existing SQL Server applications to connect to the SQL Server database in Windows 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 Windows Azure. In this case, your application, its configuration settings and its data already in this virtual machine. But this might require uploading a large .vhd file to Windows Azure. In addition, there might be some drivers and hardware dependencies on this existing virtual machine and they may not be available in Windows Azure.
  
  
• You can build a virtual machine in Windows 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 Windows Azure VM, see Migrating to SQL Server in a Windows Azure Virtual Machine topic.

If you use Windows Azure Cloud Services, move relational data from on-premise SQL Server to SQL Database and move unstructured data to Windows Azure storage like Blob, Table, or Windows Azure Drives. For more information, see Migrating Data to Tables, Blobs, and Drives in Windows Azure and Migrating SQL Server Databases to Windows Azure SQL Database.

If you decide to use SQL Server on Windows 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 Windows Azure.
  
  
• You can build a virtual machine in Windows Azure. Then, you can upload data in a .vhd file to Windows 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 a Windows Azure Virtual Machine topic to migrate your existing SQL Server databases to a SQL Server in a Windows Azure virtual machine.
  
  

After you migrate your application and data to Windows 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 Windows Azure. After that, resolve any feature, functionality, performance, or scalability issues in your cloud application. For more information, see Implementing the Migration Plan for Windows Azure.

After the testing and optimization phase, set up and implement application monitoring and tracing with Windows Azure Diagnostics. Windows Azure Diagnostics enables you to collect diagnostic data from an application running in Windows Azure. 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 Windows 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 Windows Azure SQL Database.

Other Resources