Azure SQL Database Migration CookbookSummary: Provides step-by-step recipes for migrating SQL Server databases to Microsoft Azure SQL Database using the preview of the latest SQL Database Update V12

Writer: Kathy Lu

Technical Reviewer: Bill Gibson, Umachandar Jayachandran

Published: January 2015

Applies to: Azure SQL Database V12

Copyright

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2015 Microsoft. All rights reserved.

ContentsIntroduction.................................................................................................................................................1

The recipes at a glance................................................................................................................................2

Migration tools............................................................................................................................................3

Getting Started............................................................................................................................................4

Choosing a database performance level/pricing tier for migration...........................................................11

Recipe 1. Migrating a compatible database using SSMS............................................................................11

Recipe 2. Migrating a near-compatible database using SQL Azure Migration Wizard...............................17

Recipe 3. Update database in place then deploy to Azure SQL Database.................................................24

Validating the Migration............................................................................................................................31

Appendix I. Comparison of the recipes......................................................................................................33

IntroductionMigrating to the preview of the latest SQL Database Update (V12)The preview of Azure SQL Database V12 introduces the next generation of the SQL Database service and brings near-complete engine compatibility with SQL Server 2014. As such, it dramatically simplifies the task of migrating most databases from SQL Server to Azure SQL Database. With this update, migration for many databases is a straightforward movement operation requiring few if any changes to the schema and little or no re-engineering of applications. And where databases need to be changed the scope of these changes is more confined. With a small number of exceptions, the preview of the latest SQL Database update brings full compatibility with the database-scoped features of SQL Server. By design, server-scoped features of SQL Server are not supported by SQL Database, so databases and applications that rely on these will continue to need some re-engineering before they can be migrated. You can learn more about the update here: http://azure.microsoft.com/documentation/articles/sql-database-preview-whats-new/.

While SQL Database V12 improves compatibility with SQL Server, migration still needs to be planned and executed carefully, particularly for larger more complex databases. The following MSDN articles give background and guidance for planning and executing a migration project, Migrating SQL Server Databases to Azure SQL Database and Migrating Databases to Azure SQL Database, and should be considered essential reading.

About this cookbookThis cookbook focuses on the mechanical task of migrating a SQL Server database to the latest Azure SQL Database Update V12. If migration requires changes to the schema then the possible impact of each change on applications that use the database must be considered carefully. This cookbook assumes the reader is familiar with the schema of the database being migrated and the applications that use it and thus is able to assess the impact on the applications of any schema changes that might be required to allow the database to be migrated successfully.

Different approaches or ‘recipes’ for migrating a SQL Server database to Azure are described, each using one or more tools. Some recipes are quick and easy, while others take longer to prepare and ‘cook’. Migrating a large complex database may take many hours in a slow oven!

Azure SQL Database V12, the Azure management portal and the Visual Studio tools described here are all in preview and subject to change, so make sure you have latest versions of the cookbook and tools before you start.

1

The recipes at a glanceThe recipes are summarized below and then described in detail in later sections.

Recipe 1: Migrate a compatible database using SSMSThe database is deployed from to Azure SQL Database using SSMS. The database can be deployed directly or exported to a BACPAC which is then imported to create a new Azure SQL database.

Use when the source database is fully compatible with Azure SQL Database.

Recipe 2. Migrate a near-compatible database using SQL Azure Migration wizardThe database is processed using the SQL Azure Migration Wizard to generate a migration script containing schema or schema plus data in BCP format.

Use when the database schema requires upgrade and the changes can be handled by the wizard.

Recipe 3. Update database schema off-line using VS and SAMW and deploy with SSMSThe source database is imported into a Visual Studio database project for processing offline. SQL Azure Migration Wizard is then run across all the scripts in the project to apply a series of transformations and corrections. The project is targeted at SQL Database V12 (preview) and built and any remaining errors are reported. These errors are then resolved manually using the SQL Server tooling in Visual Studio. Once the project builds successfully it is published back to a copy of the source database. This updated database is then deployed to Azure SQL Database using recipe 1. If schema-only migration is required, the schema can be publish directly from Visual Studio directly to Azure SQL

Use when the database schema requires more changes than can be handled by SAMW alone.

2

Database.

Deciding which recipe to useIf you anticipate that a database can be migrated without change you should use recipe 1 which is quick and easy. If you are uncertain, start by exporting a schema-only BACPAC from the database, as described in recipe 1. If the export succeeds with no errors then you can use recipe 1 to migrate the database with its data. If you encounter errors during the export use the SQL Azure Migration Wizard (SAMW) to process the database in schema-only mode as described in recipe 2. If SAMW reports no errors then recipe 2 can be used. If SAMW reports that the schema needs additional work then, unless it needs only simple fixes, it is best to use recipe 3 and correct the database schema offline in Visual Studio using a combination of SAMW and manually applied schema changes. A copy of the source database is then updated in situ and then migrated to Azure using recipe 1.

Migration toolsTools used include SQL Server Management Studio (SSMS), the SQL Server tooling in Visual Studio, and the SQL Azure Migration Wizard (SAMW), as well the preview of the new Azure management portal. Be sure to install the latest versions of the client tools as earlier versions are not compatible with the preview of the latest SQL Database Update. The role of each tool is summarized below together with a link for installing/accessing the latest version.

Preview Azure Management PortalThe preview Azure management portal (http://portal.azure.com) is required to create servers using the latest SQL Database Update or to migrate existing servers and databases. You can find out more about migrating existing servers here: http://azure.microsoft.com/en-us/documentation/articles/sql-database-preview-upgrade/.

SQL Server Management Studio (SSMS)SSMS can be used to deploy a compatible database directly to Azure SQL Database or to export a logical backup of the database as a BACPAC, which can then be imported, still using SSMS, to create a new Azure SQL Database. You cannot use the preview portal to import a BACPAC yet.

You must use the latest version of SSMS to work with the preview of Azure SQL Database Latest Update which is available in CU5 of SQL Server 2014 or by downloading the latest version of the tools from http://msdn.microsoft.com/en-us/evalcenter/dn434042.aspx .

SQL Azure Migration Wizard (SAMW)SAMW can be used to analyze the schema of an existing database for compatibility with Azure SQL Database, and in many cases can be used to generate and then deploy a T-SQL script containing schema and data. The wizard will report errors during the transformation if it encounters schema content that it cannot transform. If this occurs, the generated script will require further editing before it can be deployed successfully. SAMW will process the body of functions or stored procedures which is normally excluded from validation performed by the SQL Server tooling in Visual Studio (see below) so may find issues that might not otherwise be reported by validation in Visual Studio alone. Combining use of SAMW with the SQL Server tooling in Visual Studio can substantially reduce the amount of work required to migrate a complex schema.

3

Be sure to use the latest version of the SQL Azure Migration Wizard from CodePlex at http://sqlazuremw.codeplex.com/.

SQL Server tooling in Visual StudioThe SQL Server tooling in Visual Studio can be used to create and manage a database project comprising a set of T-SQL files for each object in the schema. The project can be imported from a database or from a script file. Once created, the project can be targeted at the latest preview of Azure SQL Database; building the project then validates schema compatibility. Clicking on an error opens the corresponding T-SQL file allowing it to be edited and the error corrected. Once all the errors are fixed the project can be published, either directly to SQL Database to create an empty database or back to (a copy of) the original SQL Server database to update its schema, which allows the database to be deployed with its data using SSMS as above.

You must install and use the preview of the SQL Server database tooling for Visual Studio with support for the preview of Azure SQL Database Latest Update V12. Make sure you have Visual Studio 2013 with Update 4 installed first. See this blog post for more details of this preview release and how to install it: http://blogs.msdn.com/b/ssdt/archive/2014/12/18/sql-server-database-tooling-preview-release-for-the-latest-azure-sql-database-update-v12-preview.aspx.

You can keep track of updates to this software on the team blog at http://blogs.msdn.com/b/ssdt/.

Getting Started Create a Microsoft Azure AccountIf you haven’t already got a Microsoft Azure account and subscription then create one at http://azure.microsoft.com. You will use this subscription to create the migrated database in Azure SQL Database.

Create the target server for the migrated databaseAll the recipes require a server created using the preview of the latest SQL Database Update (V12) as the target for the migration. Recipe 2 also requires an empty database on the server. Create the server using the portal, either by creating a database and V12 server together or by upgrading an existing server to the V12 preview. In both cases you must activate your subscription for the V12. Details of these two ways to create a V12 server how to activate your subscription in the preview, are given below.

4

How to create a V12 database and server together 1. Open the preview Azure management portal at https://portal.azure.com2. Click on + New on the bottom of the jump bar on the left of the portal.3. On the New blade, click the SQL Database bar that is displayed.

5

4. In the SQL database blade that opens if you have not yet activated your subscription for the V12 preview you will need to click on the information bar toward the top of the blade. This will open a blade labeled Try the latest update (preview). Check the box to indicate you understand the terms and conditions of the preview and click the OK button at the bottom of the blade to activate your subscription.

6

5. Once you have activated your subscription the information bar on the SQL Database blade will guide you to select a V12 source to use the preview of the latest SQL Database Update.

6. Provide a name for the database. Note that only in recipe 2 will you need to keep this database. If you are using recipe 2 or 3 you can delete the database once the server has been created.

7. Click on SELECT SOURCE and choose Blank Database [latest preview V12].

7

8. It’s not important at this stage which pricing tier you assign to the database – use Basic if you are only creating the database temporarily. You will configure the pricing tier of your target database as part of each recipe.

9. Click on SERVER to configure the server on which the database will be created. On the Server blade that opens select Create a new server to open the New server blade. On this blade note that the information bar confirms that, because you selected a V12 source, the server will be a V12 server and support the latest SQL Database Update.

8

How to upgrade a V12 server1. Open the preview Azure management portal at https://portal.azure.com2. Navigate to the Server blade for the server you wish to upgrade by clicking on Browse in the

jump bar, click on SQL servers, and then select the desired server from the list displayed.

9

3. On the Server blade that opens click the Latest update (preview) part to open its corresponding blade. If you have not yet activated your subscription for the V12 preview you will need to click on the information bar toward the top of the blade. This will open a blade labeled Try the latest update (preview). Check the box to indicate you understand and accept the terms and conditions of the preview and then click the OK button at the bottom of the blade to activate your subscription.

4. Once your subscription is activated for the V12 preview you will be able to select UPGRADE THIS SERVER, which will open the Upgrade this server bade. Note that in order to upgrade a server to the V12 preview it must have no Web or Business databases on it and there should be no geo-replication links to or from any database on it. If you have any incompatible databases these will be listed on the blade. If necessary upgrade any Web or Business databases and terminate any geo-replication links or, choose or create another server. Once any incompatible databases have been dealt with you will be able to upgrade the server.

10

5. Read the warning carefully as upgrade a server to the V12 preview is permanent and irreversible. To confirm the upgrade type the name of the server in the box provided and click OK. The upgrade can take up to 24 hours depending on the size of the databases on the server.

Set the firewall rules on the serverWhether you create a new server or upgrade an existing one you will need to define a firewall rule on the server that allows connection from your client machine’s IP address before you can use any of the client tools.

1. Open the Server blade as described above.2. Click on the Settings part to open the associated Settings blade3. Select Firewall to open the Firewall settings blade and then configure a rule with an IP range

that includes the IP address of the client machine. Click the Save command to save the rule.

11

Choosing a database performance level/pricing tier for migrationEach of the recipes creates and populates a database in the preview of the latest Azure SQL Database Update (V12). You can choose to create a Basic, Standard, or Premium database (Web and Business editions are not supported on a V12 server). The bulk loading of schema and data that occurs during migration is an intensive operation which needs the database to be scaled appropriately. For anything other than a very small database it is recommended to use at least the Standard S2 pricing tier. (Note that the tools may refer to pricing tier as a combination of Edition/Service Tier and Service Objective/ Performance Level).

Particularly for larger and/or more complex databases, using a higher pricing tier will reduce the time it takes for the database to be populated, while it will take longer and may be less reliable if you use a lower pricing tier. The pricing tier determines how much you are charged for the database you create. Consider using a higher pricing tier to achieve shorter deployment times and then reducing the pricing tier after deployment has completed. As you are charged by the hour, the shorter migration time mitigates the additional cost of using the higher pricing tier. The SQL Database latest Update V12 introduces a new Standard S3 pricing tier with 100 DTUs in preview. See the pricing details page for more information: http://azure.microsoft.com/en-us/pricing/details/sql-database/.

Recipe 1. Migrating a compatible database using SSMS

If a database schema is already compatible with the latest Azure SQL Database Update then migration will be straightforward. As no transformation is needed, migration only requires that the database is effectively copied to Azure. This can be done in a single step using SSMS by ‘deploying’ the database to Azure SQL Database, or as a two-step process by first exporting a BACPAC and then importing it to an Azure SQL Database server to create a new database.

Later in the preview you will be able to upload the exported BACPAC to Azure Storage and import it using the portal. Running the import in the cloud will reduce the latency in the import step which will improve performance and reliability of the migration with large databases.

12

Deploying directly from SSMS will always deploy the schema and data, while export and import always deploys the schema and provides an option to deploy data from all or a subset of the tables.

Whether you deploy from SSMS or export and then import from SSMS (or later the portal) the same DAC technology is used under the hood and the outcome is the same.

This recipe is also used as the final step in recipe 3 to migrate the databases after it has been updated to make it compatible with Azure SQL Database.

Using SSMS to Deploy to Azure SQL Database1. Provision a server in the latest SQL Database Update using the preview Azure management

portal as described in, Create the target server for the migrated database.2. Locate the source database in the SSMS Object Explorer and execute the task, Deploy Database

to Windows Azure SQL Database…

3. In the deployment wizard configure the connection to the target Azure SQL Database server provisioned in step.

13

4. Provide the name for the database and set the Edition (service tier) and Service Objective (performance level). See, Choosing a database performance level/pricing tier for migration, for more information on configuring these settings.

5. Complete the wizard to execute the migration of the database.

Depending on the size and complexity of the database deployment may take from a few minutes to many hours. If errors occur that indicate that the database schema is incompatible with the SQL Database then a different recipe must be used.

14

Use SSMS to export a BACPAC and then import it to SQL DatabaseThe deployment process can be broken into two steps: export and import. In the first step a BACPAC file is created which is then used as input in the second step.

1. Provision a server using the latest SQL Database Update as described in, Create the target serverfor the migrated database.

2. Locate the source database in the SSMS Object Explorer and select the task, Deploy Database to Windows Azure SQL Database…

15

3. In the export wizard configure the export to save the BACPAC file locally. The exported BACPAC always includes the complete database schema and by default data from all the tables. Use the Advanced tab if you wish to exclude data from some or all of the tables. You might, for example, choose to export only the data for reference tables.

Note: once the preview Azure management portal supports import running in Azure then you could choose to save the exported BACPAC file to Azure Storage and run the import in the cloud.

16

4. Once the BACPAC has been created, connect to the server you created in step1, right click on Databases folder and select Import Data Tier Application...

5. In the import wizard select the BACPAC file you have just exported to create the new database in Azure SQL Database.

6. Provide the name for the database and set the Edition (service tier) and Service Objective (performance level). See, Choosing a database performance level/pricing tier for migration for a discussion on configuring these settings.

17

7. Complete the wizard to import the BACPAC file and create the database in Azure SQL Database.

AlternativesYou can also use the command line utility sqlpackage.exe to deploy the database or export and import a BACPAC. Sqlpackage.exe uses the same DAC technology as SSMS so the outcome is the same. For more information see: http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx.

Recipe 2. Migrating a near-compatible database using SQL Azure Migration Wizard

Figure 1. Using the SQL Azure Migration Wizard to transform and deploy a database.

This recipe uses the SQL Azure Migration Wizard to generate a T-SQL script from a source database which is then transformed by the wizard to make it compatible with the latest SQL Database Update and

18

then connect to Azure SQL Database to execute the script against an empty Azure SQL database. The script can be generated with schema only or can include data in BCP format. The wizard also allows you to include or exclude specific objects from the database in the script.

Note that not all incompatible schema that can be detected by the wizard can be processed by its built-in transformations. Incompatible script that cannot be addressed will be reported as errors, with comments injected into the generated script. If this occurs the script must be saved and edited manually before it can be submitted to Azure SQL Database. If changes are needed the script can be saved and then edited with SSMS or the SQL Server tooling in VS, and once compatible, executed out-of-band against Azure SQL Database.

Note: As an extension to this recipe, if many errors are detected and correcting them is not straightforward you can import the generated script file into a database project in Visual Studio. If you set the target of the project to the latest SQL Database Update V12 you can then build the project and progressively correct the errors using the SQL Server tooling in VS. Once the schema has no errors you can publish the schema to a copy of the source database and then use SSMS to deploy or export/import the database to Azure SQL database as described in recipe 1.

Migration steps1. Provision a new database either on a new server in the latest SQL Database Update or on an

existing server upgraded to the latest update as described earlier. You will execute the migration script created in this recipe against this database as the final step. See, Choosing a database performance level/pricing tier for migration for guidance on the pricing tier to use for migration.

2. Open the migration wizard and select the option to Analyze/Migrate a Database and set the Target Server to Azure SQL Database Latest Preview V12 and then click Next.

19

3. On the next page click Connect to Server and provide the connection information for your source server. Either specify the source database in the connection dialog or connect to the server and then select the source database from the list of databases.

20

4. On the next page, Choose Objects, you can select whether to Script all database objects (the default) or Select specific database objects to be scripted. You may find it best to start by scripting all objects in a first pass and then potentially come back to this step and exclude objects if the wizard reports scripting or transformation errors. The wizard works by first scripting the objects in the database (using SMO) and then post-processes the generated script to apply a series of regex-based validation and transformation rules.

21

5. Select Advanced and review the configuration options used by the wizard. For a first pass, particularly for a large database you should set Script Table/Data to Table Schema Only, ensure Target Server is set to Microsoft Azure SQL Database Latest Preview V12, and Compatibility Checks is set to Override: Perform All Compatibility Checks.

6. Click Next to review the options and then Next again to generate and transform the script. You can review the script on the SQL Script tab.

22

7. Script generation will report errors if the schema is incompatible with the latest SQL Database Update and cannot be transformed by the wizard. In the screen shot below the transformation process has found problems with one stored procedure. In this case, a procedure has been written to use full text search which is not yet supported in the V12 preview (but will be supported in a later release).

a. Depending on your assessment of the errors you may choose to go back in the wizard and exclude objects that are causing problems and regenerate the script. As you consider how you plan to address the errors consider the impact on other objects in the database as well as the applications that use the database.

b. If the script has errors that need to be corrected you can save a schema-only script file from the SQL Script tab and open and edit the script in your favorite editor to correct the errors before executing it outside of SAMW against the new database you created in step 1. If the script is large or there are a large number of errors you should use recipe 3. Note that while you can import the generated script file into Visual Studio importing from a SQL file can take considerable longer than importing from a database as described in recipe 3.

23

8. If there are no errors or you have eliminated the source of errors resulting from the generation you can click Next and then on the following page click Connect to Server to connect to the Azure SQL Database server you created in step 1.

9. The next step is to select the database against which the script will be executed. All existing databases on the server will be listed. Select the database you created in step 1. The database should be empty and have an appropriate pricing tier for this operation.

a. If you prefer, you can create a database at this point using the wizard. To do so click Create Database to configure and create it. See the Getting Started section for guidance on choosing the performance level to use during the migration process.

b. Once you have created the database select and continue. 10. With an empty database selected click Next and confirm that you want to execute the script to

complete the migration.

24

Recipe 3. Update database in place then deploy to Azure SQL Database

Use this recipe when migrating a database to the preview of the latest Azure SQL Database Update V12 requires schema changes that cannot be addressed using the SQL Azure Migration Wizard (SAMW). This will occur if the database uses SQL Server features that are not or not yet supported in Azure SQL Database. In this recipe, Visual Studio is first used to create a database project from the source database. The project’s target platform is then set to Azure SQL Database V12 and the project is built to identify all compatibility issues. SAMW can fix many but not all compatibility issues, so is used to process all the scripts in the projects as a first pass. Using SAMW is optional but highly recommended. Building the project after processing the script files with SAMW will identify remaining issues which must then be addressed manually using the T-SQL editing tools in Visual Studio. Once the project builds successfully the schema is published back to a copy (recommended) of the source database to update its schema and data in-situ. The updated database is then deployed to Azure, either directly or by exporting and importing a BACPAC file, using the techniques described in recipe 1.

As this recipe involves updating the schema of the database in-situ before deploying to Azure it is strongly recommended to perform this update on a copy of the database. The Visual Studio Schema Compare tool can be used to review the full set of changes that will be applied to the database before publishing the project.

Use of the SQL Azure Migration Wizard (SAMW) is optional but recommended. SAMW will detect compatibility issues within the body of functions, stored procedures and triggers which will not otherwise be detected until deployment.

If a schema-only deployment is required the updated schema can be published directly from Visual Studio to Azure SQL Database.

25

Migration Steps1. Open the SQL Server Object Explorer in Visual Studio. Use Add SQL Server to connect to the SQL

Server instance containing the database being migrated. Locate the database in the explorer, right click on it and select Create New Project…

2. Configure the import settings to Import application-scoped objects only. Deselect the options to import referenced logins, permissions and database settings.

26

3. Click Start to import the database and create the project, which will contain a T-SQL script file for each object in the database. The script files are nested in folders within the project.

4. In the Visual Studio Solution Explorer, right click on the database project and select Properties. This will open the Project Settings page on which you should configure the Target Platform to Microsoft Azure SQL Database V12 (Preview).

27

5. Optional: right click on the project and select Build to build the project (this is not strictly required at this point, but doing this now will give you a baseline for the number of compatibility issues in the project and the effectiveness of the following steps.)

6. Optional: Right click on the project and select Snapshot Project. By taking a snapshot at the beginning and potentially at later stages during the transformation you can use the Schema Compare tool to compare the schema at each stage.

28

Snapshotting the project creates a time-stamped .dacpac file that contains the complete schema of the project. You can modify the file name to indicate at what stage in the process this snapshot was taken.

7. Process the imported script files using the SQL Azure Migration Wizard (SAMW). Use the folder option and select the root project folder.

29

8. The wizard will process each script file in this folder and all subfolders. A summary of the results will be displayed on the next page.

30

9. Click next to see a summary list of the files that have been changed.

Note that temporary copies are made of both the original files before processing and the impacted files after processing at the locations indicated at the top of the page.

10. Click Overwrite and OK in the confirmation dialog and the original files will overwritten with the changed files. Note that only files that have actually been changed will be overwritten.

31

11. Optional. Use Schema Compare to compare the project to an earlier snapshot or to the original database to understand what changes have been made by the wizard. You might want to take another snapshot at this point also.

12. Build the project again (see earlier step) to determine what errors remain.13. Work through the errors systematically to resolve each issue. Assess the impact of each change

on applications that use the database.14. When the database is free of errors right click on the project and select Publish to build and

publish the database to a copy of the source database (it is highly recommended to use a copy, at least initially). The goal of this step is to update the source database schema and make any consequent changes to data in the database.

a. Before you publish, depending on the source SQL Server version, you may need to reset the project’s target platform to enable deployment. If you are migrating an older SQL Server database you must not introduce any features into the project that are not supported in the source SQL Server unless you first migrate the database to a newer version of SQL Server.

b. You must configure the publish step to enable appropriate Publish options. For example, if you have deleted or commented out unsupported objects in the project then these must be deleted from the database so you must allow Publish to delete data in the target database.

c. If you anticipate publishing repeatedly 15. Deploy the copied database to Azure SQL Database using the techniques described in recipe 1.

Validating the MigrationOnce you have completed the migration it is a good idea to compare the schema in the migrated database with the schema in the source database to familiarize yourself with any changes that have been made to satisfy yourself they are as expected and will not cause any issues when migrating applications to the new database. You can use the Schema Compare tool included with the SQL Server tooling in Visual Studio to perform the comparison. You can compare the database in Azure SQL Database to the original SQL Server database or to a snapshot taken when the database was first imported into the project.

32

1. Connect to the server in the Azure SQL database containing the migrated database and locate the database.

2. Right click on the database and select Schema Compare… This will open a new schema comparison with the Azure database selected as the source on the left side. Use the Select Target drop down on the right side to select the target database or the snapshot file for the comparison.

3. With source and target selected click on Compare to trigger the comparison. Loading the schema from a complex database in Azure SQL Database may take a considerable time. Loading the schema and doing other metadata tasks on an Azure SQL database will take less time with a higher pricing tier.

4. Once the comparison is complete review the differences. Unless you have any concerns you should not as a rule apply changes to either schema.

In the schema comparison below the Adventure Works 2014 database in Azure SQL Database V12 (preview) on the left as transformed and migrated by the SQL Azure Migration Wizard, is compared with the source database in SQL Server on the right. The minor differences here are the result of the preview not yet supporting full text indexing.

33

Appendix I. Comparison of the recipesRecipe1 Recipe 2 Recipe 3

Deploy a compatible database to Azure SQL Database

Generate a migration script with changes and execute on Azure SQL

Database

Update database in-place then deploy to Azure SQL Database

Uses SSMS Uses SAMW Uses SAMW, VS, SSMSSimple process requires that schema is compatible. Schema is migrated unchanged.

T-SQL script is generated by SAMW includes changes required to ensure compatibility. Some unsupported features will be dropped from the schema, most are flagged as errors.

Schema is imported into a database project in Visual Studio and (optionally) transformed with SAMW. Additional updates are made using the SQL Server tooling in Visual Studio and final schema used to update the database in situ.

If exporting a BACPAC then can choose to migrate schema only.

Can configure the wizard to script schema or schema plus data.

Can publish schema only directly to Azure from Visual Studio. Database is updated with any required changes in-situ to allow schema and data to be deployed/exported.

Always deploys or exports the entire database.

Can choose to exclude specific objects from the migration.

Full control of the objects that are included in the migration.

No provision for changing the output if there are errors, the source schema must be compatible.

Single monolithic generated script can be awkward to edit if required. The script can be opened and edited in SSMS or Visual Studio with the SQL Server database tooling. All errors must be fixed before the script can be deployed to Azure SQL Database.

Full features of SQL Server tooling in Visual Studio available. Schema is changed offline.

Application validation occurs in Azure. Should be minimal as schema is migrated without change.

Application validation occurs in Azure after migration. Generated script could also be installed on-premises for initial application validation.

Application validation can be done in SQL Server before the database is deployed to Azure.

Microsoft supported tool. Community supported tool downloaded from CodePlex.

Microsoft supported tools with optional use of community supported tool downloaded from CodePlex.

Simple easily configured one- or two-step process.

Schema transformation and generation and deployment to the cloud are orchestrated from a single easy to use wizard.

More complex multi-step process (simpler if only deploying schema).

34