Eksportuj (0) Drukuj
Rozwiń wszystko
EN
Ta zawartość nie jest dostępna w wymaganym języku. Wersja w języku angielskim znajduje się tutaj.

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 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.

Windows Azure Migration Life Cycle

This topic explains each phase in detail with links to further information.

Microsoft Azure also supports Oracle on Microsoft 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

Analysis Phase

The goal of this phase is to understand the business needs that require the Microsoft Azure solution. After identifying the business goals, review the existing application architecture to identify the main differences between Microsoft 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 Microsoft 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 Microsoft Azure:

    • Is Microsoft 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 Microsoft 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 Microsoft Azure Virtual Machine.

    The answers to these questions impact the way that an application is designed to behave on the Microsoft Azure platform.

  • Determine feature discrepancies: Can you run your existing application in Microsoft Azure with no changes? For example, Microsoft 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 Microsoft Azure 2012 release, new Virtual Machine capabilities have been added to Microsoft Azure. With Microsoft AzureVirtual Machines, you can migrate your existing SQL Server applications built on the Windows Server platform to the Microsoft Azure Platform with minimal or no code changes. With SQL Server in Microsoft 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 Microsoft 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.

    Microsoft 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 Microsoft 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 Microsoft Azure. We recommend that you carefully maintain the staging environment and the production environment on Microsoft 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 Microsoft Azure Platform services and tools.

Application Migration Phase

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

In general, most existing on-premises applications can run in Microsoft 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 Microsoft Azure Cloud Services. For more information, see Development Considerations for Azure Cloud Services. We recommend you first move your entire application to Microsoft 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 Microsoft Azure Virtual Machine (VM), modify your existing SQL Server applications to connect to the SQL Server database in Microsoft 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 Microsoft 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 Microsoft Azure. In addition, there might be some drivers and hardware dependencies on this existing virtual machine and they may not be available in Microsoft Azure.

  • You can build a virtual machine in Microsoft 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 Microsoft Azure VM, see Migrating to SQL Server in an Azure Virtual Machine topic.

Data Migration Phase

If you use Microsoft Azure Cloud Services, move relational data from on-premise SQL Server to SQL Database and move unstructured data to Microsoft Azure storage like Blob, Table, or Microsoft Azure 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 Microsoft 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 Microsoft Azure.

  • You can build a virtual machine in Microsoft Azure. Then, you can upload data in a .vhd file to Microsoft 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 Microsoft Azure virtual machine.

Testing and Optimization Phase

After you migrate your application and data to Microsoft 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 Microsoft 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.

Operation and Management Phase

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

See Also

Zawartość społeczności

Pokaż:
© 2014 Microsoft