Azure SQL Database Migration

Cookbook
Summary: 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.

Contents
Introduction.................................................................................................................................................4
The recipes at a glance................................................................................................................................5
Migration tools............................................................................................................................................6
Getting Started ...........................................................................................................................................7
Choosing a database performance level/pricing tier for migration...........................................................15
Recipe 1. Migrating a compatible database using SSMS ...........................................................................16
Recipe 2. Migrating a near-compatible database using SQL Azure Migration Wizard...............................22
Recipe 3. Update database in place then deploy to Azure SQL Database..................................................30
Validating the Migration............................................................................................................................37
Appendix I. Comparison of the recipes......................................................................................................40
Introduction
Migrating 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 cookbook

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

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

Recipe 1: Migrate a compatible database using SSMS

The database is deployed from to Azure Use when the
SQL Database using SSMS. source database is
The database can be deployed directly fully compatible
or exported to a BACPAC which is then with Azure SQL
imported to create a new Azure SQL Database.
database.

Recipe 2. Migrate a near-compatible database using SQL Azure Migration wizard

The database is processed using the SQL Use when the
Azure Migration Wizard to generate a database schema
migration script containing schema or requires upgrade
schema plus data in BCP format. and the changes
can be handled by
the wizard.

Recipe 3. Update database schema off-line using VS and SAMW and deploy with SSMS
The source database is imported into a Use when the
Visual Studio database project for database schema
processing offline. SQL Azure Migration requires more
Wizard is then run across all the scripts changes than can
in the project to apply a series of be handled by
transformations and corrections. The SAMW alone.
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

5
 Visual Studio directly to Azure SQL
Database.
Deciding which recipe to use
If 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 tools
Tools 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 Portal

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

6
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 Studio

The 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 Account
If you havent 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 database

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

7
How to create a V12 database and server together
1. Open the preview Azure management portal at https://portal.azure.com

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

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

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

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

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

11
12
How to upgrade a V12 server
1. Open the preview Azure management portal at https://portal.azure.com

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

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

14
 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 server

Whether 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 machines 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 blade

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

Choosing a database performance level/pricing tier for

migration
Each 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

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

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.

16
Using SSMS to Deploy to Azure SQL Database
1. 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.

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.

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

18
Use SSMS to export a BACPAC and then import it to SQL Database
The 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 server
for the migrated database.

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

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

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

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

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

22
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
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 steps
1. 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.

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

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.

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

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

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

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

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

30
Migration Steps
1. 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.

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

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

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

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

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

36
 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 projects 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 Migration

Once 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

37
Database to the original SQL Server database or to a snapshot taken when the database was first
imported into the project.

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.

38
39
Appendix I. Comparison of the recipes
Recipe1
Deploy a compatible database to
Azure SQL Database
Uses SSMS
Simple process requires that
schema is compatible. Schema is
migrated unchanged.
If exporting a BACPAC then can
choose to migrate schema only.
Always deploys or exports the
entire database.
No provision for changing the
output if there are errors, the
source schema must be
compatible.
Application validation occurs in
Azure. Should be minimal as
schema is migrated without
change.
Microsoft supported tool.
Simple easily configured one- or
two-step process.
40
Recipe 2
Generate a migration script with
changes and execute on Azure SQL
Database
Uses SAMW
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.
Can configure the wizard to script
schema or schema plus data.
Can choose to exclude specific
objects from the migration.
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.
Application validation occurs in
Azure after migration. Generated
script could also be installed on-
premises for initial application
validation.
Community supported tool
downloaded from CodePlex.
Schema transformation and
generation and deployment to the
cloud are orchestrated from a
single easy to use wizard.
Recipe 3
Update database in-place then
deploy to Azure SQL Database
Uses SAMW, VS, SSMS
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.
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.
Full control of the objects that are
included in the migration.
Full features of SQL Server tooling
in Visual Studio available. Schema is
changed offline.
Application validation can be done
in SQL Server before the database
is deployed to Azure.
Microsoft supported tools with
optional use of community
supported tool downloaded from
CodePlex.
More complex multi-step process
(simpler if only deploying schema).
41