DP 050T00A ENU TrainerHandbook

Microsoft
Official
Course
DP-050T00
Migrate SQL workloads to
Azure
HIBITED
DP-050T00
Migrate SQL workloads to Azure
II Disclaimer
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with
any real company, organization, product, domain name, e-mail address, logo, person, place or event is
intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
The names of manufacturers, products, or URLs are provided for informational purposes only and
Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding
these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a
manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links
may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is
not responsible for the contents of any linked site or any link contained in a linked site, or any changes or
updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission
received from any linked site. Microsoft is providing these links to you only as a convenience, and the
inclusion of any link does not imply endorsement of Microsoft of the site or the products contained
therein.
© 2019 Microsoft Corporation. All rights reserved.

Microsoft and the trademarks listed at http://www.microsoft.com/trademarks are trademarks of the
Microsoft group of companies. All other trademarks are property of their respective owners.
MCT USE ONLY. STUDENT USE PROHIBITED
EULA III
MICROSOFT LICENSE TERMS

MICROSOFT INSTRUCTOR-LED COURSEWARE
These license terms are an agreement between Microsoft Corporation (or based on where you live, one of
its affiliates) and you. Please read them. They apply to your use of the content accompanying this agree-
ment which includes the media on which you received it, if any. These license terms also apply to Trainer
Content and any updates and supplements for the Licensed Content unless other terms accompany those
items. If so, those terms apply.
BY ACCESSING, DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS.
IF YOU DO NOT ACCEPT THEM, DO NOT ACCESS, DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below for each license you acquire.
1. DEFINITIONS.
a) “Authorized Learning Center” means a Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, or such other entity as Microsoft may designate from time to time.
b) “Authorized Training Session” means the instructor-led training class using Microsoft Instruc-
tor-Led Courseware conducted by a Trainer at or through an Authorized Learning Center.
c) “Classroom Device” means one (1) dedicated, secure computer that an Authorized Learning Center
owns or controls that is located at an Authorized Learning Center’s training facilities that meets or
exceeds the hardware level specified for the particular Microsoft Instructor-Led Courseware.
d) “End User” means an individual who is (i) duly enrolled in and attending an Authorized Training
Session or Private Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time
employee.
e) “Licensed Content” means the content accompanying this agreement which may include the
Microsoft Instructor-Led Courseware or Trainer Content.
f) “Microsoft Certified Trainer” or “MCT” means an individual who is (i) engaged to teach a training
session to End Users on behalf of an Authorized Learning Center or MPN Member, and (ii) current-
ly certified as a Microsoft Certified Trainer under the Microsoft Certification Program.
g) “Microsoft Instructor-Led Courseware” means the Microsoft-branded instructor-led training course
that educates IT professionals and developers on Microsoft technologies. A Microsoft Instruc-
tor-Led Courseware title may be branded as MOC, Microsoft Dynamics or Microsoft Business
Group courseware.
h) “Microsoft IT Academy Program Member” means an active member of the Microsoft IT Academy
Program.
i) “Microsoft Learning Competency Member” means an active member of the Microsoft Partner
Network program in good standing that currently holds the Learning Competency status.
j) “MOC” means the “Official Microsoft Learning Product” instructor-led courseware known as
Microsoft Official Course that educates IT professionals and developers on Microsoft technologies.
k) “MPN Member” means an active Microsoft Partner Network program member in good standing.
l) “Personal Device” means one (1) personal computer, device, workstation or other digital electronic
device that you personally own or control that meets or exceeds the hardware level specified for
the particular Microsoft Instructor-Led Courseware.
MCT USE ONLY. STUDENT USE PROHIBITED IV EULA
m) “Private Training Session” means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective using Microsoft Instructor-Led
Courseware. These classes are not advertised or promoted to the general public and class attend-
ance is restricted to individuals employed by or contracted by the corporate customer.
n) Trainer” means (i) an academically accredited educator engaged by a Microsoft IT Academy
Program Member to teach an Authorized Training Session, and/or (ii) a MCT.
o) “Trainer Content” means the trainer version of the Microsoft Instructor-Led Courseware and
additional supplemental content designated solely for Trainers’ use to teach a training session
using the Microsoft Instructor-Led Courseware. Trainer Content may include Microsoft PowerPoint
presentations, trainer preparation guide, train the trainer materials, Microsoft One Note packs,
classroom setup guide and Pre-release course feedback form. To clarify, Trainer Content does not
include any software, virtual hard disks or virtual machines.
2. USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is licensed on a one
copy per user basis, such that you must acquire a license for each individual that accesses or uses the
Licensed Content.
2.1. Below are five separate sets of use rights. Only one set of rights apply to you.
a) If you are a Microsoft IT Academy Program Member:
i) Each license acquired on behalf of yourself may only be used to review one (1) copy of the
Microsoft Instructor-Led Courseware in the form provided to you. If the Microsoft Instruc-
tor-Led Courseware is in digital format, you may install one (1) copy on up to three (3) Personal
Devices. You may not install the Microsoft Instructor-Led Courseware on a device you do not
own or control.
ii) For each license you acquire on behalf of an End User or Trainer, you may either:
1. distribute one (1) hard copy version of the Microsoft Instructor-Led Courseware to one (1)
End User who is enrolled in the Authorized Training Session, and only immediately prior to
the commencement of the Authorized Training Session that is the subject matter of the
Microsoft Instructor-Led Courseware being provided, or
2. provide one (1) End User with the unique redemption code and instructions on how they
can access one (1) digital version of the Microsoft Instructor-Led Courseware, or
3. provide one (1) Trainer with the unique redemption code and instructions on how they can
access one (1) Trainer Content,
provided you comply with the following:
iii) you will only provide access to the Licensed Content to those individuals who have acquired a
valid license to the Licensed Content,
iv) you will ensure each End User attending an Authorized Training Session has their own valid
licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized
Training Session,
v) you will ensure that each End User provided with the hard-copy version of the Microsoft
Instructor-Led Courseware will be presented with a copy of this agreement and each End User
will agree that their use of the Microsoft Instructor-Led Courseware will be subject to the terms
in this agreement prior to providing them with the Microsoft Instructor-Led Courseware. Each
individual will be required to denote their acceptance of this agreement in a manner that is
enforceable under local law prior to their accessing the Microsoft Instructor-Led Courseware,
vi) you will ensure that each Trainer teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
EULA V
vii) you will only use qualified Trainers who have in-depth knowledge of and experience with the
Microsoft technology that is the subject of the Microsoft Instructor-Led Courseware being
taught for all your Authorized Training Sessions,
viii) you will only deliver a maximum of 15 hours of training per week for each Authorized
Training Session that uses a MOC title, and
ix) you acknowledge that Trainers that are not MCTs will not have access to all of the trainer
resources for the Microsoft Instructor-Led Courseware.
b) If you are a Microsoft Learning Competency Member:
own or control.
ii) For each license you acquire on behalf of an End User or MCT, you may either:
End User attending the Authorized Training Session and only immediately prior to the
commencement of the Authorized Training Session that is the subject matter of the Micro-
soft Instructor-Led Courseware provided, or
2. provide one (1) End User attending the Authorized Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) MCT with the unique redemption code and instructions on how
they can access one (1) Trainer Content,
iv) you will ensure that each End User attending an Authorized Training Session has their own valid
licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized
Training Session,
v) you will ensure that each End User provided with a hard-copy version of the Microsoft Instruc-
tor-Led Courseware will be presented with a copy of this agreement and each End User will
agree that their use of the Microsoft Instructor-Led Courseware will be subject to the terms in
this agreement prior to providing them with the Microsoft Instructor-Led Courseware. Each
vi) you will ensure that each MCT teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
vii) you will only use qualified MCTs who also hold the applicable Microsoft Certification credential
that is the subject of the MOC title being taught for all your Authorized Training Sessions using
MOC,
viii) you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
ix) you will only provide access to the Trainer Content to MCTs.
MCT USE ONLY. STUDENT USE PROHIBITED VI EULA
c) If you are a MPN Member:

own or control.
ii) For each license you acquire on behalf of an End User or Trainer, you may either:
End User attending the Private Training Session, and only immediately prior to the com-
mencement of the Private Training Session that is the subject matter of the Microsoft
Instructor-Led Courseware being provided, or
2. provide one (1) End User who is attending the Private Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) Trainer who is teaching the Private Training Session with the unique
redemption code and instructions on how they can access one (1) Trainer Content,
iv) you will ensure that each End User attending an Private Training Session has their own valid
licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the Private
Training Session,
v) you will ensure that each End User provided with a hard copy version of the Microsoft Instruc-
tor-Led Courseware will be presented with a copy of this agreement and each End User will
agree that their use of the Microsoft Instructor-Led Courseware will be subject to the terms in
this agreement prior to providing them with the Microsoft Instructor-Led Courseware. Each
vi) you will ensure that each Trainer teaching an Private Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Private Training Session,
vii) you will only use qualified Trainers who hold the applicable Microsoft Certification credential
that is the subject of the Microsoft Instructor-Led Courseware being taught for all your Private
Training Sessions,
viii) you will only use qualified MCTs who hold the applicable Microsoft Certification credential
that is the subject of the MOC title being taught for all your Private Training Sessions using
MOC,
ix) you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
x) you will only provide access to the Trainer Content to Trainers.
d) If you are an End User:
For each license you acquire, you may use the Microsoft Instructor-Led Courseware solely for your
personal training use. If the Microsoft Instructor-Led Courseware is in digital format, you may
access the Microsoft Instructor-Led Courseware online using the unique redemption code provid-
ed to you by the training provider and install and use one (1) copy of the Microsoft Instructor-Led
Courseware on up to three (3) Personal Devices. You may also print one (1) copy of the Microsoft
EULA VII
Instructor-Led Courseware. You may not install the Microsoft Instructor-Led Courseware on a
device you do not own or control.
e) If you are a Trainer.
i) For each license you acquire, you may install and use one (1) copy of the Trainer Content in the
form provided to you on one (1) Personal Device solely to prepare and deliver an Authorized
Training Session or Private Training Session, and install one (1) additional copy on another
Personal Device as a backup copy, which may be used only to reinstall the Trainer Content. You
may not install or use a copy of the Trainer Content on a device you do not own or control. You
may also print one (1) copy of the Trainer Content solely to prepare for and deliver an Author-
ized Training Session or Private Training Session.
ii) You may customize the written portions of the Trainer Content that are logically associated with
instruction of a training session in accordance with the most recent version of the MCT agree-
ment. If you elect to exercise the foregoing rights, you agree to comply with the following: (i)
customizations may only be used for teaching Authorized Training Sessions and Private
Training Sessions, and (ii) all customizations will comply with this agreement. For clarity, any
use of “customize” refers only to changing the order of slides and content, and/or not using all
the slides or content, it does not mean changing or modifying any slide or content.
2.2. Separation of Components. The Licensed Content is licensed as a single unit and you may not
separate their components and install them on different devices.
2.3. Redistribution of Licensed Content. Except as expressly provided in the use rights above, you may
not distribute any Licensed Content or any portion thereof (including any permitted modifications)
to any third parties without the express written permission of Microsoft.
2.4. Third Party Notices. The Licensed Content may include third party code that Microsoft, not the
third party, licenses to you under this agreement. Notices, if any, for the third party code are includ-
ed for your information only.
2.5. Additional Terms. Some Licensed Content may contain components with additional terms, condi-
tions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also
apply to your use of that respective component and supplements the terms described in this
agreement.
3. LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Content’s subject
matter is based on a pre-release version of Microsoft technology (“Pre-release”), then in addition to
the other provisions in this agreement, these terms also apply:
a) Pre-Release Licensed Content. This Licensed Content subject matter is on the Pre-release version
of the Microsoft technology. The technology may not work the way a final version of the technol-
ogy will and we may change the technology for the final version. We also may not release a final
version. Licensed Content based on the final version of the technology may not contain the same
information as the Licensed Content based on the Pre-release version. Microsoft is under no
obligation to provide you with any further content, including any Licensed Content based on the
final version of the technology.
b) Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly
or through its third party designee, you give to Microsoft without charge, the right to use, share
and commercialize your feedback in any way and for any purpose. You also give to third parties,
without charge, any patent rights needed for their products, technologies and services to use or
interface with any specific parts of a Microsoft technology, Microsoft product, or service that
includes the feedback. You will not give feedback that is subject to a license that requires Micro-
soft to license its technology, technologies, or products to third parties because we include your
feedback in them. These rights survive this agreement.
MCT USE ONLY. STUDENT USE PROHIBITED VIII EULA
c) Pre-release Term. If you are an Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, MPN Member or Trainer, you will cease using all copies of the Licensed
Content on the Pre-release technology upon (i) the date which Microsoft informs you is the end
date for using the Licensed Content on the Pre-release technology, or (ii) sixty (60) days after the
commercial release of the technology that is the subject of the Licensed Content, whichever is
earliest (“Pre-release term”). Upon expiration or termination of the Pre-release term, you will
irretrievably delete and destroy all copies of the Licensed Content in your possession or under
your control.
4. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some
rights to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you
more rights despite this limitation, you may use the Licensed Content only as expressly permitted in
this agreement. In doing so, you must comply with any technical limitations in the Licensed Content
that only allows you to use it in certain ways. Except as expressly permitted in this agreement, you
may not:
● access or allow any individual to access the Licensed Content if they have not acquired a valid
license for the Licensed Content,
● alter, remove or obscure any copyright or other protective notices (including watermarks), brand-
ing or identifications contained in the Licensed Content,
● modify or create a derivative work of any Licensed Content,
● publicly display, or make the Licensed Content available for others to access or use,
● copy, print, install, sell, publish, transmit, lend, adapt, reuse, link to or post, make available or
distribute the Licensed Content to any third party,
● work around any technical limitations in the Licensed Content, or
● reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation.
5. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to
you in this agreement. The Licensed Content is protected by copyright and other intellectual property
laws and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property
rights in the Licensed Content.
6. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regula-
tions. You must comply with all domestic and international export laws and regulations that apply to
the Licensed Content. These laws include restrictions on destinations, end users and end use. For
additional information, see www.microsoft.com/exporting.
7. SUPPORT SERVICES. Because the Licensed Content is “as is”, we may not provide support services for
it.
8. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you
fail to comply with the terms and conditions of this agreement. Upon termination of this agreement
for any reason, you will immediately stop all use of and delete and destroy all copies of the Licensed
Content in your possession or under your control.
9. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed
Content. The third party sites are not under the control of Microsoft, and Microsoft is not responsible
for the contents of any third party sites, any links contained in third party sites, or any changes or
updates to third party sites. Microsoft is not responsible for webcasting or any other form of transmis-
sion received from any third party sites. Microsoft is providing these links to third party sites to you
EULA IX
only as a convenience, and the inclusion of any link does not imply an endorsement by Microsoft of
the third party site.
10. ENTIRE AGREEMENT. This agreement, and any additional terms for the Trainer Content, updates and
supplements are the entire agreement for the Licensed Content, updates and supplements.
11. APPLICABLE LAW.
a) United States. If you acquired the Licensed Content in the United States, Washington state law
governs the interpretation of this agreement and applies to claims for breach of it, regardless of
conflict of laws principles. The laws of the state where you live govern all other claims, including
claims under state consumer protection laws, unfair competition laws, and in tort.
b) Outside the United States. If you acquired the Licensed Content in any other country, the laws of
that country apply.
12. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the
laws of your country. You may also have rights with respect to the party from whom you acquired the
Licensed Content. This agreement does not change your rights under the laws of your country if the
laws of your country do not permit it to do so.
13. DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS" AND "AS AVAILA-
BLE." YOU BEAR THE RISK OF USING IT. MICROSOFT AND ITS RESPECTIVE AFFILIATES GIVES NO
EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS. YOU MAY HAVE ADDITIONAL CON-
SUMER RIGHTS UNDER YOUR LOCAL LAWS WHICH THIS AGREEMENT CANNOT CHANGE. TO
THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, MICROSOFT AND ITS RESPECTIVE AFFILI-
ATES EXCLUDES ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICU-
LAR PURPOSE AND NON-INFRINGEMENT.
14. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT, ITS RESPECTIVE AFFILIATES AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO
US$5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST
PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES.
This limitation applies to
● anything related to the Licensed Content, services, content (including code) on third party Internet
sites or third-party programs; and
● claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence,
or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The
above limitation or exclusion may not apply to you because your country may not allow the exclusion
or limitation of incidental, consequential or other damages.
Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this
agreement are provided below in French.
Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses
dans ce contrat sont fournies ci-dessous en français.
EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute
utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre
garantie expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection
dues consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les
garanties implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contre-
façon sont exclues.
MCT USE ONLY. STUDENT USE PROHIBITED X EULA
LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES.

Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs
uniquement à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les autres
dommages, y compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.
Cette limitation concerne:
● tout ce qui est relié au le contenu sous licence, aux services ou au contenu (y compris le code)
figurant sur des sites Internet tiers ou dans des programmes tiers; et.
● les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité stricte, de
négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.
Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel
dommage. Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages
indirects, accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus
ne s’appliquera pas à votre égard.
EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits
prévus par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois
de votre pays si celles-ci ne le permettent pas.
Revised November 2014
Contents
■ Module 0 Welcome ................................................................ 1

Welcome to the course ............................................................... 1
■ Module 1 Introducing Data Platform Modernization ................................... 5
Module introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Understand data platform modernization ................................................ 6
Understanding the stages of migration .................................................. 12
Data migration technologies ........................................................... 23
Module summary .................................................................... 27
■ Module 2 Choosing the right tools for Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Discover the Database Migration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Build your data estate inventory using MAP Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37
Identify Migration candidates using Data Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Evaluate Data workload using Database Experimentation Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Migrate non SQL Server workloads using SQL Server Migration Assistant . . . . . . . . . . . . . . . . . . . . . . 66
Data migration using Azure Database Migration Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Module summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
■ Module 3 Migrate SQL Workloads to Azure Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Considerations of migrating to SQL Server in Azure Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . 86
SQL workloads to Azure VM migration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Application configuration and optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Module summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
■ Module 4 Migrate SQL Workloads to SQL Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Considerations of migrating to Azure SQL Database . .. . .. . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . 114
Migrating to Azure SQL Database ...................................................... 131
Service continuity of Azure SQL Database ................................................ 137
Module summary .................................................................... 144
■ Module 5 Migrate SQL Workloads to Managed Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Module introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............................ 147
Considerations of migrating to Azure SQL Database managed instance . . . . . . . . . . . . . . . . . . . . . . . 148
Migrating to Azure SQL Database managed instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Synchronizing data to Azure SQL Database managed instance .............................. 192
Module summary .................................................................... 202
Module 0 Welcome
Welcome to the course

Implementing an Azure Data Solution
This course has been created by ..…
Learning objectives
In this module you will gain information:
● About this course
● About the audience
● Course pre-requisites
● Course agenda
● Certification details
About this course

In this course, the students will explore the objectives of data platform modernization and how it is
suitable for given business requirements. They will also explore each stage of the data platform moderni-
zation process and define what tasks are involved at each stage. This involve exploring the assessment,
planning and migration tools that are available. This involves learning the capabilities of these tools and
how they are suitable for each stage of the data migration process.
The student will learn the three target platforms for SQL based workloads; Azure Virtual Machines, Azure
SQL Databases and Azure SQL Database Managed Instances. The student will learn the benefits and
limitations of each target platform and how they can be used to fulfil both business and technical
requirements for modern SQL workloads. The student will explore the changes that may need to be made
to existing SQL based applications, so that they can make best use of modern data platforms in Azure.
MCT USE ONLY. STUDENT USE PROHIBITED 2 Module 0 Welcome
Course Audience
Primary audience
The audience for this course is data professionals and data architects who want to learn about migrating
data platform technologies that exist on Microsoft Azure and how existing SQL based workloads can be
migrated and modernized.
Secondary audience
The secondary audience for this course is individuals who manage data platforms or develop applications
that deliver content from the existing data platform technologies.
Course Prerequisites
In addition to their professional experience with SQL Server, students who take this training should have
technical knowledge equivalent to the following courses:
• Azure fundamentals1
Course Agenda
At the end of this course, the student will learn:
Module 1: Introducing Data Platform Modernization

In this module, the students will learn the purpose of Data Platform Modernization and they will outline
the benefits that data platform modernization can bring to an organization. The students will then learn
the various stages of a data platform migration projects to understand what is involve in each stage to
maximise the chances of a successful Data Platform Modernization Projects. Finally, students will explore
the various data migration paths to understand how each approach is different and why you would
choose one migration approach over another.
Module 2: Choose the right tools for Data Migration

In this module, the student will be introduced to the Data Migration Guide as a starting point for the
source of information that your organization should use for step by step guidance for modernizing your
existing data platform. They will then learn the value of the Microsoft Assessment and Planning Toolkit to
help discover the data assets that currently exist in their environments.
The students will then learn the tools that can be used to help them to assess for compatibility or
workload issues using both the Data Migration and Data Experimentation Assistant. The students will
then see how the Azure Database Migration Service can be used to aid online migration of databases to
reduce the amount of downtime. Finally, an overview of the SQL Migration assistant is provided to show
student how to migrate no-SQL Server workloads.
1 https://docs.microsoft.com/en-us/learn/paths/azure-fundamentals/
Welcome to the course 3
Module 3: Migrate SQL Workloads to Azure Virtual Ma-

chines
In this module, the student will learn how to migrate on-premises SQL workloads to Azure Virtual
Machines that are running SQL Server. Students will first explore the migration consideration when
migrating from on-premises SQL Server to Azure Virtual Machines and the benefits they can gain by
performing the migration.
They will then learn the different migration options that can be performed when migrating to Azure
Virtual Machines. This will include a look at the benefits and limitations of each approach. The students
will finally look at SQL Server workloads that include High Availability and Disaster Recovery to ensure
service continuity.
Module 4: Migrate SQL Workloads to Azure SQL Databases

In this module, the students will explore what is Azure SQL Database and why it is a suitable target for
SQL based workloads. It teaches students how to choose the appropriate SQL Server instance option and
why it can fulfil business requirements for data platform modernization.
The modules will also show students how they can perform both offline and online migrations to Azure
SQL Database. By doing so, they can assess which method maybe appropriate to their scenarios at work.
It will also show the tools that can be used to enable the data migration process. Finally, they will explore
the methods that can be used to load data into Azure SQL Database from an on-premises instance
Module 5: Migrate SQL Workloads to Azure Managed In-

stances
This module will explore what is an Azure SQL Database Managed Instance and why it is a suitable target
for SQL based workloads. They also learn how Azure SQL Database Managed Instance can fulfil the
business requirements for data platform modernization. The students will then explore the tools that can
be used to enable the data migration process to Azure SQL Database Managed Instance.
They will then explore the methods and tools that can be used to load data into Azure SQL Database
Managed Instance from an on-premises instance. Finally, they will learn some of the changes that may
need to be made to existing SQL based applications so that they can use Azure SQL Database Managed
Instance.
Microsoft Certification
This course is not associated to any specific exam certification
Module 1 Introducing Data Platform Moderni-
zation
Module introduction
Module Introduction
In this module, the students will learn the purpose of Data Platform Modernization and they will outline
the benefits that data platform modernization can bring to an organization. The students will then learn
the various stages of a data platform migration projects to understand what is involve in each stage to
maximise the chances of a successful Data Platform Modernization Project. Finally, students will explore
the various data platform technologies to understand how each approach is different and why you would
choose one migration approach over another.
Learning objectives
In this module, you will be able to:
● Understand Data Platform Modernization
● Understand the Stages of Migration
● Data Platform Technologies
MCT USE ONLY. STUDENT USE PROHIBITED 6 Module 1 Introducing Data Platform Modernization
Understand data platform modernization

Lesson 1: Data Platform Modernization
In this lesson, you are introduced to Data Platform Modernization and the benefits that it can bring to
organizations that perform it. You will also learn the various stages of data platform modernization and
the strategies that can be adopted by an organization to deliver it.
Learning objectives
In this module, you will learn:
● What is Data Platform Modernization
● Why perform Data Platform Modernization
● The 7 R considerations to migration
What is Data Platform Modernization

With the growth of cloud computing, and as IT hardware comes to end of life within a business, many
organizations take stock and look at how the cloud can help bring new efficiencies, transform their
working practices, and in some cases disrupt entire industries with new business models.
At the heart of this transformation is data; it drives business success. To that end, Database Administra-
tors and/or Data Engineers within IT departments must modernize existing Data Platform technologies to
help businesses realize their transformation goals whilst minimizing downtime and data loss.
Data Platform Modernization is primarily focused on selecting and migrating to the right data platform
technology that will help the business achieve its strategic objectives and goals. In some cases, this may
involve an organization simply upgrading an existing on-premises SQL Server to a newer version. More
and more, organizations are choosing to take advantage of the elastic nature and economies of scale that
the cloud brings, as well as the technological benefits through a wider range of technologies that is
available within Azure.
Data Platform Modernization is also more than that, it's also about designing and implementing a
process that ensures that the Data Platform Modernization takes place almost seamlessly. The process of
Data Platform Modernization consists of five stages:
● Initiate and Discovery-At this stage, you perform an audit of your existing environment to under-
stand the data estate that exists within the business. You also gain insight on and document the type
of workloads that your applications and databases deal with such as how big the workloads are, the
frequency that the workloads run and what they are used for.
● Assessment-At this stage, you use the information gained in the discovery phase to perform a
thorough assessment of the workloads you identified and assess any potential problems or breaking
Understand data platform modernization 7
changes that could exist pre or post migration, as well as the mitigation approach that will be used to
deal with them. You will also assess what Azure features can be used as soon as possible to maximize
the benefits of the data platform modernization project.
● Planning-The planning phase outlines the workloads and the associated databases and applications
that will be migrated. It will also specify the order in which they are migrated and what tools will be
used to perform the migration
● Transformation and Optimization-In this phase, any workload that requires any changes to become
compatible with the new data platform technology are dealt with by using transformations. Workloads
are then optimized to make use of the new features of the new data platform
● Testing and Remediation-At this stage, the migration is performed, with testing performed to
validate that the migration has been successful, and remediate any issues that arise
Why Perform Data Platform Modernization

Microsoft Azure provides a number of fully managed SQL based data platform technologies and services
that are cloud-based, secure, and scalable. Their features address the key challenges of cloud storage and
provide you with reliable and durable data platform solutions. But there are some other reasons why
Azure SQL based data platform technologies are beneficial:
● Convenience-Setting up SQL based data platform technologies is convenient. You don't have to
manage the physical hardware. You'll need to understand the latest security best practices and may
need to manage the operating system and SQL Server patches on a routine basis in some situations.
In other situations we manage all the hardware, software updates, and OS patches for you. All you
specify is the name of your database and a few options. You'll have a running SQL database in
minutes. You can also bring up and tear down Azure SQL Database instances at your convenience.
Azure SQL Database comes up fast and is easy to configure. You can focus less on configuring
software and more on making your applications great.
● Cost-Because Microsoft manages hardware for you, there is no system hardware for you to buy,
provide power for, or otherwise maintain. The Azure SQL based data platform has several pricing
options. These pricing options enable you to balance performance versus cost so you can start for just
a few dollars a month. In fact, the Total Cost of Ownership can be calculated using the online calcula-
tor Azure Total Cost of Ownership Calculator to help you establish the costs of the service you wish to
use.
● Scale-With Azure based data platform technologies, you can adjust the performance and size on the
fly when your needs change. This is difficult when running on-premises SQL Server where you have to
predict the size and scale in advance of reaching them.
● Security-Azure SQL based data platform technologies comes with the range of security features that
you have come to expect from Microsoft. But there is also a shared responsibility with you and
Microsoft to ensure that security is as strong as it can be. For example, you don't have to worry about
the physical security of the hardware, Microsoft deals with this as part of its data center security. You
would be concerned with an individuals access to the data through permissions.
● Automated backup and recovery-This mitigates the risk of losing your data if there is any unfore-
seen failure or interruption.
● Encryption capabilities-Data is automatically encrypted on disk to make it highly secure; you also
have encrypting connections to the data.
The 7 R Considerations to Migration

Within the planning phase of the Data Platform Modernization process, there are seven terms to describe
how you can handle application and data transitioning from an existing on-premises environment to a
new cloud based environment (either public or private).
These terms can be used to help formulate the strategy that an organization would want to take when
undertaking a Data Platform Modernization project. As the table below shows the strategy can range
from doing nothing at all to a complete replacement of a Data Platform solution and application.
# Phase Description Benefit

1. Remain Do nothing With this option
modernization of the
rest of the platform
continues whilst long
term options for the
services that are
remaining on-premises
are considered.
2. Rehost Optimize the data This approach removes
center and migrate to the need for datacenter
IaaS management and gives
a Higher Return On
Investment (ROI)
through a lower Total
Cost of Ownership
(TCO) due to consump-
tion of IaaS compute.

3. Refactor Migration to IaaS or This approach removes
PaaS with minimal the need for datacenter
application changes management and gives
a Higher Return On
Investment (ROI)
through a lower Total
Cost of Ownership
(TCO) due to consump-
tion of IaaS compute. It
also enables a lower
management overhead
through consolidation
of databases
4. Rearchitect redevelopment of the It allows the system to
application to make use make use of the latest
of cloud technologies components and reduce
the amount of code
required to deploy an
application. It also
provides the opportuni-
ty to allow the use of
DevOps deployment of
infrastructure and
Services.
5. Rebuild rebuilding the applica- Rebuilding data plat-
tion to use PaaS or forms and applications
serverless technologies using newer technolo-
gies allows the use of
the built-in Azure High
availability and Increas-
es the portability and
scalability of the
application. It also
reduces the likelihood
of a skills gap between
the technologies used
and the staff support-
ing/ developing the
application.
6. Replace Change the application The replace approach
in favour of a newer should be considered
application or SaaS when an application
solution requires physical
devices attached to the
server or it integrates
tightly with on-premises
infrastructure.

7. Retire Decommission applica- The retire approach
tions that are no longer should be considered
required when legacy applica-
tions and databases are
no longer used because
there is no business or
legal requirement to
keep them.
The graph below shows the amount of effort that each term requires compared to the value that the
business gains from the migration.
Lesson Summary
In this lesson, you learned about the purpose and benefits of data platform modernization. You have also
learned how to classify data platform and applications in terms of their migration methods using the
terms
● Remain
● Rehost
● Refactor
● Rearchitect
● Rebuild
● Replace
● Retire
Important
Should you be working in your own subscription while running through this content, it is best practice at
the end of a project to identify whether or not you still need the resources you created. Resources left
running can cost you money. You can delete resources one by one, or just delete the resource group to
get rid of the entire set.
Knowledge Check
Question 1
Adatum Corporation acquired a factory from Northwind Traders that was surplus to their requirements.
The Northwind building has a key card access system which has a dedicated server. The server connects to
the Key card system through a physical card installed in the server.
How should this server be categorized for migration? (Choose all that apply)
 Remain
 Rehost
 Refactor
 Rearchitect
 Rebuild
 Replace
 Retire
Question 2
The Northwind building has a facilities management system that monitors the temperature throughout the
building.
The temperature sensors communicate via a VPN with a central server which stores the data in a database
on a shared server for later analysis.
The building where the database server is being held is due to be demolished.
How should the database server be categorized for migration? (Choose all that apply)
 Remain
 Rehost
 Refactor
 Rearchitect
 Rebuild
 Replace
 Retire
Understanding the stages of migration

Lesson 2: Understanding the stages of migration
This lesson explores the stages of the migration process and what activities occur at each stage. Under-
taking the activities outlined at each stage will increase the chances that the migrations you perform are
successful.
Learning objectives
In this lesson, you will learn:
● The initiate and discovery stage
● The assessment stage
● The planning stage
● The transform and optimize stage
● The validate and remediation stage
Initiate and Discovery Stage

Initiation of Data Platform Modernization projects are typically driven by a wider business or legal
requirement. For example, ensuring that an organization uses a technology that is GDPR compliant, or
has a feature that brings about an improved business benefit. Therefore, it is important that projects do
account for these types of need to obtain project support from senior management in the business.
Assuming that this is the case, then the first step of the project is to perform a discovery exercise that
consists of the following considerations:
Taking stock of the current environment

Many IT infrastructures will typically evolve over many years, perhaps even decades. In that time, business
and staff can change immensely to the extent that there may no longer be experts in the systems that an
organization has. Indeed on rare occasions, organizations may even forget that they still have some
systems in existence.
To that end the first step that you should take in a Data Platform Modernization project is to that take an
inventory of your data estate and the applications that run within the organization. This could include:
● A list of servers both physical and virtual that are running
● The operating systems that are running and any service packs and updates
● The hardware capabilities of physical servers including memory and disk capacities
● The physical location and IP addresses of the servers identified
● The services and applications that are running on the server
Check for dependencies between existing Applications

and Databases
You should take time to understand how your applications interact with the databases that exist in your
network. Furthermore, you should also understand any inter database dependencies that may exist so
Understanding the stages of migration 13
that you can collectively group databases together in logical groupings. By performing this exercise, you
will use the logical groupings of databases as a basis for migrating them to Azure as one unit.
List the workload types of your systems

Listing the workload types against the database servers that you have identified will help you understand
how the server is used. Traditionally workloads can be either identified as analytical (AKA OLAP) or
transactional (AKA OLTP). Such categorization denotes if the servers perform read or write intensive
operations, and to that end can help you formulate a decision as to which data platform technology to
migrate to. You may also want to go further and categorize servers into those that perform Batch work-
loads or those that perform Decision Support workloads.
Assessment Stage
The assessment stage takes the information that has been gained from the discovery phase and your
team performs a thorough assessment of the workloads you have identified to establish the following:
● Any potential migration blockers
● Any breaking changes that require post migration fixes
● Azure features that the workloads can utilize
You establish this by performing a Current Workload Assessment and a Workload Criteria Assessment
Current Workload Assessment

With the list of categorized database servers and applications that have been identified in the discovery
phase, your assessment should confirm what databases exist on each server, establish the data volumes
and expected growth rates of each database, and document the average resource usage of each data-
base. In addition, you should understand the criticality of the applications and databases to the business.
For example, is it a database that cannot afford any downtime, or is important in facilitating revenue for
the business. At this stage, there is also an opportunity to consider if you should consolidate or decom-
mission any on-premises databases before performing a cloud migration. This can reduce the number of
databases to migrate, as well as reduce the total cost of ownership.
Once you have a deep understanding of your on-premises databases, you should classify the databases
and applications by effort and impact to migrate. From an effort perspective, you should have a list of
migration blockers, breaking changes and Azure features per database to be migrated. From this, you
may be able to identify those databases that have the easiest path to migrate, and use this as the first
wave of migration to practise and establish your migration routine, leaving more complex migrations in
later waves. You will also want to consider which database will have the biggest impact to the business in
terms of gaining the benefits of a migration. In summary, migrating low effort, high business impact
databases and applications would be candidates for the first systems to migrate.
Workload Criteria Assessment

In the Workload Criteria Assessment, you use the findings from the Current Workload Assessment and
define the post migration criteria for running the identified workloads in the following areas:
● Performance-At a minimum, you must ensure that the migrated databases and applications perform
to the same performance level as experienced on-premises. Therefore, if your decision is to migrate
databases to a Virtual Machine that has SQL Server installed, then you may provision a Virtual Ma-
chine that has the same memory and CPU as the on-premises server. For PaaS services, this will
require an investigation into the required performance unit of the selected platform. For SQL Data-
base, this will be Database Transaction Unit (DTUs), for Azure SQL Data Warehouse this is Data
Warehouse Units (DWU), and Cosmos Database uses Request Units (RUs). You will also want to
demonstrate the ease of scaling these systems up or down in line with your system demands.
● Availability-Any availability requirements that are required should be adopted into the platform that
you migrate into. Azure SQL Databases highly-available as standard, with three copies of your data-
base held in the same data center to keep the data online and accessible during patching and
transient hard failures. SQL Server on Azure VMs would require HA technologies configured such as
Always On Failover Clustering, Always On availability groups, database mirroring or Peer to Peer
Replication.
● Disaster Recovery-Based on the organizations Restore Time Objective (RTO) and Restore Point
Objective (RPO), you should also consider if the technology that you are migrating to can meet these
requirements. This involves understanding the disaster recovery capabilities of each of the available
data platforms on Azure.
● Compliance-Be mindful of the compliance and regulatory requirements of the organization. Azure
data centers comply with strict regulations and compliance standards, to help customers meet
international data protection laws and industry requirements. In addition, understanding the security ,
privacy, compliance and transparency which is reflected in the capabilities of the platforms and
services offered through Azure will help you select the right service to do the job.
● Third party considerations-You may be using third party applications that are not yet compatible
with Azure. Check with the appropriate vendor for any updates, compatible versions or alternate
products.
Planning Stage
The planning stage of a data platform modernization project is used to determine the target platform,
and whether the data migration involves a one time sync or a continuous flow of data. You will also build
in any rollback or mitigation plans required if there should be any planned or unplanned interruptions or
issues.
Platform target options

There are two high level choices available to you when it comes to choosing the target platform.
● Infrastructure as a Services (IaaS)-In this approach, you will migrate your data to a virtual machine
that has SQL Server installed.
● Platform as a Service (PaaS)-In this approach, you will migrate your data to a data platform service
that suits your workload. For transactional workloads, that would involve Azure SQL Database or
Cosmos DB. For Online Analytical Processing (OLAP) type workloads, this would involve Azure SQL
Data Warehouse.
Choosing the right target platform

Choosing the right target platform is dependant on the motivation for moving in the first place. This can
be typically categorized into the following:
Choosing target platform by features

● Azure SQL Database-Azure SQL Database would be appropriate for use if the application surface
area is database scoped. If the application uses some SQL features listed below in Managed Instances,
then Azure SQL Database may not be appropriate as not all are yet available.
● Azure SQL Database Elastic Pools-Azure SQL Database would be appropriate for use if the applica-
tion surface area is database scoped. If the application uses some SQL features listed below in
Managed Instances, then Azure SQL Database may not be appropriate as not all are yet available.
● Azure SQL Database Managed instance-Would be appropriate for use if the application surface area
is instance scoped and requires features not available in Azure SQL Database such as:
● SQL Agent
● MSDTC
● DQS
● MDS
● Database Mail
● Filestream
● Filetable
● Polybase
● Support for Linked Servers
● Supports new Azure cloud services such as Threat Detection
● SQL Server on Azure VMs-Use if application surface area is instance scoped and requires features
not available in Azure SQL Database Managed Instance. Additionally, supports local instances of:
● SSRS
● SSAS
● SSIS
● Azure SQL Data Warehouse-Use if you have applications that run complex queries across petabytes
of data that can leverage massively parallel processing (MPP) to reduce query processing times from
hours to minutes
Migrating SSAS, SSIS and SSRS to an Azure fully managed

service offering
If you are looking to also migrate SSRS, SSAS or SSIS, not all SQL Server components have an Azure data
services equivalent currently. You can consider migrating the following services within an Azure Virtual
Machine with SQL Server installed. Otherwise, you should consider the following:
● SQL Services Analysis Services (SSAS)-SSAS can be migrated to Azure Analysis Services which is
largely compatible with recent versions of SQL Server Analysis Services Enterprise Edition.
● SQL Server Integration Services (SSIS)-Use the Azure SSIS Integration Runtime, which is the
compute infrastructure used by Azure Data Factory. SSIS packages can be invoked using stored
procedures in Azure Data Factory to provide true first-class support of SSIS package execution.
● SQL Server Reporting Services (SSRS)-SSRS currently has no direct cloud-based equivalent, but
reports could be re-written using Microsoft Power BI or migrate to SSRS running on an Azure VM.
Choosing target platform by cost

● Azure SQL Database-The Platform-as-a-Service nature of Azure SQL Database greatly reduces
administration and management costs over the more traditional SQL Server on Azure IaaS topology,
as most of the required work is completed silently in the background for you by Microsoft Operations.
This is evident at scale where considerable savings in time and effort can be made.
● Azure SQL Database Elastic Pools-Azure SQL Database Elastic Pools can offer considerable savings if
used by multiple databases that have varying and unpredictable usage demands. The sharing of
compute resources amongst all databases in the pool means that customers are not required to
over-provision resources for all databases to meet their infrequent spikes in usage. Further savings are
made on lowered server maintenance and administrative costs as most of the required work is
completed silently in the background by Microsoft Operations.
● Azure SQL Database Managed instance-Managed Instances is offered to those customers who want
a fully managed service offering, where they can easily lift and shift their on-premises environment
with minimal configuration changes. The environment offers a minimum of 8 cores and up to 8 TB of
storage and sits in an isolated virtual network. This offering is great for customers that want to quickly
get to the cloud and want to avoid the overhead of virtual machines.
● SQL Server on Azure VMs-VMs impose higher compute, storage, and management costs over the
Azure SQL Database offerings but grants greater control across the SQL Server and infrastructure.
● Azure SQL Data Warehouse-Azure SQL Data Warehouse can reduce your cost by being able to
leverage the MPP architecture to process complex queries in minutes rather than hours.
Offline versus online migrations

In the planning stage, you will want to consider whether you perform an offline or an online migration.
With offline migrations, application downtime begins at the same time that the migration starts. To limit
downtime to the time required to cut over to the new environment when the migration completes, use
an online migration. It's recommended to test an offline migration to determine whether the downtime is
acceptable; if not, do an online migration. Furthermore, online versus offline options may not be available
depending on the Azure Service offering.
Transform and Optimize Stage

Your assessment and planning would have identified aspects of your applications and database that
would require post migration work that either transforms or optimizes a feature to ensure a successful
migration. Transformation typically involves work that requires you to fix or change an aspect of a
database. Optimization typically involves making a modification to the migrated database to take
advantage of a feature, or optimizes its usage within Azure.
Transformation
There may be one or more of the following changes that need to be made to a database to ensure that it
works successfully post migration
Install pre-migration version upgrades

There will be a minimum version that your on-premises SQL Server must be in order to perform a
migration. If this version is not met, then install any updates to ensure the minimum requirement is met.
Fix any errors that are identified by the migration assess-

ment tools
At the same time as performing version upgrades, fix any errors that are reported in SQL Server logs, or
Windows Event Viewer. You don't want to migrating any SQL Server that has issues.
Implement database schema changes

Your assessment phase may have identified changes that need to be made to the database schema, and
you should make these changes at the transformation phase.
Migrate existing integrated database services into Azure

As we previously found, Azure doesn’t yet have a like-for-like comparable cloud service for SSIS or SSRS.
These workloads will require implementing new Azure services that can partially support the required
workloads, keeping the workloads on-premises, or implementing them in virtual machines.
Handling SSIS workloads in the cloud

Slightly different from on-premises SSIS, where the SSIS runtime is hosted by the SQL Server, in Azure it is
Azure Data Factory that hosts the runtime engine for SSIS packages. The runtime engine is called the
Azure SSIS Integration Runtime (SSIS IR). The SSIS Catalog Database that SSIS uses (called SSISDB) is
provisioned on Azure SQL Database, which should be implemented in the same Azure region as the SSIS
IR.
Creation of the Azure Data Factory is easily accomplished via the Azure Portal or PowerShell. The neces-
sary Azure SSIS integration runtime can then be created and started, making it ready to service SSIS pack-
ages. To deploy SSIS packages to Azure you can use either SQL Server Data Tools (SSDT) or SQL Server
Management Studio (SSMS), which connects to the Azure SQL Server that hosts the SSIS Catalog
(SSISDB).
SSIS can also be used to migrate data from on-premises to Azure. Here, Azure Data Factory again hosts
the AzureSSIS integration runtime.
Optimize
There may be one or more of the following optimization guidelines you will want to follow during the
migration to ensure that your organization is getting the most out of their investment in Azure.
Assess what new features may be available on the target

platform
The assessment and planning phase would have identified to Azure features that you would have wanted
to use on completion of the migration. Implement the features that are appropriate.
Re-structure workloads into more cost effective or perfor-

mance effective sets
Organize your databases into the appropriate performance tiers that meet the requirement of the
workloads. In the past these databases may have been “dumped” onto a single SQL Server. In Azure, you
are able to configure seting for each databases so that they are both performant and cost effective.
Choose the highest service level and performance tier dur-

ing the migration
While you perform the actual migration, set the highest service level and performance tier that your
budget allows for the migration time to maximize the transfer performance.
Ensure workloads are right-sized

Look to realign workloads into the more appropriate service levels and performance tiers once you have
completed the migration. With the fully managed service offering of Azure SQL Database it’s possible to
get a
more accurate size of the databases by using tools such as the Azure SQL Database DTU calculator or
comparing on-premises core requirements to vCores and dial up the allocated resources only if required
Minimize the distance between your BACPAC file and the

destination data center
Should you perform a migration using the BACPAC tool (More information to follow in later modules),
make sure that the BACPAC files are placed in the same data center region as the SQL Database that you
are migrating to. This will reduce the network latency.
Disable auto-statistics during migration

On Azure SQL Database, statistics objects have “Auto update” turned on by default. The auto update of
the statistics is done when a sufficient amount of change to a table has occurred. During the import
process, when nearly all the rows in all tables are changing, this trigger is repeatedly met, causing
continuous attempts to update the statistics.
This update uses valuable IO resources to complete, which detracts from the overall pool of IO resources
available for the import process and extends the migration timeline.
Partition tables and indexes

Portioning tables and indexes can help with the transfer and access of data during a migration. The data
can be partitioned into one or more subsets that are similar and will allow for the transfer of data quicker.
Partitioning large datasets can also reduce lock contention, because lock escalation can be activated at
the partition level without
hurting the entire dataset. Once the data is moved to the cloud, then queries may performance faster and
reduce overhead costs for applications. Overall partitioning tables and indexes helps the migration cost
and mitigates future risk after the migration by helping increase performance of the data.
Drop indexed views and recreate them once finished

When an indexed view is used, every time data is modified on an underlying table Azure SQL maintains
the index entries on those tables, but also the index entries on the view. This can affect write performance
and again reduce IO resources available for the import process, extending the migration timeline. In
addition, they also have the potential to cause other issues such as lock contentions.
Migrate, validate and remediate

This phase involves the migration itself, and importantly the validation steps and remediation steps
required to confirm a successful migration. The previous planning, assessment, and transformations
stages will have ensured everything is ready to be migrated and functioning correctly once moved to
Azure. Therefore, all that’s left to do is to prepare the migration tools required, perform the migration,
and run post migration functional and performance validations.
Migration, validation and remediation considerations

There are a wide range of tools that can be used to perform the migration to the selected target plat-
form. These tools will be covered in later modules. But you should consider the following when perform-
ing the migration
Understand your workload requirements as a starting point

This should have been established during the assessment and planning stage including storage size,
storage throughput, and high availability requirements. If you are not sure of this by this stage, you may
want to revisit the previous stages to reduce the risk of migration failure.
Select non-critical workloads or low priority databases for

migration initially
This can help ensure the migration process works and help gauge how long the migration is likely to take
when you
get to your critical workloads.
Run a test migration with chosen tool

Before migrating the database, run a test migration of the database to confirm the amount of time the
migration will take, and any issues encountered during the migration process.
Test database for issues

When the test migration completes, perform validation steps to confirm that the data is migrated in full
and check for any issues encountered
Test the plan to mitigate risk associated with downtime and

compatibility issues
Conduct test migrations before doing the final migration by getting to know any errors before getting to
more critical workloads and have a rollback plan prepared in case of an emergency.
Assess migration tools based on disruption to help lower the

risk of database downtime
In the coming sections we’ll look at which migration tools require downtime to complete, and which ones
can work in the background while the workload remains online and available. You can work with these
tools in the testing phase to discover the impact that they have on your migration.
Repeat issue fixes until the database is fixed

For each issue discovered during testing, find a fix, and then retest. Keep repeating this test-fix cycle until
all issues
have been found and repaired.
Continually iterate on your migration process

During the first migrations small changes will be found, documentation or processes will need to be
created, or unnecessary migration steps will need to be removed. These findings should be fed back in to
the migration process that you are following to optimize the remaining higher priority migrations.
Consider the maintenance windows that are available to the

application and database targeted for migration
If you have critical workloads, they may only be able to go offline for a few minutes at a very specific
point in time. Alternatively, a workload may be used for historical reporting purposes and can easily be
taken offline most days of the week without impacting end-users. Understanding these differences will
help decide which migration technique needs to be used and when they should be done.
Take old databases and application offline

Remember to take the source database and application offline before starting the migration process to
avoid confusion and preserve the original data in case there is a need to refer to them or perform a
roll-back.
Test third-party applications

Confirm that any third-party applications that have been identified as being migrated will still function as
expected in the cloud as each application is moved, including any dependencies.
Create new disaster recovery and maintenance plans

Take the time to update your disaster recovery plans, as data has now moved locations and is accessed in
a different manner. Consider improving disaster recovery plans by utilizing the geo-replication features of
Azure to protect data that may previously have been too complex or costly to protect when on-premises.
Maintenance plans will also need to be reviewed as Azure now performs many of those maintenance
tasks automatically for you in the
background, removing the need to perform them manually.
Use toolsets to give you greater insight into your environ-

ment and greatly assist with the migration process
Numerous Microsoft and third-party tools exist that can help keep tabs on your SQL environments both
on premises and in the cloud, including the Azure Database Migration Service (DMS) and Azure SQL
Database Intelligent Insights.
Lesson Summary
In this lesson, you learned have learned the stages that you should undertake in order to increase the
successful outcomes of a migration. This involves:
● The initiate and discovery stage
● The assessment stage
● The planning stage
● The transform and optimize stage
● The validate and remediation stage
Important
Knowledge Check
Question 1
Which migration stage enables you to identify any potential blockers to a migration, any breaking changes
that require post migration fixes and the features that the migration can utilize.
 Initiate and discovery stage
 Assessment stage
 Planning stage
 Transform and optimize stage
 Migrate, validate and remediate stage
Question 2
You want to take advantage of the auto-scaling of Azure SQL Database once you have migrated an
on-premises database. Which migration stage would this be covered?
 Planning stage
Question 3
You want to understand the business requirements and reasons for migrating your data estate to Azure. At
which stage of the migration process is this done?
 Planning stage
Data migration technologies 23
Data migration technologies

Lesson 3: Data Migration Platforms
The discovery and assessment phase should have given you a clear understanding of your current
environment and the workloads that operate within it. You should also understand what you are striving
for in your data modernization outcomes. By understanding this, you can select an appropriate data
platform technology to support your workloads.
Learning objectives
In this lesson, you will learn the migration benefits of:
● SQL Server on Azure Virtual Machines
● SQL Database
● SQL Database Managed Instance
● SQL Data Warehouse
SQL Server on a Virtual Machine

Using Infrastructure as a Services (IaaS) is very useful for any application solutions that require a quick
migration to the cloud with minimal changes. All the versions and editions of SQL Server are available
and offer 100% compatibility with SQL Server, allowing you to host as many databases as needed and
executing cross-database transactions. There are also other benefits that may get you to consider using
IaaS platform including:
● Configure and manage high availability, disaster recovery, and patching for SQL Server easier than
on-premises machines
● Customized environment with full administrative rights
● SQL Server instances with up to 64 TB of storage and as many databases as needed
● Fully supports SQL Server transactional replication, AlwaysOn Availability Groups, Integration Services,
Log Shipping to replicate data, and traditional SQL Server backups
Due to the simple nature of the migration, migrating to this target platform is often referred to as “lift
and shift”
Azure SQL Database

Azure SQL Database is the collective term for Microsoft's SQL Server Platform-as-a-Service (PaaS)
offering. It's fully managed and provides organizations with a highly performing, reliable and secure,
general purpose relational database engine in the cloud. There are three products within the Azure SQL
Database family, each providing different benefits:
● Single databases
● Elastic Pools
● Managed Instances
A Single Database has its own resources and is deployed to a logical SQL Database server where it is
managed. There are several tiers of performance, each providing different levels of throughput, perfor-
mance, storage and cost. SQL Database Elastic Pools provide organizations with a cost-effective way for
deploying and managing multiple databases with different workload characteristics. Elastic Pool databas-
es are deployed onto a single SQL Database server where resources are shared between all of the
databases on that server.
Single Databases can be purchased via two different models; the DTU Purchasing Model and the vCore
Purchasing Model. Elastic Pool databases can purchased via the eDTU Purchasing Model and the vCore
Purchasing Model. A Database Throughput Unit (DTU) is a unit of performance that is calculated as a
result of blending CPU, memory, data I/O and transaction log I/O. he higher the DTU, the higher the
performance level. The DTU Purchasing Model provides customers with per-hourly, fixed price billing. The
vCore Purchasing Model enables customers to select a performance level based on vCores and memory,
as opposed to DTUs, allowing compute to be scaled independently of the storage at a more granular
level. As an added benefit, the vCore Purchasing Model allows organizations to license Azure SQL
Databases with the Azure Hybrid Use Benefit for SQL Server. This means that customers with Active
Software Assurance (SA) coverage for SQL Server Enterprise and Standard Edition core licenses can
transfer this core-based license entitlement and receive savings of up to 30%
Under the DTU Purchasing Model, there are two different service tiers:
● Basic
● Standard
● Premium
Under the vCore Purchasing Model, there are three different service tiers:
● General Purpose
● Business Critical
● Hyperscale
Using a single Azure SQL Database service will suit many business requirements that have databases with
predictable performance requirements and it can bring about the following benefits:
● A SQL Server engine compatibility and native virtual network (VNET) support
● Dynamic scalability with no downtime
● Built-in intelligent optimization, global scalability and availability, and advanced security options
● Eliminates hardware costs and reduces administrative costs
● Built-in fault tolerance infrastructure capabilities, Azure SQL Database provides features, such as
automated backups, Point-In-Time Restore, geo-restore, and active geo-replication to increase
business continuity for applications hosting data in Azure SQL Database
● Databases of up to 4 TB or larger databases that can be horizontally or vertically partitioned using a
scale-out pattern
Azure SQL Database Managed Instance

For organizations looking to migrate large numbers of SQL Server databases from on-premises or VM/
hosted, with as low effort as possible, Managed Instance provides a simple, secure and economical
migration destination. It offers broad SQL Server compatibility and network isolation making it easy to
lift-and-shift SQL Server databases to Azure. You can now simply backup an on-premise database and
restore it into an Azure SQL Database Managed Instance. Built on the same fully-managed service
offering infrastructure as Azure SQL Database and maintaining all the Azure SQL Database features like
active geo-replication, high availability, automatic backups, database advisor, threat detection, intelligent
Data migration technologies 25
insights, and vulnerability assessment. It also adds support for database sizes up to 8TB and SQL Server
features like SQL Agent, cross-database querying and replication.
Using Azure SQL Database Managed Instance brings about the following benefits:
● Isolated environment (single-tenant service with VNET, dedicated compute and storage resources)
● Customer configurable backup retention and recovery
● Database Advisor and Log Analytics for advanced workload analysis
● Automatic database tuning and maintenance for predictable performance
● Monitor, troubleshoot and manage at scale
● Azure Portal functionality for manual service provisioning and scaling
● Azure AD authentication, single sign-on support
● Adheres to same compliance standards as Azure SQL Database
● Encryption of the data in transit and rest with customer provided encryption keys
● No patching and version upgrade overhead
Azure SQL Database Managed Instance is a SQL Server database engine. While it includes SQL Server
Agent, it doesn't include other components of SQL Server product including:
● SQL Server Reporting Services (SSRS).
● SQL Server Analysis Services (SSAS).
● SQL Server Integration Services (SSIS).
Azure SQL Data Warehouse

SQL Data Warehouse is a cloud-based Enterprise Data Warehouse (EDW) that leverages Massively Parallel
Processing (MPP) to quickly run complex queries across petabytes of data. It is a distributed system
designed to perform analytics on large data. Migrating to SQL Data Warehouse requires some design
changes to table schemas and code that are not difficult to understand but might take some time to
implement. If your business requires an enterprise-class data warehouse, the benefits are worth the effort.
However, if you don't need the power of SQL Data Warehouse, it will be more cost-effective to use Azure
SQL Database or SQL Server on Virtual Machines.
Consider using SQL Data Warehouse when you:
● Have one or more Terabytes of data
● Plan to run analytics on substantial amounts of data
● Need the ability to scale compute and storage
● Want to save on costs by pausing compute resources when you don't need them.
Do not use SQL Data Warehouse when your workloads have:
● High frequency reads and writes
● Large numbers of singleton selects
● High volumes of single row inserts
● Row-by-row processing needs
● Incompatible formats (JSON, XML)
Note: This course will focus on transactional SQL Workloads.
Lesson Summary
In this lesson, you have explored the range of data platform technology available and how the are
appropriate to support your workloads. In this lesson, you have learned the migration benefits of:
● SQL Database
● SQL Database Managed Instance
Important
Knowledge Check
Question 1
You will be migrating three databases to Azure. Each of the databases contains queries that retrieve data
from the other two databases. Which Azure data platform technology would continue to meet this require-
ment?
 SQL Server on Azure Virtual Machine
 Azure SQL Database
 Azure SQL Database Elastic Pool
 SQL Server
Question 2
You have 30 departmental transactional databases that will be migrated to Azure. There is very low utiliza-
tion of each of the databases, but occasionally, some of the databases perform large volumes of data loads
that require extra resources to process the data. Which Azure data platform technology would continue to
meet this requirement?
 Azure SQL Data Warehouse
 Azure SQL Database Elastic Pools
 Azure SQL Database Managed instance
Module summary 27
Module summary
Module Introduction
In this module, you have learned the purpose of Data Platform Modernization and the benefits that data
platform modernization can bring to an organization. You have learned the various stages of a data
platform migration projects to understand what is involve in each stage to maximise the chances of a
successful Data Platform Modernization. Finally, you explored the various data migration platform
technologies to understand how each is beneficial in a migration.
Learning objectives
In this module, you have learned to:
● Understand Data Platform Modernization
● Understand the Stages of Migration
● Data Platform Technologies
Answers
Question 1
The Northwind building has a key card access system which has a dedicated server. The server connects
to the Key card system through a physical card installed in the server.
How should this server be categorized for migration? (Choose all that apply)
■ Remain
 Rehost
 Refactor
 Rearchitect
 Rebuild
 Replace
 Retire
Explanation
The use of a physical card in the server excludes this server from migration to Azure.
Discussions with the vendor may identify the possibility or either a software upgrade or an alternative piece
of hardware that may allow the server to be migrated to Azure.
If neither of these are possible solutions then Remain should be the choice with a view to replacing the
system with one that is cloud compatible.
Question 2
The Northwind building has a facilities management system that monitors the temperature throughout
the building.
The temperature sensors communicate via a VPN with a central server which stores the data in a data-
base on a shared server for later analysis.
The building where the database server is being held is due to be demolished.
How should the database server be categorized for migration? (Choose all that apply)
 Remain
 Rehost
■ Refactor
 Rearchitect
 Rebuild
 Replace
 Retire
Explanation
The database server is already remote from the application server and communicates via a VPN.
The database is already on shared infrastructure and should be assessed to see whether it can be hosted
within PaaS or alternatively onto a shared IaaS server.
Module summary 29
Question 1
Which migration stage enables you to identify any potential blockers to a migration, any breaking
changes that require post migration fixes and the features that the migration can utilize.
■ Assessment stage
 Planning stage
Explanation
The assessment stage is where you try to identify any potential blockers to a migration, any breaking
changes that require post migration fixes and the features that the migration can utilize.
Question 2
You want to take advantage of the auto-scaling of Azure SQL Database once you have migrated an
on-premises database. Which migration stage would this be covered?
 Planning stage
■ Transform and optimize stage
Explanation
Using auto-scaling in Azure SQL Database is taking advantage of an Azure feature that is available. This
would be considered in the transform and optimize stage
Question 3
You want to understand the business requirements and reasons for migrating your data estate to Azure.
At which stage of the migration process is this done?
■ Initiate and discovery stage
 Planning stage
Explanation
Understanding the business requirements and the reasons for migrating is performed in the initiate and
discovery stage
Question 1
You will be migrating three databases to Azure. Each of the databases contains queries that retrieve data
from the other two databases. Which Azure data platform technology would continue to meet this
requirement?
■ SQL Server on Azure Virtual Machine
 Azure SQL Database Elastic Pool
 SQL Server
Explanation
Azure SQL Database and Azure SQL Database Elastic Pool are unable to perform cross database queries.
SQL Server is an on-premises data platform technology. Therefore, SQL Server on Azure Virtual Machine
would be the best option in this case
Question 2
You have 30 departmental transactional databases that will be migrated to Azure. There is very low
utilization of each of the databases, but occasionally, some of the databases perform large volumes of
data loads that require extra resources to process the data. Which Azure data platform technology would
continue to meet this requirement?
■ Azure SQL Database Elastic Pools
 Azure SQL Database Managed instance
Explanation
Azure SQL Database Elastic Pools would be an appropriate choice in this scenario as you allocate perfor-
mance resources to a pool rather than an individual database and pay for the collective performance
resources of the pool rather than for single database performance.
Module 2 Choosing the right tools for Data
Migration
Module introduction
Module Introduction
In this module, the student will be introduced to the Data Migration Guide as a starting point for the
source of information that your organization should use for step by step guidance for modernizing your
existing data platform. They will then learn the value of the Microsoft Assessment and Planning Toolkit to
help discover the data assets that currently exist in their environments.
The students will then learn the tools that can be used to help them to assess for compatibility or
workload issues using both the Data Migration and Data Experimentation Assistant. Then an overview of
the SQL Server Migration Assistant is provided to show student how to migrate no-SQL Server workloads.
Finally, they will see how the Azure Database Migration Service can be used to aid online migration of
databases to reduce the amount of downtime
Learning objectives
In this module, you will:
● Discover the Database Migration Guide
● Build your data estate inventory using Map Toolkit
● Identify Migration candidates using Data Migration Assistant
● Evaluate Data workload using Database Experimentation Assistant
● Migrate non-SQL Server workloads using SQL Server Migration Assistant
● Data Migration using Azure Database Migration Service
MCT USE ONLY. STUDENT USE PROHIBITED 32 Module 2 Choosing the right tools for Data Migration
Discover the Database Migration Guide

Lesson 1: Data Migration Guide
The Database Migration Guide should be the starting point for anyone wanting to perform any database
migration. Whether you are migrating from SQL Server, Oracle or MySQL, the database migration guide
provides a wealth of information that will help you be successful in your approach.
Learning objectives
● Explore the Data Migration Guide
● Supported Sources for the Data Migration Guide
● Microsoft migration tools and services
Exploring the Data Migration Guide

The Database Migration Guide is a website that provides comprehensive, step-by-step guidance for
performing migrations. It also provides information about the tools, software, and programs that are
available to assist you in performing these migrations. The website can be found at https://datamigration.
microsoft.com/ and you should use this as a basis for information beyond this course as it is always being
updated with the latest information and guidance.
There is also the opportunity to explore the range of third party tools that are available to help you with
you migrations through the network of Microsoft Partners. In addition, case studies from customers are
also available to gain a perspective from those that have already migrated their SQL workloads
Discover the Database Migration Guide 33
Supported Data Sources

The Database Migration Guide provides information about a wide range of data sources including:
Microsoft SQL Server

SQL Server is Microsoft flagship SQL-based relational database management system designed for use in
corporate applications, both on premises and in the cloud. The Database Migration Guide provide
guidance on migrating the on-premises version to the following cloud platforms:
● Azure SQL Database
● Azure SQL Database Managed Instance
● SQL Data Warehouse.
Oracle Database
Oracle Database is a relational database management system from the Oracle Corporation and is often
used by large enterprises to manage and process data.
The Database Migration Guide provide guidance on migrating the on-premises version to the following
cloud platforms:
● Azure Database for PostgreSQL
DB2 Database
DB2 Database is another relational database management system from IBM that is used by many organi-
zations. The Database Migration Guide provide guidance on migrating the on-premises version to the
following cloud platforms:
MySQL
MySQL is an open source SQL database management system which is developed, distributed, and
supported by Oracle Corporation. The Database Migration Guide provide guidance on migrating the
on-premises version to the following cloud platforms:
● Azure Database for MySQL
PostgreSQL (Postgres)
PostgreSQL is another open source SQL database management system. The Database Migration Guide
provide guidance on migrating the on-premises version to the following cloud platforms:
● Azure Database for PostgreSQL
MongoDB
MongoDB is a document database that stores data in flexible, JSON-like documents, meaning fields can
vary from document to document and data structure can be changed over time. The Database Migration
Guide provide guidance on migrating to the following cloud platforms:
● Azure Cosmos DB
Cassandra
Apache Cassandra is a free and open-source, distributed, wide column store, NoSQL database manage-
ment system designed to handle large amounts of data across many commodity servers. The Database
Migration Guide provide guidance on migrating to the following cloud platforms:
● Azure Cosmos DB
Microsoft Access
Microsoft Access is an easy-to-use tool for creating business applications and databases, from templates
or from scratch. With its rich and intuitive design tools, Access can help business users create appealing
and highly functional applications in a minimal amount of time. The Database Migration Guide provide
guidance on migrating to the following cloud platforms:
SAP ASE
SAP ASE (Adaptive Server Enterprise), was originally known as Sybase SQL Server is a relational database
management system from SAP. The Database Migration Guide provide guidance on migrating to the
following cloud platforms:
Microsoft Azure Table Storage

Azure Table Storage is a NoSQL key-value store for rapid development using massive semi-structured
datasets. The Database Migration Guide provide guidance on migrating to the following cloud platforms:
● Azure Cosmos DB
Migration Tools and Services

There are a number of tools that you can use to help you through the different stages of a Data Platform
Modernization project. The Database Migration Guide website provides links to some of the relevant
documentation that can help you use each of the tools. The following is a summary of each of the tools
that you can use in a Data Platform Modernization project.
Microsoft Assessment and Planning Toolkit (MAPS)

The Microsoft Assessment and Planning Toolkit (MAPS) is a very useful tool to use in the discovery stage
of a Data Platform Modernization project when you are wanting to understand the make-up of your
current environment. The tool helps you to build an inventory of the servers that you have on your
network, the specs of the servers and the services that are running on them.
Discover the Database Migration Guide 35
Data Migration Assistant (DMA)

The Data Migration Assistant helps you understand compatibility issues that can impact database
functionality in your new version of SQL Server or Azure SQL Database. This tool can be helpful to you in
identifying any issues that can affect a migration to an Azure SQL data platform.
Database Experimentation Assistant (DEA)

The Database Experimentation Assistant can help in the assessment stage by allowing you to identify any
queries that may have compatibility errors, any workloads that may have degraded query plans, and a
general assessment of how a workload would perform on a target platform.
SQL Server Migration Assistant (SSMA)

The SQL Server Migration assistant is a tool designed to automate database migration to SQL Server from
Microsoft Access, DB2, MySQL, Oracle, and SAP ASE. In order to use this successfully you first must
understand the source database and target database and download the right version of the tool as
shown in the downloads section of this website1. The download includes a GUI client based application
to manage migration process. Depending on the download you choose, a seperate extension pack will
install functionalities in SQL Server to emulate other third party features not natively supported in SQL
Server.
SSMA automates all aspects of migration including migration assessment analysis, schema and SQL
statement conversion, data migration as well as migration testing. Like the DMA, it can support you in the
assessment and planning stage of a Data Platform Modernization project as well as with the migration
itself.
Azure Database Migration Service

The Azure Database Migration Service can help with the migration stage of a Data Platform Moderniza-
tion project taking data from multiple database sources to Azure Data platforms with minimal downtime.
The service uses the Data Migration Assistant to generate assessment reports that provide recommenda-
tions to guide you through the changes required prior to performing a migration. When you're ready to
begin the migration process, the Azure Database Migration Service performs all of the required steps.
Lesson Summary
In this lesson, you have learned how the Database Migration Guide can be a useful resource in helping
you perform a database migration.
Learning objectives
In this module, you have learned:
● What is the Data Migration Guide.
● The supported sources for the Data Migration Guide.
● The various Microsoft migration tools and services.
Important
1 https://docs.microsoft.com/en-us/sql/ssma/sql-server-migration-assistant?view=sql-server-2017
Knowledge Check
Question 1
Which of the following Data Platform technologies cannot be migrated to Azure Cosmos DB
 Cassandra
 SAP ASE
 Microsoft Azure Table Storage
 MongoDB
Question 2
Which tool would you use to aid you with the discovery of servers, thier specs and the services running on
the server?
 Azure Database Migration Service
 Database Experimentation Assistant
 Data Migration Assistant
 Microsoft Assessment and Planning Toolkit
Question 3
Which stage of the Data Platform Migration project does that answer to the previous question support?
 Planning stage
Build your data estate inventory using MAP Toolkit 37
Build your data estate inventory using MAP

Toolkit
Lesson 2: Build your Data Estate Inventory using
the Microsoft Assessment and Planning Toolkit
In this lesson, you are introduced to the Microsoft Assessment and Planning (MAP) Toolkit to aid Data
Engineers and Database Administrators with a tool that enables them to discover the technology assets
that exists within thier networks. In this lesson, you will learn the capabilities of the tool and how you can
use it.
Learning objectives
● What is the Microsoft Assessment and Planning (MAP) ToolKit
● How to use the MAP Toolkit
What is the Microsoft Assessment and Planning

(MAP) ToolKit
The Microsoft Assessment and Planning (MAP) Toolkit is a free utility that can use to determine whether
or not a particular Windows infrastructure, software application or user's device is adequately prepared to
migrate to a new operating system, server version or cloud environment. It provides a powerful inventory,
assessment, and reporting tool to simplify the migration planning process.
Installation and Guidance

The Microsoft Assessment and Planning (MAP) Toolkit and supporting documentation can be download-
ed at the following website2. The download includes the following files:
● MapSetup.exe: MAP source installation files
● MAP_Sample_Documents.zip: provides sample documents on the the type of information that is
collected by the tool
● MAP_Training_Kit.zip: provides instrcutions on how to use MAP
● readme.htm
The tool can be run on a PC on a wide range of operating systems from Windows 8.1 Professional and
Enterprise editions onwards with the following spec:
● A dual-core 1.5GHz processor
● 2.0 GB of RAM
● 1 GB of available disk space
2 https://www.microsoft.com/en-us/download/details.aspx?id=7826
Collecting inventory data

MAP makes use of Windoes Management Instrumentation (WMI) and performance collection protocols
to communicate with machines on the network to collect inventory information and performance data. As
a result remote administration and the neccessary ports should be enabled to allow MAP to perform an
analysis of the servers to collect the inventory data.
In addition, there are a number of different discovery methods that can be used to determine which
machines to perform an inventory against. At a simple level, you can manually define a computer name
and authenticate against a single machine to collect data about the one machine. Alternatively, you can
scan for computeres and servers that are members of an Active Directory Domain. Additional methods
include:
● Windows networking protocols
● System Center Configuration Manager
● Scan an IP address range
● Import computer names from a file
Performing an inventory of SQL Server database

The MAP Toolkit feature performs an inventory of web applications and SQL Server databases in your
environment and assesses them for migration to a Windows Azure Platform. You can select which web
applications and SQL Server databases in your environment to consider for migration. Based on your
selection, a Windows Azure Application Summary will be generated with recommendations.
By selecting Windows Azure Platform Migration from the Inventory and Assessment Wizard Inventory
Scenarios page you will be able to specifically collect Windows Azure Platform Migration information
such as hardware, device, and software information for Windows-based machines in your environment,
including IIS instances, web applications and Microsoft SQL Server databases running on them. For more
detailed information for just SQL Server, select Databases from the Scenario group in the MAP wizard.
Generating reports
Whilst you have the ability to review the results in the MAP UI, there is the option to generate reports.
This is useful when presenting your finding to other IT professional or executive. Click Generate Detailed
SQL Server Reports at the top of the scenario detail page to start generating the reports. After which
you only need to make slight modifications to prepare it for use in written documentation helping to pro-
vide information about your estate
Using the MAP Toolkit

The following are the steps required to perform a discovery of the SQL Servers that exist on your network
Collecting inventory data

1. Launch the MAP Toolkit. You may want to resize the application to full screen.
2. Click Yes to accept the User Account Control (UAC) dialog to run this application.
3. In the Create or Select a Database dialog click Create an inventory database and type MAPAssess-
ment as a new database name and click OK. (The lab uses this database to do a very small inventory
of your local computer.)
4. In the scenario detail page click Perform an Inventory to launch the inventory wizard.
5. In the Inventory Scenarios page, ensure that the Windows Azure Platform Migration checkbox is
selected, then click Next.
6. In the Discovery Methods page, uncheck Use Active Directory Domain Services (AD DS).
7. Check Manually enter computer names and credentials then click Next.
8. In All Computer Credentials page, click Create.
9. In the Account Entry dialog, type the username for the local computer user (example: Administra-
tor) in the Account Name field
10. In both the Password and Confirm Password fields, type the password for the local computer user
(example: password) then click Save.
11. In the All Computer Credentials Page, click Next.
12. Click Next in the Credentials Order page.
13. In the Enter Computers Manually Page, click Create.
14. In the Specify Computers and Credentials page, type the name of the local computer (example:
MAP-HOL) as the computer name and click Add.
15. Check Use All Computers Credential list and click Save.
16. Click Next and review the information displayed in the Summary page.
17. Click Finish to launch a status dialog and the inventory process.
18. When it finishes, click Close on the status dialog.
Reviewing Discovery Results via the UI

1. Select File → Select a Database from the main menu to launch the Create or select a database to
use dialog.
2. Click Use an existing database, and select MAPAssessment from the Databases menu, and click OK.
3. Click the Database scenario group in the left pane of the UI, then click the SQL Server Products tile.
4. Inspect the scenario detail page and observe the tables and pie chart with SQL Server information.
Generating a Discovery Results Report

1. Click the Database scenario group in the left pane of the UI, then click the SQL Server Products tile.
2. Click Generate Detailed SQL Server Reports at the top of the scenario detail page to start generat-
ing the reports and to launch a status dialog.
3. After the status dialog reports that the generation has completed, click Close.
4. Select View → Saved Reports from the main menu (or navigate to a previously opened file explorer)
to launch a file browser on the directory where the generated files are stored.
Note: Reports are created in folders named after the database currently in use.
1. Open the SQLServerAssessment-date-and-time and SQLServerDatabaseDetails-date-and-time
Excel documents.
2. In the SQLServerAssessment Excel report, view the Summary tab to see how many SQL Server
database components were found in the network in total.
3. View the Database Instances tab to see all database instances listed with server details including if
the server is virtualized (Machine Type).
4. View the Components tab to see all installed database components listed with server details.
5. In the SQLServerDatabaseDetails Excel report, view the SQL Server database information.
6. After viewing close reports and file browser.
Lesson Summary
In this lesson, you have been introduced to the Microsoft Assessment and Planning (MAP) Toolkit and
how it can help you in the discovery stage of a Data Platform Modernization project. You have also
learned the capabilities of the tool and how you can use it to gain information about the SQL Servers on
your network.
Learning objectives
● What is the Microsoft Assessment and Planning (MAP) ToolKit
● How to use the MAP Toolkit
Important
Knowledge Check
Question 1
You are a consultant for the Adatum Corporation performing a data migration for a bank. You need a
laptop to install and run the Microsoft Assessment and Planning Toolkit to perform an inventory of thier
network. However, you are not allowed to use your own laptop on thier network. You need to advise thier IT
department of the spec of machine to use to perform this activity. Which operation systems can you use to
perfrom the task?
 Windows 8.1 Professional Edition
 Windows 8.1 Enterprise Edition
 Windows Server 2016
 Windows 7 Professional
Question 2
You are a consultant for the Adatum Corporation performing a data migration for a bank. You have run the
Microsoft Assessment and Planning Toolkit to perform an inventory of thier network. The Data Engineer at
the bank has expressed concern over the accuracy of the report as some of the servers that deal with key
business process such as transaction management are not listed. From the available answers, which two are
the most likely explanation?
 The servers don't exist
 Remote Desktop Protocol is not enabled on those servers
 Remote administration is not enabled on those servers
 The Discovery method used does not include the servers.
Identify Migration candidates using Data Mi-

gration Assistant
Lesson 3: Identify Migration candidates using
Data Migration Assistant
In this lesson, you are introduced to Data Migration Assistant as a tool that can be used to support you in
your SQL Server Migration assessments, or with a SQL Server migration itself. You will learn the installa-
tion and configuration of the tool as well as the advanced settings that can be used to ensure that the
tool works optimally. You will see an example of how you can perform an assessment using the tool and
the best practices to follow when you use it.
Learning objectives
● What is the Data Migration Assistant?
● Data Migration Assistant Configuration
● Using the Data Migration Assistant
● Data Migration Assistant Best Practices
Microsoft Data Migration Assistant

The Data Migration Assistant helps you upgrade to a modern data platform by detecting compatibility
issues that can impact database functionality in your new version of SQL Server or Azure SQL Database.
DMA recommends performance and reliability improvements for your target environment and allows you
to move your schema, data, and objects from your source server to your target server.
Identify Migration candidates using Data Migration Assistant 43
This tool can be helpful to you in identifying any issues that can affect a migration to an Azure SQL data
platform. The DMA can run assessment projects that will identify any blocking issues or unsupported
features that are currently in use with your on-premises SQL Server. It can also help you understand the
new features in the target SQL Server platform that the database can benefit from after a migration. The
DMA can also perform migration projects that can migrate an on-premises SQL Server instance to a
modern SQL Server instance hosted on-premises or on an Azure virtual machine (VM) that is accessible
from your on-premises network.
The Data Migration Assistant replaces all previous versions of SQL Server Upgrade Advisor and should be
used for upgrades for most SQL Server versions.
Supported SQL Source and Targets

The Data Migration Assistant supports the following source and target technlogies
Sources
● SQL Server 2005
● SQL Server 2008
● SQL Server 2008 R2
● SQL Server 2012
● SQL Server 2014
● SQL Server 2016
● SQL Server 2017 on Windows
Targets
● SQL Server 2012
● SQL Server 2014

● SQL Server 2016
● SQL Server 2017 on Windows and Linux
● Azure SQL Database Managed Instance
Note.: The tool recommends that migrations to Azure SQL Database or Azure SQL Database Managed
Instance should be performed by the Azure Migration Service. The Data Migration Assistant is ideal for
migrations to SQL Server on Virtual Machines
Microsoft Data Migration Assistant Configura-

tion
In order to run the Data Migration Assistant you need to be a member of the SQL Server sysadmins role
on the source server. You can download the Data Migration Assistant from the Microsoft Download
Center3, this will download a file named DataMigrationAssistant.msi file.
Double clicking on this file starts the Data Migration Assistant setup which is relatively straightforward.
Click on Next on the Welcome screen
3 https://www.microsoft.com/en-us/download/details.aspx?id=53595
You then accept the license agreement

You then accept the Privacy statement

and then click on Install to complete the installation. Optionally you can select the Launch the Data
Migration Assistant on completion to launch the tool at the end of the installation
Advanced Configuration
You can fine-tune certain behavior of Data Migration Assistant by setting configuration values in the dma.
exe.config file. This file can be found in the following folders:
● Desktop Application
● %ProgramFiles%\Microsoft Data Migration Assistant\dma.exe.config
● Command-Line Utility
● %ProgramFiles%\Microsoft Data Migration Assistant\dmacmd.exe.config
The additional settings that can be configured in the dma.exe.config file include:
Number of databases to assess in parallel

The default value is 8. During the assessment, the Data Migration Assistant extracts data-tier application
(dacpac) to understand the database schema. This operation can time out if several databases on the
same server are assessed in parallel. You can modify this value to reduce the number of databases with
the following JSON code:
<advisorGroup>
<workflowSettings>
<assessment parallelDatabases="8" />
</workflowSettings>
</advisorGroup>
Number of databases to migrate in parallel

Data Migration Assistant migrates multiple databases in parallel, before migrating logins. During migra-
tion, Data Migration Assistant will take a backup of the source database, optionally copy the backup, and
then restore it on the target server. You may encounter timeout failures when several databases are
selected for migration. You can modify this value to reduce the number of databases with the following
JSON code:
<advisorGroup>
<workflowSettings>
<migration parallelDatabases="8″ />
</workflowSettings>
</advisorGroup>
SQL connection timeout

You can control the SQL connection time-out for source and target instances while running an assess-
ment or migration, by setting the connection timeout value to a specified number of seconds. The default
value is 15 seconds.
<appSettings>
<add key="ConnectionTimeout" value="15" />
</appSettings>
Using the Data Migration Assistant.

On completion of the installation, the Data Migration Assistant opens. The first step is to configure the
type of project that you want to run. There are two choices:
1. Assessment Projects.
2. In this configuration, the Data Migration Assistant will identify any blocking issues or unsupported
features that are currently in use with your on-premises SQL Server.
3.
4. You can then define setting for your assessment project to check database compatibility or feature
parity
5.
6. Set the source database that you would like to perform the check against, and then start the assess-
ment
7.
8. and then review the results, either in the tool, or exported into a JSON file for later review
9.
10. Migration Projects.
11. In this configuration, the Data Migration Assistant will migrate the data, schema, or both to the target
services defined in the settings.
12.
13. Note. Migration projects using the Data Migration Assistant will be covered in a later module
Best practices for running Data Migration Assis-

tant
The following list outlines the best practices that you should consider when working with the Data
Migration Assistant:
● Don't install and run the Data Migration Assistant directly on the SQL Server host machine.
● Run assessments on production databases during non-peak times.
● Perform the Compatibility issues and New feature recommendations assessments separately to reduce
the assessment duration.
● Migrate a server during non-peak times.
● When migrating a database, provide a single share location accessible by the source server and the
target server, and avoid a copy operation if possible. A copy operation may introduce delay based on
the size of the backup file. The copy operation also increases the chances that a migration will fail
because of an extra step. When a single location is provided, Data Migration Assistant bypasses the
copy operation.
● Be sure that to provide the correct permissions to the shared folder to avoid migration failures. The
correct permissions are specified in the tool. If a SQL Server instance runs under Network Service
credentials, give the correct permissions on the shared folder to the machine account for the SQL
Server instance.
● Enable encrypt connection when connecting to the source and target servers. Using SSL encryption
increases the security of data transmitted across the networks between Data Migration Assistant and
the SQL Server instance, which is beneficial especially when migrating SQL logins. If SSL encryption
isn't used and the network is compromised by an attacker, the SQL logins being migrated could get
intercepted and/or modified on-the-fly by the attacker.
Lesson Summary
In this lesson, you have learned about the Data Migration Assistant and how it can be used to support
you in your SQL Server Migration assessments, or with a SQL Server migration itself. You learned the
installation and configuration of the tool as well as the advanced settings that and you saw an example of
how you can perform an assessment using the tool and the best practices to follow when using it.
Learning objectives
● What is the Data Migration Assistant?
● Data Migration Assistant Configuration
● Using the Data Migration Assistant
● Data Migration Assistant Best Practices
Important
Knowledge Check
Question 1
You are performing an assessment of an on-premises SQL Server that contains over 40 databases. You
decide to use the Data Migration Assistant, but as you perform the assesment you recieve timeout errors.
What should you do to attempt to resolve this issue?
 Stop the on-premises SQL Server instance
 In the dma.exe.config file, change the element "assessment parallelDatabases" from 8 to 1
 In the dma.config file, change the element "assessment parallelDatabases" from 8 to 1
 In the dma.exe.config file, change the element "migrate parallelDatabases" from 8 to 1
Question 2
You are running the DAta Migration Assistant on your laptop, and set the source to a on-premises SQL
Server that you have been asked to assess. You recieve a message stating that you sont have the permission
to run the tool against the server. Which role should you be a member of on the SQL Server that you are
assessing?
 Sysadmin
 db_datareader
 SecurityAdmin
 Backup_Operator
Evaluate Data workload using Database Experimentation Assistant 55
Evaluate Data workload using Database Exper-

imentation Assistant
Lesson 4: Database Experimentation Assistant
In this lesson, you will be shown how you can take the workloads that are generated on your production
servers and test them against the target servers that you are migrating to. This provides you with the
opportunity to see if what performance improvements will be gained by migrating to a target server, as
well as seeing which of your production queries will have issues
Learning objectives
● What is Database Experimentation Assistant
● How to configure the Database Experimentation Assistant
● How to use the Database Experimentation Assistant
● How to analyze the Database Experimentation results
Database Experimentation Assistant (DEA)

The Database Experimentation Assistant is an experimentation tool for SQL Server upgrades. It can help
you evaluate a targeted version of SQL Server for a specific workload. Customers who are upgrading from
earlier SQL Server versions (starting with 2005) to a more recent version of SQL Server; both on-premises
or SQL Server on Azure Virtual Machines, can use the analysis metrics to give comparison data to allow
you to make decisions on whether the targeted version would provide a better experience after a
migration.
You would use the DEA to test your real workloads before a migration. This is different to the Data
Migration Assistant as this only does static code analysis, DEA provides you with the opportunity to test
your real world workloads against a newer platform prior ro performing the migration so you can get
metrics on how your code will perfrom on a newer version of a data platform technology.
The metrics that the Database Experimentation Assistant provide includes:
● Queries that have compatability errors
● Degraded queries and query plans
● Other comparison data
Database Experimentation Assistant Architecture and

Workflow
The architecture for the Database Experimentation Assistant is setup in such a way so that A/B testing can
be performed between the source system and the target system. A being an the current SQL Server
instance that you have, and B being the target SQL Server to migrate to.
You capture trace information in the Source SQL Server instance, this ensure that there is no unnecessary
performance overheasd on the production server. and then replay the trace files in a test environment
using Distributed Replay. The graphic below shows one test environment containing SQL Server 2008,
and another instance containing the target environment of SQL Server 2016. Once the replay of the trace
files is complete, the Database Experimentation Assistant analyzes the results of the replay, and performs
a comparison of the A/B environments. The comparison results are displayed in Database Experimenta-
tion Assistant.
The hardware configurations of each test environment should be as similar as possible so SQL Server can
accurately analyze the performance effect of your proposed changes.
As a result, the three high level tasks that you perform in the Database Experimentation Assistant:
1. Capture Workloads
2. Capture trace file information from a production server to capture real world workloads.
3. Replay Workloads
4. Replay the captured trace files against a source and target server to generated information against
each version.
5. Analyze Workloads
6. View the results so that a workload performance comparison can be made between the source adn
target workloads
Configuring the Database Experimentation As-

sistant
In order for the Database Experimentation Assistant to run successfully, it does rely on minimum specs
for the machine that it will be running on. In addition, it also relies on there being a Distributed Relay
infrastructure being in place to perform the experimentation. More information can be found on Micro-
soft Docs4 about this feature. As a result, the setup and configuration of the the Database Experimenta-
tion Assistant requires some work.
Pre-requisites
The following are prerequisites for running the Database Experimentation Assistant and the supporting
infrastructure:
● Minimum hardware requirement for the DEA tool is a single-core machine with 3.5 GB of RAM.
4 https://docs.microsoft.com/en-us/sql/tools/distributed-replay/sql-server-distributed-replay?view=sql-server-2017
● An additional 33% of performance trace size is needed to store A, B, and report analysis databases.
● Windows authentication is required between all the servers taking part in the DEA including the server
that will be analyzed (source, target and analysis server), and the servers running the Distributes Relay
infrastructure.
● The user running DEA must have sysadmin rights on the source and target database server
● the service account running the source and target database server must have write access to the trace
folder path.
● DEA communicates with the Distributed Replay controller by using COM interfaces. Make sure that
TCP ports are opened for incoming requests on the Distributed Replay controller.
● recommend that you install DEA on the same machine as the Distributed Replay controller.
Note: DEA has an internet-enabled feature that can send telemetry information to Microsoft. Telemetry is
optional and must be configured. Should you choose to use this and you can always see what's collected.
All log files from DEA are saved in the %temp%\DEA folder.
Installing the Database Experimentation Assistant

To install DEA is a very simple installation, download the latest version of the tool. Then, run the Databa-
seExperimentationAssistant.exe file.
In the Database Experimentation Assistant screen, click I accept the agreement, and click on Install.
The Database Experimentation Assistant will install,
and then complete.

Working with the Database Experimentation As-

sistant
There are three high level tasks that you perform in the Database Experimentation Assistant:
1. Capture Workloads
2. Here, you point the Database Experimentation Assistant to the production server where you want to
collect the tracefile information. You specify the SQL Server connection details and can control the
settings for how the trace capture details. Below are the detailed steps
● In DEA, go to All Captures by selecting the camera icon in the left menu.
●
● Enter or select the following information:

● Trace name: The file name for the new trace file you're creating. Avoid a trace name that uses
the rollover file naming convention, for example, CaptureName_NNN.
● Duration: The duration for the capture.
● SQL Server instance name: The SQL Server instance from which you want to capture a trace.
● Database name: The name of the database on the computer running SQL Server that you want
capture a trace of. If left blank, trace is captured from all databases on the server.
● Path to store source trace file on SQL Server machine: The folder path where you want to
save the trace file.
● Make sure that the target database is backed up. Then, select the database check box.
● Select Start to start the capture.
●
3. Replay Workloads
4. Here you will define the setup of the Distributed Replay infrastructure that you have in place and that
is required to run the environment. You then select the trace file that you want to replay, as well as the
location to store the replay preprocessing output. Finally, you specify the test instance you want to
run the trace against. In the DEA UI this can only be done one instance at a time. The cmd line tool
can run multiple instances in parallel.
● In DEA, select the play icon in the left menu to go to All Replays. The list of past replays that run
during the session, if any, appear. To start a new replay, select New Replay.
● Enter or select the following information:
● Replay name: The file name for the replay trace.
● Controller machine name: The name of the Distributed Replay controller machine.
● Path to source trace file on controller: The file path for the source trace file from Capture.
● SQL Server instance name: The name of the SQL Server instance on which to replay the
source trace.
● Path to store target trace file on SQL Server machine: The folder path for the resulting
replay trace file.
● Select the check box to restore the backup from the first step.
● Select Start to start the replay.
●
5. Analyze Workloads
6. Once the replay is completed, you can review the results in the Database Experimentation Assistant by
creating a new analysis report and pointing to each of the trace files generated for the source and
target server. You also specify a server name that would host the reports.To generate an analysis
report:
● In the left menu, go to Analysis Reports. Connect to the computer running SQL Server where you
store your report databases. A list of all reports in the server appears. To create a new report, select
New Report.
● Enter or select the information that's required to generate a report:
● Report name: The name of the analysis report to create.
● Trace for Target 1 SQL Server: The path for the trace file from replaying on Target 1.
● Trace for Target 2 SQL Server: The path for the trace file from replaying on Target 2.
● Select Start to generate the report. The new report appears at the top of the list. The icon next to
the report becomes a green checkmark when the report has been generated.
Analyzing the Database Experimentation Assis-

tant Output
Once the Database Experimentation Assistant has performed its analysis, you are able to view comparison
data within the tool itself, or you can export the results for later view. You are first provided with a
summary of the version of the servers that have been part of the A/B analysis.
You can use threshold to adjust the sensitivity or tolerance of your A/B Test analysis. By default, the
threshold is set at 5%. Any improvement in performance that is more than or equal to 5% is categorized
as Improved. Select options in the drop-down menu to evaluate the report by using different perfor-
mance thresholds.
Once the threshold has been defined, then you can explore the following reports:.
Query workload and query distribution reports

Presented as pie charts, they represent the performance metrics between the two servers based on the
workload that has been provided.
Five categories of results are provided which are:

● Improved: Statistically, the query ran better on Target 2 than on Target 1.
● Degraded: Statistically, the query ran worse on Target 2 than on Target 1.
● Same: There's no statistical difference for the query between Target 1 and Target 2.
● Cannot Evaluate: The sample size for the query is too small for statistical analysis. For A/B testing
analysis, DEA requires the same queries to have at least 30 executions on each target.
● Error: The query errored out at least once on one of the targets.
You can click on a slice of the pie chart to get more detailed information. For example, click in the errors
slide will provide the following visuals
and click on another slice to see the specific queries that make up the analysis. For example, clicking on
the **New Errors"" slice will return the following information.
Comparison Summary
When you view a specific query in the reports as described above, you can drill down into information
that provides a more detailed comparison of the performance of the query on the source and target
server.
The Comparison Summary page shows summary statistics for that query and includes the number of
executions, mean duration, mean CPU, mean reads/writes, and error count. If the query is an error query,
the Error Information tab shows more information about the error. The Query Plan Information tab shows
information about the query plans that are used for the query on Target 1 and Target 2.
Lesson Summary
In this lesson, you have learned how you can take the workloads that are generated on your production
servers and test them against the target servers that you are migrating to using the Database Experimen-
tation Assistant.
Learning objectives
● What is Database Experimentation Assistant
● How to configure the Database Experimentation Assistant
● How to use the Database Experimentation Assistant
● How to analyze the Database Experimentation results
Important
Knowledge Check
Question 1
You are wanting to use the Database Experimentation Assistant to test the queries that are running against
your SQL Server 2012 Enterprise Edition, against a SQL Server 2016 Enterprise Edition that is running on an
Azure Virtual Machine. The SQL Server 2012 server Enterprise Edition is configured with SQL Server Authen-
tication, and SQL Server 2016 Enterprise Edition is configured with Mixed Mode Authentication. Will the
Database Experimentation Assistant execute successfully?
 No
 Yes
Question 2
You can only use trace files generated by the Database Experimentation Assistant to perform an analysis of
your servers? True or False?
 True
 False
Migrate non SQL Server workloads using SQL

Server Migration Assistant
Lesson 1: Data Platform Modernization
In this lesson, you are introduced to the high level steps required to migrate non SQL Server workloads
from products such as MySQL and Oracle, and how the SQL Server Migration Assistant can be installed to
help with the automation of these types of migrations.
Learning objectives
● What is the SQL Server Migration Assistant
● Using the SQL Server Migration Assistant (SSMA) for Oracle
● Using the SQL Server Migration Assistant (SSMA) for MySQL
SQL Server Migration Assistant

If you are looking to automate database migrations to SQL Server or Azure from Microsoft Access, DB2,
MySQL, Oracle, and SAP ASE then the SQL Server Migration Assistant is the tool to use. It can support
source versions of on-premises SQL Server from 2008 onwards runinng on either Windows or Linux.
There are seperate downloads of the tool depending on the targer that you are migrating to. From an Az-
ure perspective, the target service that are support are Azure SQL Database and Azure SQL Database
Managed Instance. However you can use the SQL Server Migration Assistant for Oracle to migrate to
Azure SQL Data Warehouse as well.
Using the SQL Server Migration Assistant

(SSMA) for Oracle
SSMA for Oracle converts Oracle database objects to SQL Server database objects, creates those objects
in SQL Server, and then migrates data from Oracle to SQL Server. SQL Server Migration Assistant (SSMA)
for Oracle consists of a client application that you use to perform a migration from Oracle to SQL Server
and Azure SQL DB. It also contains an extension pack that supports data migration and the use of Oracle
system functions in your migrated databases. You install the client application on the computer from
which you will perform the migration steps. You must install the extension pack files on the computer
where the migrated databases will be hosted. That computer must be running SQL Server.
Installation
SSMA for Oracle is designed to work with Oracle 9 or later versions and all editions of SQL Server. Before
you install SSMA, make sure that the computer meets the following requirements:
● Windows 7 or later versions, or Windows Server 2008 or later versions.
● Microsoft Windows Installer 3.1 or a later version.
● The Microsoft .NET Framework version 4.0 or a later version. The .NET Framework version 4.0 is
available on the SQL Server product media. You can also obtain it from the .NET Framework Developer
Center.
Migrate non SQL Server workloads using SQL Server Migration Assistant 67
● Oracle Client 9.0 or a later version, and connectivity to the Oracle databases that you want to migrate.
The Oracle client version must be the same version as, or a later version than, the Oracle database
version. You can install the Oracle Client from the Oracle product media or from the Oracle Web site.
For information about connectivity, see Connecting to Oracle Database (OracleToSQL).
● Access to and sufficient permissions on the computer that hosts the target instance of SQL Server or
Azure SQL DB where you will be migrating database objects and data. For more information, see
Connecting to SQL Server (OracleToSQL).
● 4 GB RAM recommended.
To install the SSMA client
1. Double-click SSMA for Oracle n.Install.exe, where n is the build number.
2. On the Welcome page, click Next.
If you do not have the prerequisites installed, a message will appear that indicates that you must first
install required components. Make sure that you have installed all prerequisites, and then run the
installation program again.
3. Read the End User License Agreement. If you agree, select I accept the terms in the license agreement,
and then click Next.
4. On the Choose Setup Type page, click Typical.
5. Click Install.
The default installation location is C:\Program Files\Microsoft SQL Server Migration Assistant for Oracle.
In addition to the SSMA program files, you must also install the SSMA for Oracle extension pack on SQL
Server.
Performing the Migration

To successfully migrate objects and data from Oracle databases to SQL Server, Azure SQL DB, or Azure
SQL Data Warehouse, use the following process:
1. Create a new SSMA project.
2. After you create the project, you can set project conversion, migration, and type mapping options. For
information about project settings, see Setting Project Options (OracleToSQL). For information about
how to customize data type mappings, see Mapping Oracle and SQL Server Data Types (OracleToSQL).
3. Connect to the Oracle database server.
4. Connect to an instance of SQL Server.
5. Map Oracle database schemas to SQL Server database schemas.
6. Optionally, Create assessment reports to assess database objects for conversion and estimate the
conversion time.
7. Convert Oracle database schemas into SQL Server schemas.
8. Load the converted database objects into SQL Server.
You can do this in one of the following ways:
● Save a script and run it in SQL Server.
● Synchronize the database objects.
9. Migrate data to SQL Server.
10. If necessary, update database applications.
Full details on how to migrate can be found at the following web location5
Using the SQL Server Migration Assistant

(SSMA) for MySQL
At the time of writing the SQL Server Migration Assistant for MySQL V8.0 introduced the capability to
migrate to Azure SQL Database Managed Instance as well as Azure SQL Database as a target, providing
more flexibility from the tool. SQL Server Migration Assistant (SSMA) for MySQL consists of a client
application that you use to perform a migration from MySQL to SQL Server or SQL Azure. It also contains
an extension pack that supports data migration and the use of MySQL system functions in your migrated
databases. Install the client application on the computer from which you will perform the migration steps.
You must install the extension pack files on the computer where the migrated databases will be hosted.
That computer must be running SQL Server.
Installation
1. Go to https://aka.ms/ssmaformysql
2. Confirm that your environment supports the software by checking the required System Requirements.
3. Download SSMAforMySQL_x.x.x.msi which is the 64 bit version of the SQL Server Migration Assis-
tant for MySQL. If appropriate download the 32 bit version indicated by the x86 file name.
4. Double-Click the installer SSMAforMySQL_x.x.x.msi.
5. Click Next on the Welcome screen.
6. Read the User License Agreement and accept if appropriate and then click Next.
7. Choose Setup Type by selecting Complete
8. Click if required sending Telemetry and checking for newer versions and then click Install.
9. If prompted allow UAC control for this application. Complete install by clicking Finish.
After SSMA is installed and licensed, you can use SSMA to migrate MySQL databases to SQL Server or
Azure SQL DB. It helps to become familiar with the SSMA user interface before you start.
To start a migration, you must:
● Create a new project.
● Connect to a MySQL database.
● After a successful connection, MySQL schemas will appear in SQL Server Migration Assistant for
MySQL ready for conversions to SQL Server/Azure SQL DB.
Note: Course DP-160T00 explores Migrating from MySQL to SQL Server in more depth
Lesson Summary
In this lesson, you are provided with the high level steps required to migrate non SQL Server workloads
from products such as MySQL and Oracle. You have seen how to install SQL Server Migration Assistant to
help with the automation of these types of migrations.
5 https://docs.microsoft.com/en-us/sql/ssma/oracle/migrating-oracle-databases-to-sql-server-oracletosql?view=sql-server-2017
Migrate non SQL Server workloads using SQL Server Migration Assistant 69
Learning objectives
● What is the SQL Server Migration Assistant
● Using the SQL Server Migration Assistant (SSMA) for Oracle
● Using the SQL Server Migration Assistant (SSMA) for MySQL
Important
Knowledge Check
Question 1
Which of the following Azure Data Platform technologies can't be used by the SQL Server Migration Assis-
tant to automate the migration from MySQL?
 Azure SQL Database Managed Instance
 All of the above
Data migration using Azure Database Migra-

tion Service
Lesson 6: Database Migration Service
In this lesson, you are introduced to the Database Migration Service that is a service that can be created
in Azure to manage large scale migrations from on-premises servers to Azure. You will also learn the
prerequisites setup and how to Create the Database Migration Service. Finall, you will learn the difference
between the Database Migration Service and Azure Migrate to resolve any confusion that may surround
the differences between each service.
Learning objectives
● What is Database Migration Service
● The prerequisites setup for the Database Migration Service
● Creating the Database Migration Service
● What is Azure Migrate
What is the Azure Database Migrate Service

The Azure Database Migrate Service enables you to perform large scale database migration from within
the Azure Portal. Azure Database Migration Service integrates some of the functionality of existing tools
and services to provide customers with a comprehensive, highly available solution. The tools include:
● Database Migration Assistant
● SQL Server Migration Assistant
● Data Experimentation Assistant
This enable you to streamline the process of database migrations and have a single place to efficiently
manage the execution of a Data Platform Modernization projects. Additionally, you can use the Database
Migrate Service to perform source and destination testing to perform validation testing after the migra-
tion. It also supports a wide range of data sources that include:
● SQL Server
● MySQL
● Oracle
● DB2
● MongoDB
● PostgreSQL
But perhaps the biggest benefit to this service, is its ability to provide near zero downtime on the data
sources that enable live database migrations. This enables you to speed up the database migration
process with minimal disruption. Although you also have the ability to perform offline migrations if you
so wish.
Data migration using Azure Database Migration Service 71
Note: Using Azure Database Migration Service to perform an online migration requires creating an
instance based on the Premium pricing tier.
Prerequisites for using the Azure Database Mi-

gration Service
The Azure Database Migration service uses many tools in order to streamline data migrations. There are
several prerequisites required to ensure that the Azure Database Migration Service runs smoothly. Due to
range of data source and targets that are supported, there are some prerequisites that apply to all
scenarios (source-target pairs) supported by the service, while other prerequisites are unique to a specific
scenario.
Common prerequisites
Azure Database Migration Service prerequisites that are common across all supported migration scenari-
os include the need to:
● Ensure the the TCP/IP protocol is enabled in SQL Server
● Configure your Windows Firewall for database engine access.
● When using a firewall appliance in front of your source databases, add firewall rules to allow Azure
Database Migration Service to access the source database for migration.
● Create an Azure Virtual Network (VNet) for Azure Database Migration Service by using the Azure
Resource Manager deployment model. It provides site-to-site connectivity to your on-premises source
servers by using either ExpressRoute or VPN
● Ensure that your VNet Network Security Group (NSG) rules don't block the following communication
ports 443, 53, 9354, 445, 12000.
Prerequisites for migrating SQL Server to an Azure SQL

Database Managed Instance
● You should create an Azure SQL Database managed instance by following the detail in the article
Create an Azure SQL Database Managed Instance in the Azure portal6.
● Open your firewalls to allow SMB traffic on port 445 for the Azure Database Migration Service IP
address or subnet range.
● Open your Windows Firewall to allow the Azure Database Migration Service to access the source SQL
Server, which by default is TCP port 1433.
● If you are running multiple named SQL Server instances using dynamic ports, you may wish to enable
the SQL Browser Service and allow access to UDP port 1434 through your firewalls so that the Azure
Database Migration Service can connect to a named instance on your source server.
● Ensure that the logins used to connect the source SQL Server and target Managed Instance are
members of the sysadmin server role.
● Create a network share that the Azure Database Migration Service can use to back up the source
database.
● Ensure that the service account running the source SQL Server instance has write privileges on the
network share that you created.
● Ensure that the computer account for the source server has read/write access to the same share.
● Make a note of a Windows user (and password) that has full control privilege on the network share
that you previously created. The Azure Database Migration Service impersonates the user credential
to upload the backup files to Azure storage container for restore operation.
● Create a blob container and retrieve its Shared Access Signature URI (SAS URI) and select all permis-
sions (Read, Write, Delete, List) on the policy window while creating the SAS URI.
Important
Creating an instance of Azure Database Migration Service requires access to VNet settings that are
normally not within the same resource group. As a result, the user creating an instance of DMS requires
permission at subscription level. To create the required roles, which you can assign as needed, run the
following script:
$readerActions = `
"Microsoft.DataMigration/services/*/read", `
"Microsoft.Network/networkInterfaces/ipConfigurations/read"
$writerActions = `
"Microsoft.DataMigration/services/*/write", `
"Microsoft.DataMigration/services/*/delete", `
"Microsoft.DataMigration/services/*/action"
$writerActions += $readerActions
$subScopes = ,"/subscriptions/00000000-0000-0000-0000-000000000000/","/
subscriptions/11111111-1111-1111-1111-111111111111/"
function New-DmsReaderRole() {
6 https://docs.microsoft.com/en-gb/azure/sql-database/sql-database-managed-instance-get-started
$aRole = [Microsoft.Azure.Commands.Resources.Models.Authorization.PSRole-
Definition]::new()
$aRole.Name = "Azure Database Migration Reader"
$aRole.Description = "Lets you perform read only actions on DMS service/
project/tasks."
$aRole.IsCustom = $true
$aRole.Actions = $readerActions
$aRole.NotActions = @()
$aRole.AssignableScopes = $subScopes
#Create the role
New-AzRoleDefinition -Role $aRole

}
function New-DmsContributorRole() {
$aRole = [Microsoft.Azure.Commands.Resources.Models.Authorization.PSRole-
Definition]::new()
$aRole.Name = "Azure Database Migration Contributor"
$aRole.Description = "Lets you perform CRUD actions on DMS service/project/
tasks."
$aRole.IsCustom = $true
$aRole.Actions = $writerActions
$aRole.AssignableScopes = $subScopes
#Create the role
New-AzRoleDefinition -Role $aRole

}
function Update-DmsReaderRole() {
$aRole = Get-AzRoleDefinition "Azure Database Migration Reader"
$aRole.Actions = $readerActions
Set-AzRoleDefinition -Role $aRole
}
function Update-DmsConributorRole() {
$aRole = Get-AzRoleDefinition "Azure Database Migration Contributor"
$aRole.Actions = $writerActions
Set-AzRoleDefinition -Role $aRole
}
Invoke above functions

New-DmsReaderRole
New-DmsContributorRole
Update-DmsReaderRole
Update-DmsConributorRole
Create an instance of the Azure Database Migra-

tion Service
You use the Azure portal to create an instance of the Azure Database Migration Service. Once coomplet-
ed, you can use it to migrate data from SQL Server on-premises to an Azure SQL database.
Register the Microsoft.DataMigration resource provider

1. Open your web browser, navigate to the Microsoft Azure portal7, and then enter your credentials to
sign in to the portal.
2. In the Azure portal, select All services, and then select Subscriptions.
3. Select the subscription in which you want to create the instance of the Azure Database Migration
Service, and then select Resource providers.
4. Search for migration, and then to the right of Microsoft.DataMigration, select Register.
1. Select +Create a resource to create an instance of the Azure Database Migration Service.
2. Search the marketplace for “migration”, select Azure Database Migration Service, and then on the
Azure Database Migration Service screen, select Create.
7 https://portal.azure.com/
3. On the Create Migration Service screen:
● Choose a Service Name that is memorable and unique to identify your instance of the Azure
Database Migration Service.
● Select the Azure Subscription in which you want to create the instance.
● Select an existing Resource Group or create a new one.
● Choose the Location that is closest to your source or target server.
● Select an existing Virtual network (VNET) or create one.
The VNET provides the Azure Database Migration Service with access to the source database and
target environment.
● Select Basic: 1 vCore for the Pricing tier.
4. Click Create
Note: You will perform use the Database Migration Service to perform an actual Migration in a later mod-
ule
What is the Azure Migrate Service

The Azure Migrate Service is often confused as a tool that is the same the Azure Database Migration
Service, but they are not. It can be used for migrations to Azure SQL Server Virtual Machines, and it can
provide the following abilities:
1. Assess Azure readiness: Assess whether your on-premises machines are suitable for running in Azure.
2. Get size recommendations: Get size recommendations for Azure VMs based on the performance his-
tory of on-premises VMs.
3. Estimate monthly costs: Get estimated costs for running on-premises machines in Azure.
4. Migrate with high confidence: Visualize dependencies of on-premises machines to create groups of
machines that you will assess and migrate together.
However the source system that it supports is limited to on-premises VMware virtual machines (VMs)
managed by vCenter Server version 5.5 or above for migration to Azure VMs. Hyper-V is currently in
preview with production support and you must use other tools for physical servers. In addition, Azure
Migrate only supports managed disks for migration assessment.
Azure Migrate Assessments

You can use the Azure Migrate Service to perform assessment of source systems and the assessment
settings can be customized by changing the following properties:
Property Details
Target location The Azure location to which you want to migrate
Storage type The type of managed disks you want to allocate
for all VMs that are part of the assessment. If the
sizing criterion is as on-premises sizing you can
specify the target disk type either as premium
disks (the default), standard SSD disks or standard
HDD disks. For performance-based sizing, along
with the above options, you also have the option
to select Automatic which will ensure that the disk
sizing recommendation is automatically done
based on the performance data of the VMs. For
example, if you want to achieve a single instance
VM SLA of 99.9%, you may want to specify the
storage type as Premium managed disks which will
ensure that all disks in the assessment will be
recommended as Premium managed disks. Note
that Azure Migrate only supports managed disks
for migration assessment.
Reserved Instances Whether you have reserved instances in Azure.
Azure Migrate estimates the cost accordingly.
Sizing criterion Sizing can be based on performance history of the
on-premises VMs (the default), or as on-premises,
without considering performance history.
Property Details
Performance history By default, Azure Migrate evaluates the perfor-
mance of on-premises machines using perfor-
mance history for the last day, with a 95% percen-
tile value.
Comfort factor Azure Migrate considers a buffer (comfort factor)
during assessment. This buffer is applied on top of
machine utilization data for VMs (CPU, memory,
disk, and network). The comfort factor accounts
for issues such as seasonal usage, short perfor-
mance history, and likely increases in future usage.
For example, a 10-core VM with 20% utilization
normally results in a 2-core VM. However, with a
comfort factor of 2.0x, the result is a 4-core VM
instead. The default comfort setting is 1.3x.
VM series The VM series used for size estimations. For
example, if you have a production environment
that you do not plan to migrate to A-series VMs in
Azure, you can exclude A-series from the list or
series. Sizing is based on the selected series only.
Currency Billing currency. Default is US dollars.
Discount (%) Any subscription-specific discount you receive on
top of the Azure offer. The default setting is 0%.
VM uptime If your VMs are not going to be running 24x7 in
Azure, you can specify the duration (number of
days per month and number of hours per day) for
which they would be running and the cost estima-
tions will be done accordingly. The default value is
31 days per month and 24 hours per day.
Azure offer The Azure offer you're enrolled to. Azure Migrate
estimates the cost accordingly.
Azure Hybrid Benefit Whether you have software assurance and are
eligible for Azure Hybrid Benefit with discounted
costs.
Azure Migrate Migrations

You can also use the Azure Migrate Service to perform the actual migration from VMware virtual ma-
chines using the following tools:
● Azure Database Migration: for on-premises machines SQL Server, MySQL, or Oracle, you can use the
Azure Database Migration Service to migrate them to Azure.
● Azure Site Recovery: You can use Azure Site Recovery to migrate to Azure. To do this, you prepare
the Azure components you need, including a storage account and virtual network. On-premises, you
prepare your VMware environment. When everything's prepared, you set up and enable replication to
Azure, and migrate the VMs.
Lesson Summary
In this lesson, you have learned about the Database Migration Service and how it can be used to manage
large scale migrations from on-premises servers to Azure. You also learned the prerequisites setup and
how to Create the Database Migration Service. You also learned the difference between the Database
Migration Service and Azure Migrate to resolve any confusion that may surround the differences between
each service.
Learning objectives
● What is Database Migration Service
● The prerequisites setup for the Database Migration Service
● What is Azure Migrate
Important
Knowledge Check
Question 1
You are using the Azure Database Migration Service to migrate databases from SQL Server 2014 SP3 in
Azure SQL DAtabase Managed Instance. Whilst running the assessment on Azure Database Migration
Service you recieve the following error from SQL Server Error: 40 – could not open a connection to SQL
server. What should you check on the SQL Server 2014 instance:
 Ensure the TCP/IP protocol is enabled in SQL Server
 Ensure the Windows Firewall for database engine access.
 Ensure any firewall appliance in front of your source databases has the correct firewall rule
Question 2
You are a database adminstrator for Adventureworks and you manage over 200 SQL Servers hosted on
VMWare. You manage the VMWare estate managed by vCenter Server version 6.5 and want to migrate to
Azure SQL Server Virtual Machines. Which tool would enable you to perform this?
 Database Migration Assistant
 Azure Migrate Service
 SQL Server Migration Assistant
Module summary
Module Summary
In this module, you have been introduced to the Data Migration Guide as a starting point for the source
of information that your organization should use for step by step guidance for modernizing your existing
data platform. You then learned the value of the Microsoft Assessment and Planning Toolkit to help
discover the data assets that currently exist in your environment.
You then explored the tools that can be used to help you to assess for compatibility or workload issues
using both the Data Migration and Data Experimentation Assistant. Then an overview of the SQL Server
Migration Assistant was provided to show student how to migrate no-SQL Server workloads. Finally, you
saw how the Azure Database Migration Service can be used to aid online migration of databases to
reduce the amount of downtime.
Learning objectives
In this module, you have learned how to:
● Discover the Database Migration Guide
● Build your data estate inventory using Map Toolkit
● Identify Migration candidates using Data Migration Assistant
● Evaluate Data workload using Database Experimentation Assistant
● Migrate non-SQL Server workloads using SQL Server Migration Assistant
● Data Migration using Azure Database Migration Service
Module summary 81
Answers
Question 1
Which of the following Data Platform technologies cannot be migrated to Azure Cosmos DB
 Cassandra
■ SAP ASE
 Microsoft Azure Table Storage
 MongoDB
Explanation
Cassandra, MongoDB and Microsoft Azure Table Storage are all NOSQL data stores that can be migrated to
Azure Cosmos DB. SAP ASE is a relational data store, previously known as Sybase SQL that cannot be
migrated to Azure Cosmos DB
Question 2
Which tool would you use to aid you with the discovery of servers, thier specs and the services running
on the server?
■ Microsoft Assessment and Planning Toolkit
Explanation
he Microsoft Assessment and Planning Toolkit (MAPS) is a very useful that helps you to build an inventory
of the servers that you have on your network, the specs of the servers and the services that are running on
them.
Question 3
Which stage of the Data Platform Migration project does that answer to the previous question support?
■ Initiate and discovery stage
 Planning stage
Explanation
The Microsoft Assessment and Planning Toolkit (MAPS) is a very useful tool to use in the discovery stage of
a Data Platform Modernization project when you are wanting to understand the make-up of your current
environment.
Question 1
You are a consultant for the Adatum Corporation performing a data migration for a bank. You need a
laptop to install and run the Microsoft Assessment and Planning Toolkit to perform an inventory of thier
network. However, you are not allowed to use your own laptop on thier network. You need to advise thier
IT department of the spec of machine to use to perform this activity. Which operation systems can you
use to perfrom the task?
■ Windows 8.1 Professional Edition
■ Windows 8.1 Enterprise Edition
■ Windows Server 2016
 Windows 7 Professional
Explanation
The tool can be run on a PC on a wide range of operating systems from Windows 8.1 Professional and
Enterprise editions onwards. Therefore, Windows 7 Professional would not be supported.
Question 2
You are a consultant for the Adatum Corporation performing a data migration for a bank. You have run
the Microsoft Assessment and Planning Toolkit to perform an inventory of thier network. The Data
Engineer at the bank has expressed concern over the accuracy of the report as some of the servers that
deal with key business process such as transaction management are not listed. From the available
answers, which two are the most likely explanation?
 The servers don't exist
 Remote Desktop Protocol is not enabled on those servers
■ Remote administration is not enabled on those servers
■ The Discovery method used does not include the servers.
Explanation
Remote Administration must be enabled on servers in order for MAP to work successfully, if remote admin-
istration has been enabled, then it is possible that thediscovery method used may be a scope that does not
include those servers.
Question 1
You are performing an assessment of an on-premises SQL Server that contains over 40 databases. You
decide to use the Data Migration Assistant, but as you perform the assesment you recieve timeout errors.
What should you do to attempt to resolve this issue?
 Stop the on-premises SQL Server instance
■ In the dma.exe.config file, change the element "assessment parallelDatabases" from 8 to 1
 In the dma.config file, change the element "assessment parallelDatabases" from 8 to 1
 In the dma.exe.config file, change the element "migrate parallelDatabases" from 8 to 1
Module summary 83
Question 2
You are running the DAta Migration Assistant on your laptop, and set the source to a on-premises SQL
Server that you have been asked to assess. You recieve a message stating that you sont have the permis-
sion to run the tool against the server. Which role should you be a member of on the SQL Server that you
are assessing?
 Sysadmin
 db_datareader
■ SecurityAdmin
 Backup_Operator
Explanation
In order to use the Data Migration Assistant on an on-premises SQL Server, you need to be a member of the
Sysadmins role
Question 1
You are wanting to use the Database Experimentation Assistant to test the queries that are running
against your SQL Server 2012 Enterprise Edition, against a SQL Server 2016 Enterprise Edition that is
running on an Azure Virtual Machine. The SQL Server 2012 server Enterprise Edition is configured with
SQL Server Authentication, and SQL Server 2016 Enterprise Edition is configured with Mixed Mode
Authentication. Will the Database Experimentation Assistant execute successfully?
■ No
 Yes
Explanation
The Database Experimentation Assistant will not execute successfully as the source and target server should
be running WIndows Authentication
Question 2
You can only use trace files generated by the Database Experimentation Assistant to perform an analysis
of your servers? True or False?
 True
■ False
Explanation
This is false, you can use trace files that have been generated by the Database Experimentation Assistant or
you can use existing trace files that you have generated in the past
Question 1
Which of the following Azure Data Platform technologies can't be used by the SQL Server Migration
Assistant to automate the migration from MySQL?
 Azure SQL Database Managed Instance
■ Azure SQL Data Warehouse
Explanation
You cannot use the SQL Server Migration Assistant for MySQL to perform a migration to Azure SQL Data
Warehouse. This can only be performed using the SQL Server Migration Assistant for Oracle
Question 1
You are using the Azure Database Migration Service to migrate databases from SQL Server 2014 SP3 in
Azure SQL DAtabase Managed Instance. Whilst running the assessment on Azure Database Migration
Service you recieve the following error from SQL Server Error: 40 – could not open a connection to SQL
server. What should you check on the SQL Server 2014 instance:
 Ensure the TCP/IP protocol is enabled in SQL Server
 Ensure the Windows Firewall for database engine access.
 Ensure any firewall appliance in front of your source databases has the correct firewall rule
■ All of the above
Explanation
All of the answers outlined above could contribute to Error: 40 – could not open a connection to SQL server.
These are some the pre-requisites required to use the Azure Database Migration Service
Question 2
You are a database adminstrator for Adventureworks and you manage over 200 SQL Servers hosted on
VMWare. You manage the VMWare estate managed by vCenter Server version 6.5 and want to migrate to
Azure SQL Server Virtual Machines. Which tool would enable you to perform this?
 Database Migration Assistant
■ Azure Migrate Service
 SQL Server Migration Assistant
Explanation
The Azure Migrate Service enables you to migrate SQL Servers hosted on VMWare managed by vCenter
Server to Azure SQL Server Virtual Machines.
Module 3 Migrate SQL Workloads to Azure
Virtual Machines
Module introduction
Module Introduction
In this module, the student will learn how thet can migrate SQL Server workloads to SQL Server installa-
tions that are running on an Azure Virtual Machine. This Infrastructure as a Service approach has benefits
that you will learn, as well as the considerations that need to be taken into account when using this
approach. The students will then learn the various ways to migrate the SQL Server workloads both offline
and online, and then finish up with the post migration tasks that may have to be taken to ensure that the
migrated database performs appropriately.
Learning objectives
● Considerations for migrating to SQL Server on Azure Virtual Machines
● SQL Server workload to Azure Virtual Machine migration options
● Application configuration and optimization
MCT USE ONLY. STUDENT USE PROHIBITED 86 Module 3 Migrate SQL Workloads to Azure Virtual Machines
Considerations of migrating to SQL Server in

Azure Virtual Machines
Lesson 1: Considerations of Migrating to SQL
Server in Azure Virtual Machines
In this lesson, you will learn the specific benefits to migrating your SQL Server workloads to a SQL Server
that is hosted in an Azure Virtual Machine. You will then understand which tools you should use to help
get an understanding of your source and target server that are part of the migration. You will then look at
additional migration considerations that should be part of the planning process.
Learning objectives
● Understand the Migration Benefits to SQL Server
● Tools to support your migration planning
● Additional migration planning considerations
● Defining the migration approach
The Migration Benefits of SQL Server on Azure

Virtual Machines
Azure Virtual Machines is perhaps the technology from all of the data platform choices that is the most
understood by Data Engineers and Database Administrators alike. They are likely to have worked with
virtual machines on thier own infrastructures by using either Hyper-V or other vendors virtual machines.
As a result, migrating to this platform typically does not represent a steep learning curve for the individu-
al, but you get the benefits of automatic backups and updates that eases your administrative burden.
Using virtual machine allows you to have the full administrative control over the host operating system
and the SQL Server instance that is installed within it. However, this comes at a higher costs than other
data platform options, although there are a wide range of virtual machines configurations with different
compute, storage and management capabilities.
With Azure Virtual Machines you are not concerned with the phsical hardware configuration, and you are
able to configure and manage high availability, disaster recovery, and patching for SQL Server easier than
on-premises machines. In addition, it fully supports the following SQL Server components:
● SQL Server transactional replication
● AlwaysOn Availability Groups
● Integration Services
● Analysis Services
● Reporting Services
● Log Shipping
● SQL Server backup.
Considerations of migrating to SQL Server in Azure Virtual Machines 87
SQL Server on Azure virtual machines are optimized for migrating existing SQL Server applications, with
up to 64 TB of storage. All the versions and editions of SQL Server are available, and they offer 100%
compatibility with SQL Server, allowing you to host as many databases as needed and executing
cross-database transactions.
Tools to support you migration planning to SQL

Server on Azure Virtual Machines
The following tools should be used in the discovery, planning and assessment stage of your migration to
SQL Server on Azure Virtual Machines.
1. Microsoft Planning and Assessment
2. Use this tool in the discovery stage to confirm the source environment that you are migrating from.
This helps you to understand the configuration of your source SQL Server, how many instances are
installed and the components that are running on each instance. In addition, you can use the tool to
confirm the version and configuration of the Windows Server that it is running on.
3. Data Migration Assistant
4. Use the Data Migration Assistant in the planning and assessment stage of a Data Platform Moderniza-
tion project to check for compatibility issues that can impact database functionality in your new
version of SQL Server hosted in the Azure Virtual Machine. You should also use it to review perfor-
mance and reliability improvements for your target environment prior to performing the migration so
that you can incorporate them into your plan.
5. Database Experimentation Assistant
6. If you have concerns surrounding the workloads that will be operating on the target server, then use
the Database Experimentation Assistant to assess if your target server can handle the workload.
Customers who are upgrading from earlier SQL Server versions to a more recent version of SQL Server
on Azure Virtual Machines, can use the analysis metrics to give comparison data to allow you to make
decisions on whether the targeted version would provide a better experience after a migration.
Migration Planning for SQL Server on Azure Vir-

tual Machines
In addition to the areas that have been discussed with the planning and assessment stages of a Data Plat-
form Modernization process, there are areas that should be considered that are specific to migrating your
SQL Server Workload to an Azure Virtual Machine.
Licensing
There are two types of licensing model that can be used for SQL Server virtual machines hosted in Azure.
You should assess which on is the most appropriate for your migration scenario.
● The pay-as-you-go (PAYG) model means that the per-second cost of running the Azure VM includes
the cost of the SQL Server license.
● The bring-your-own-license (BYOL) model is also known as the Azure Hybrid Benefit (AHB), and it
allows you to use your own SQL Server license with a VM running SQL Server. You would only pay for
the VM usage.
You can modify the licensing with either the Azure Portal, Azure CLI or PowerShell
Virtual Machine Sizing

To get started, you can choose a SQL Server virtual machine image with your required version, edition,
and operating system. Virtual Machines start from SQL Server 2008 R2 SP3, and you can configure the
number of CPUs and memory to the size that is appropriate for your workloads.
Networking
If you provision a SQL Server VM in the Azure portal, you have the option of specifying the type of SQL
connectivity which includes:
● Public: Connect to SQL Server over the internet
● Private: Connect to SQL Server in the same virtual network
● Local: Connect to SQL Server locally on the same virtual machine
If you want to connect to your SQL Server database engine from the Internet, select Public for the SQL
connectivity type in the portal during provisioning. The portal automatically does the following steps:
● Enables the TCP/IP protocol for SQL Server.
● Configures a firewall rule to open the SQL Server TCP port (default 1433).
● Enables SQL Server Authentication, required for public access.
● Configures the network security group on the VM to all TCP traffic on the SQL Server port.
When you choose Private for the SQL connectivity type in the portal, Azure configures most of the
settings identical to Public. The one difference is that there is no network security group rule to allow
outside traffic on the SQL Server port (default 1433). You can change the connectivity settings for your
SQL Server virtual machine in the Azure portal.
1. In the Azure portal, select Virtual Machines.
2. Select your SQL Server VM.
3. Under Settings, click SQL Server configuration.
4. Change the SQL connectivity level to your required setting. You can optionally use this area to change
the SQL Server port or the SQL Authentication settings.
5. Wait several minutes for the update to complete
Key Management
There are a number of SQL Server features such as transparent data encryption (TDE), column level
encryption (CLE), and backup encryption. These forms of encryption require you to manage and store the
cryptographic keys you use for encryption. The Azure Key Vault (AKV) service is designed to improve the
security and management of these keys in a secure and highly available location. The SQL Server Connec-
tor enables SQL Server to use these keys from Azure Key Vault.
You can save time by using the Azure Key Vault Integration feature. When this feature is enabled, it
automatically installs the SQL Server Connector, configures the EKM provider to access Azure Key Vault,
and creates the credential to allow you to access your vault.
Performance best practices with SQL Server running on an

Azure Virtual Machine
Many of the database performance tuning options that you have used to ensure that your SQL Server
performs well on-premises still apply to a SQL Server that runs on an Azure Virtual Machine. There are
additional considerations that you need to be mindful of such as the size of the Azure Virtual Machine, or
the configration of the disks within the virtual machine. You can use the following checklist as a guide to
ensure that you have the optimal performance setup for a SQL Server running on Azure Virtual Machine
Performance Metric Optimization option

Virtual Machine ● The minimum virtual machine size that
should be selected for Enterprize
editions of SQL Server is DS3_v2 or
higher..
● For standard or web edition, use
DS2_v2 as a minimum size.
Storage ● Use premium SSDs for production
workloads.
● Standard storage for dev/test envi-
ronment.
● Make sure that the storage is colocat-
ed in the same location as the virtual
machine.
Disks ● Use a minimum of 2 P30 disks (1 for
log files and 1 for data files including
TempDB). For workloads requiring
~50,000 IOPS, consider using an Ultra
SSD.
● Avoid using operating system or
temporary disks for database storage
or logging.
● Enable read caching on the disk(s)
hosting the data files and TempDB
data files.
● Do not enable caching on disk(s)
hosting the log file. Important: Stop
the SQL Server service when changing
the cache settings for an Azure VM
disk.
● Stripe multiple Azure data disks to get
increased IO throughput.
● Format with documented allocation
sizes.
● Place TempDB on local SSD for
mission critical SQL Server workloads
(after choosing correct VM size)
Performance Metric Optimization option

I/O ● Enable database page compression.
● Enable instant file initialization for
data files.
● Limit autogrowth of the database.
● Disable autoshrink of the database.
● Move all databases to data disks,
including system databases.
● Move SQL Server error log and
trace file directories to data disks.
● Setup default backup and database
file locations.
● Enable locked pages.
● Apply SQL Server performance
fixes.
There may be specific performance setting that you want to apply that are specific to your workload.
Make sure that this is tested in a test environment prior to the migration.
Defining the migration approach

Regardless of whether you migrate to SQL Server in virtual machine, or to Azure SQL Database, when
considering the approach to a database migration, it's important to consider the business downtime
requirements associated with the migration. This will determine the type of migration you will conduct in
a given timeframe. There are three types of migrations based on time, including:
● Zero downtime migration
● Small maintenance window migration
● Large maintenance window migration
Zero downtime migration

Zero downtime migrations are suitable for mission critical workloads for require zero or near zero
downtime. For this, SQL Server Transactional Replication or Always On Availability Groups can be used to
replicate data from a SQL Server database to the cloud based database.
Downtime is the amount of time that a service is unavailable. This is measured in days, hours, minutes
and seconds (to 1/1000 second). The amount of time that a service is allowed to be unavailable is known
as it's Service Level Agreement (SLA) and is expressed as a percentage.
eg. a service with an SLA of 99.95 % has the following downtimes agreed with the business
Period Time
Daily 43 Seconds
Weekly 5 Minutes 2 Seconds
Monthly 21 Minutes 36 Seconds
Yearly 4 Hours 22 Minutes 48 Seconds
eg. a service with an SLA of 99.995 % has the following downtimes agreed with the business
Period Time
Daily 4 Seconds
Weekly 30 Seconds
Monthly 2 Minutes 10 Seconds
Yearly 26 Minutes 17 Seconds
Small maintenance window migration

Small maintenance windows are often measured in minutes. For this, the Azure Data Migration Service
(DMS) can be used to replicate and migrate data from a SQL Server database to an Azure SQL Databases.
Large maintenance window migration

Large maintenance windows are often measured in hours and are suitable for application databases that
change infrequently, or where the workload is not critical to the business. For this, SQL Server Manage-
ment Studio BACPAC export/import files are suitable, as is backup and restore, or attach and detach
database.
Lesson Summary
In this lesson, you learned the specific benefits to migrating your SQL Server workloads to a SQL Server
that is hosted in an Azure Virtual Machine. You now understand which tools you should use to help get
an understanding of your source and target server that are part of the migration. You then looked at the
additional migration considerations that should be part of the planning process.
Learning objectives
● Understand the Migration Benefits to SQL Server
● Tools to support your migration planning
● Additional migration planning considerations
● Defining the migration approach
Important
Knowledge Check
Question 1
You work as a Data Engineer at Adventureworks who have an Enterprise Agreement that covers the SQL
Servers that are currently installed on thier network. You want to migrate one of your servers to a SQL
Server hosted on a Azure Virtual Machine. Which licensing model should you select when you provision the
virtual machine?
 CAL model
 pay-as-you-go
 Software Assurance
 bring-your-own-license
Question 2
Which of the tools can be used to help you in the discovery, planning and assessment stages of performing a
migration of an on-premises SQL Server to SQL Server hosted on a Azure Virtual Machine?
 Microsoft Planning and Assessment
SQL workloads to Azure VM migration options

Lesson 3: Identify Migration candidates using
In this lesson, you will explore the different methods you can use to migrate your on-premises SQL Server
workloads to Azure. You will understand why you would choose one method over another and under-
stand the steps that you need to take to perform each method.
Learning objectives
● Choosing a migration approach to Azure?
● Migrating using backup and restore
● Migrating using attach and Detach
● Migrating using Always On Availability Groups
● Migrating using Transactional Replication
● Migrating using the Data Migration Assistant
● Other migration options
Choosing the migration approach to Azure Vir-

tual Machines
There are a number of different ways that you can migrate your SQL Server to an Azure Virtual Machine.
The first step in the process is to provision an Azure Virtual Machine that has SQL Server installed. The
method chosen to migrate the database is typically dependent on the how much time you can afford the
SQL Server databases to be offline. However, another reason can be based on how much of the process
you would like to automate versus performing a manual migration. The different methods involved
include:
● Perform a backup using compression and then copy and restore the backup file to the Azure Virtual
Machine.
● Perform a backup to a URL and restore into the Azure virtual machine from the URL.
● Detach the database and copy the database files to the Azure Virtual Machine.
● Ship the database hard drive using Windows Import/Export Service
● Convert on-premises physical machine to Hyper-V VHD, upload to Azure Blob storage, and then
deploy as new VM using uploaded VHD
● Use the Data Migration Assistant Migration project to mograte a database schema and data
● Use AlwaysOn Availability Group deployed on-premises, use the Add Azure Replica Wizard to create a
replica in Azure and then failover, pointing users to the Azure database instance
● Use SQL Server transactional replication to configure the Azure SQL Server instance as a subscriber
and then disable replication, pointing users to the Azure database instance
SQL workloads to Azure VM migration options 95
For optimum data transfer performance, migrate the database files into the Azure VM using a com-
pressed backup file.
To minimize downtime during the database migration process, use either the AlwaysOn option or the
transactional replication option. If it is not possible to use the above methods, manually migrate your
database. Using this method, you will generally start with a database backup followed by a copy of the
database backup into Azure and then perform a database restore. You can also copy the database files
themselves into Azure and then attach them. There are several methods by which you can accomplish
this manual process of migrating a database into an Azure VM.
Note: SQL Server 2008 and SQL Server 2008 R2 are approaching the end of their support life cycle for
on-premises instances. To extend support, you can either migrate your SQL Server instance to an Azure
VM, or buy Extended Security Updates to keep it on-premises. For more information, see Extend support
for SQL Server 2008 and 2008 R2 with Azure1
Migrating using a Backup and Restore

Migrating using a Backup and Restore is the simplest method of performing a migration that is well
understood by SQL Server professionals. There are two methods in which this approach can be done.
Using Backup with Compression

This method of migration can be performed on source SQL Server 2005 systems or greater. You should
perform the following steps to perform a migration using this method
1. Create an Azure Virtual Machine with the version of SQL Server required
2. Ensure that you have connectivity to the Azure Virtual Machine from an on-premises location
3. Perform a full database backup with compression to an on-premises location.
4. Copy the backup file to a folder on the virtual machine.
5. Restore the database backup file onto the SQL Server in the Azure Virtual Machine
Note: If your backup file is larger than 1 TB, you must stripe it because the maximum size of a VM disk is
1 TB.
Performing a Backup and Restore using a URL

This method of migration can be performed on source SQL Server 2012 SP1 CU2 or greater. You should
perform the following steps to perform a migration using this method
1. Create an Azure Virtual Machine with the version of SQL Server required
2. Ensure that you have connectivity to the Azure Virtual Machine from an on-premises location
3. Perform a full database backup to a URL location.
4. Restore the database backup file from the URL onto the SQL Server in the Azure Virtual Machine
NOTE: With SQL Server 2016, striped backup sets are supported, are recommended for performance, and
required to exceed the size limits per blob.
1 https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-server-2008-eos-extend-support
Migrating using Attach and Detach Database

Another offline method that can be used to migrate your databases is using detach and attach databases
from URL. This method supports source databases of SQL Server 2005 or greater, with the target servers
of SQL Server 2014 or greater. You can detach your database and log files and transfer them to Azure
Blob storage. Then attach the database from the URL on your Azure VM.
This method is useful if you want the physical database files to reside in Blob storage. This might be
useful for very large databases. Below are the following general steps to migrate a user database using
this manual method:
1. Detach the database files from the on-premises database instance.
2. Copy the detached database files into Azure blob storage using the AZCopy command-line utility.
3. Attach the database files from the Azure URL to the SQL Server instance in the Azure VM.
Migrating SQL Server workloads using Availabil-

ity groups
If you want to minimize the amount of downtime whilst performing a migration, you can use the SQL
Server Always On Availability Group feature to extend an on-premises database into the cloud. This can
be achieved by provisioning an Azure Virtual Machine that contains SQL Server and then setting up a
secondary replica of the database in Azure. To do this you can use Transact-SQL to add a replica of the
database. In order for this to occur, it is assumed that there is already and on-premises SQL Server that
has an existing Always On Availability Group and that ther is connectivity between your on-premises
network to Azure. It is also assume that you have a virtual machine with SQL Server running.
NOTE: The Add Azure Replica Wizard only works with Virtual Machines running in Classic deployment
model. The best practices is to create Virtual Machines with Resource Manager, as a reult you can only
add a replica using Transact-SQL
Add a secondary replica to an Always On Availability

Group
In order to add a secondary replica to an Always On Availability Group, there are a numer of Transact-SQL
commands that are run to make this happen.
1. From within SQL Server Management Studio, connect to the instance of SQL Server that hosts the
primary replic and open a New Query window.
2. Add the new secondary replica to the availability group by using the ADD REPLICA ON clause of the
ALTER AVAILABILITY GROUP statement.
3. ALTER AVAILABILITY GROUP MyAG ADD REPLICA ON 'COMPUTER04'
WITH (
ENDPOINT_URL = 'TCP://COMPUTER04.Adventure-Works.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL
);
4. The previous Transact-SQL statement creates a new replica to an availability group named MyAG on
the default server instance hosted by COMPUTER04, whose endpoint URL is TCP://COMPUTER04.
Adventure-Works.com:5022'. This replica supports manual failover and asynchronous-commit availa-

bility mode.
Join a Secondary Replica to an Availability Group (SQL

Server).
Once the replica database is added, you then need to join the new secondary replica to the availability
group using the following steps:
1. Connect to the server instance that is going to host the new secondary replica.
2. Use the ALTER AVAILABILITY GROUP statement. The following example, joins the secondary replica
to the MyAG availability group.
3. ALTER AVAILABILITY GROUP MyAG JOIN;
Manually Prepare a Secondary Database for an Availability

Group (SQL Server).
You can use the following steps to create a secondary database on the server instance that is hosting the
secondary replica
1. Restore a recent database backup of the primary database and subsequent log backups onto each
server instance that hosts the secondary replica, using RESTORE WITH NORECOVERY on the second-
ary server
2. Join the restored database to the availability group using the following code:
3. ALTER DATABASE Db1 SET HADR AVAILABILITY GROUP = MyAG;
4. The following example joins the secondary database, Db1, to the local secondary replica of the MyAG
availability group.
Join a Secondary Database to an Availability Group (SQL

Server).
After you prepare a secondary database for a secondary replica, you need to join the database to the
availability group as soon as possible. This will start data movement from the corresponding primary
database to the secondary database.
To join a secondary database to an availability group, peform the following steps:
1. Connect to the server instance that hosts the secondary replica.
2. Use the SET HADR clause of the ALTER DATABASE statement. The following example joins the
secondary database, Db1, to the local secondary replica of the MyAG availability group.
3. ALTER DATABASE Db1 SET HADR AVAILABILITY GROUP = MyAG;
Create an availability group listener

After the availability group has been created, you should create a listener for clients to connect to the
replicas. Listeners direct incoming connections to either the primary or a read-only secondary replica.
Migrating SQL Server workloads using Transac-

tional Replication
Always On Availability Groups was introduced in SQL Server 2012, so use transactional replication when
you need to minimize downtime and do not have an Always On on-premises deployment. There are
three basic steps required to perform this migration
1. Set up distribution - responsible for distributing articles in the replication topology. Articles are a
database object e.g. Table that is included in the Publication
2. Create publication - a collection of one or more articles from the database being replicated
3. Create subscription. - a request from a Subscriber for a Publication from a Publisher
Setup a distribution database

The first step is to setup the distribution database that is used to manage the replication topology.
1. Connect to server you are replicating in Object Explorer. (This will be known as the Publisher)
2. Right click on the Replication folder and select Configure Distribution.
3. On the Distributor page, select Server Name will act as its own distributor. Then click next.
4. If the SQL Agent isn’t running on the SQL Agent Start page, select Yes to configure the SQL Agent to
run automatically.
5. Select a Snapshot folder to store your initial snapshot. Creating a snapshot involves taking a BCP
copy of every replicated table. It is for the initial synchronization between the publisher and subscrib-
er. You can also schedule your snapshot creation for later.
6. Use the defaults on the remaining pages of the wizard.
7. Click Finish to enable the distribution.
Create a publication
You can create a publication of the source database that can be replicated to a secondary server inclusing
an Azure Virtual Machine hosting SQL Server.
1. Connect to the Publisher in SQL Server Management Studio, and expand the server node.
2. Expand the Replication folder and right-click the Local Publications folder.
3. Click New Publication.
4. Select your publication database, then click Next.
5. Select Transactional Publication , then click Next.
6. Select the articles you want to publish, then click next. You can publish everything, or select specific
tables.
7. Select when you would like to create a snapshot. Click Immediately and then click Next.
8. Click Security Settings near the Snapshot Agent box. Select Run under the following Windows
account and enter your credentials. Under Connect to the Publisher, select Impersonate. Click ok to
confirm and return to the original Agent Security page. Check the checkbox at the bottom and click
next. Select Create the publication and then click Next.
9. Name the publication and click finish.
Create a subscription
1. Connect to the Publisher in SQL Server Management Studio and expand the server node.
2. Expand the Replication folder, and then expand the Local Publications folder.
3. Right-click your publication and click New Subscriptions.
4. Select your publication and click Next. Select Run at Distributor and click Next.
5. Click Add Subscriber and connect to the Azure SQL Database logical server and then click Next.
6. Click the ellipsis button … and select the option to connect to the subscriber using SQL Server login.
Enter the credentials. Connect to the Distributor by Impersonating. Then click Next.
7. Use the defaults on the remaining pages of the wizard.
8. Click Finish to create the subscription.
Once the process is complete, you should test that the database appears on the subscriber instance in
the Azure Virtual Machine. You can direct the connections to the subscriber database. You may wish to
stop and delete the replication once the data has been successfully migrated.
Migrating SQL Server workloads using the Data

Migration Assistant
The Data Migration Assistant can be used to migrate the schema and data from an on-premises SQL
Server to an Azure Virtual Machine. After running an assessment in the Data Migration Assistant and
addressing any compatibility issues, you can use the same tool to create a migration project ujsing the
following steps.
1. Open the Data Migration Assistant.
2. Select the New icon, select the Migration project type, select SQL Server as source and target types,
and then select Create.
3.
4. Provide source and target SQL server conenction details, and then select Next.
5.
6. The wizard will connect up to both the servers
7.
8. Select the database to migrate and a shared location for the backup and restore operation.
9. Select the logins to migrate and start the migration
10. View the status of the migration until completion
Other Migration Options

Most of the migration options that have been outlined so far will help most organizations when migrat-
ing thier SQL workloads to Azure Virtual Machines. However, the following are alternatives, and can be
used to perform a migration as well.
Convert to VM and upload to URL and deploy as new VM

Use this method to migrate all system and user databases in an on-premises SQL Server instance to
Azure virtual machine. The source and target server can be a minimum of SQL Server 2005. You should
use this approach when bringing your own SQL Server license, migrating a database that you will run on
an older version of SQL Server, or when migrating system and user databases together as part of the
migration of database dependent on other user databases and/or system databases.
Use the following general steps to migrate an entire SQL Server instance using this manual method:
1. Convert physical or virtual machines to Hyper-V VHDs.
2. Upload VHD files to Azure Storage by using the Add-AzureVHD cmdlet.
3. Deploy a new virtual machine by using the uploaded VHD.
The Windows Export Service

Use the Windows Import/Export Service method to transfer large amounts of file data to Azure Blob
storage in situations where uploading over the network is prohibitively expensive or not feasible. With
this service, you send one or more hard drives containing that data to an Azure data center, where your
data will be uploaded to your storage account. This approach supports SQL Server 2005 or greater as
both the source and target server.
Lesson Summary
In this lesson, you have explored the different methods you can use to migrate your on-premises SQL
Server workloads to Azure. You also understand why you would choose one method over another and
the steps that is required to use each method.
Learning objectives
● Choosing a migration approach to Azure?
● Migrating using backup and restore
● Migrating using attach and Detach
● Migrating using Always On Availability Groups
● Migrating using Transactional Replication
● Migrating using the Data Migration Assistant
● Other migration options
Important
Knowledge Check
Question 1
You have a SQL Server 2012 instance with a database that contains over 1.2TB of compressed data. You
want to perform a backup of the database so that it can be used as part of a database migration. What type
of disk volume should the backup be made to?
 a simple volume
 A dynamic volume
 A striped volume
 A mirrored volume
Question 2
You are running a database on SQL Server 2008 R2. You want to perform a migration that minimizes the
downtime. Which migration approach should you use?
 attach and detach database
 Alway On Availability Groups
 Import and Export Service
 Transactional Replication
Application configuration and optimization

Lesson 1: Considerations of Migrating to SQL
Server in Azure Virtual Machines
In this lesson, you will look at some of the post migration tasks that may have to be completed. This
involves checking that your application can connect to the database, any business intelligence considera-
tions and finally post migration tasks that ensure that the databases perform well
Learning objectives
● Connecting applications to a migrated database
● Business Intelligence considerations
● Post Migration Considerations
Application Connectivity to Azure Virtual Ma-

chines
One of the key benefits of performing a migration to SQL Server on an Azure Virtual Machine is that you
can migrate the database and the applications with minimal changes to code and connection string
information changes within the application. This statement is made on the basis that the database is
migrated to the same version of SQL Server, with a database that is remaining at the same database
compatability level that was set when it was on an on-premises server. If not, then there are a number of
considerations that must be taken into account. This is covered in more depth in other topics where a
migration of an on-premises SQL Server database to Azure Database or Azure Database Managed
Instance is more likely to move to a newer version of SQL Server where database compatability is an
issue.
Business Intelligence Considerations

Many on-premises business intelligence technologies have Platform as a Service (PaaS) equivalent
technologies to take advantage of in Azure such as Azure Data Factory, Azure Analysis Services, Power BI,
and more. There are also many scenarios where businesses have invested heavy amounts of time and
resources towards building very rich business intelligence estates that consist of SQL Server Integration
Services packages, very deep SQL Server Reporting Services landscape with a scaled-out topology
leveraging highly available reports, which often rely on scheduled reports that must be sent to consumer
directly. There are also organization who have heavily invested into MDX with SQL Server Analysis
Services where they have not yet embraced Analysis Services tabular model.
For these scenarios, it may seem that their business intelligence investment is also a blocker for moving
to PaaS options such as Azure SQL Database or SQL Database Managed Instance, but this is not the case.
It simply means that there's a choice between using SQL Server on an Azure Virtual machine or migrating
to a Platform as a Service (PaaS). An organization could decide to remain on-premises too. The reality is
you can use any of these approaches to accomplish your business goals. You can always change your
business intelligence investment on your own time at a future date.
There is nothing stopping an organization from deploying a fully scaled-out Reporting Services solution
in the same VNet that Managed Instance and Managed Instance databases are located. You can also put
Application configuration and optimization 105
your Business Intelligence solution in a separate VNet and use VNet peering to ensure that the connectiv-
ity is secure. It is recommended to leverage Platform as a Service (PaaS) technologies to get the most up
to date experience in Azure.
Post Migration Considerations

Should your SQL Server database migration upgrade your database to a newer version of SQL Server or a
higher database compatability level, there are a number of post migrations steps that you will want to
check to complete the migration. Many checks largely fall around ensuring that the database performs
well, and these checks are valid with migrations to SQL Database and SQL Database Managed Instance as
well as SQL Server on an Azure Virtual Machine.
Query performance
It's important when you're migrating legacy technologies such as SQL server 2008, that you leverage the
latest database compatibility where possible. However, there are times that latest compatibility level
produces non optimal results and you have query regressions. This is the perfect scenario to leverage
query store which is like a black box recorder at the database level. Query store also captures the execu-
tion plan where you can identify parameter sniffing issues and specifically see when queries have re-
gressed. by leveraging Query Store, you can get a baseline of a healthy state and then use this healthy
state as a means to fall back to when there are issues such as changing the compatibility level.
When migrating from an older version of SQL Server to SQL Server 2014 (12.x) or newer, and upgrading
the database compatibility level to the latest available, a workload may be exposed to the risk of perfor-
mance regression. Starting with SQL Server 2014, all Query Optimizer changes are tied to the latest
database compatibility level, so plans are not changed right at point of upgrade, but when a user chang-
es the COMPATIBILITY_LEVEL database option to the latest one. This capability, in combination with
Query Store gives you a great level of control over the query performance in the upgrade process. Param-
eter sniffing can also be addressed using query store as it can also be partially addressed using the latest
compatibility levels using the following steps
1. Use the RECOMPILE hint. A plan is calculated every time adapted to each parameter value.
2. Rewrite the stored procedure to use the option (OPTIMIZE FOR(“input parameter” = "value")). Decide
which value to use that suits most of the relevant workload, creating and maintaining one plan that
becomes efficient for the parameterized value.
3. Rewrite the stored procedure using local variable inside the procedure. Now the optimizer uses the
density vector for estimations, resulting in the same plan regardless of the parameter value.
4. Rewrite the stored procedure to use the option (OPTIMIZE FOR UNKNOWN). Same effect as using the
local variable technique.
5. Rewrite the query to use the hint DISABLE_PARAMETER_SNIFFING. Same effect as using the local
variable technique by totally disabling parameter sniffing, unless OPTION(RECOMPILE), WITH RECOM-
PILE or OPTIMIZE FOR “value” is used.
Missing indexes
Incorrect or missing indexes causes extra I/O that leads to extra memory and CPU being used in a
sub-optimal way. This maybe because the workload profile has changed such as using different predi-
cates, which invalidates existing index design. Evidence of a poor indexing strategy or changes in work-
load profile include lookups for duplicate, redundant, rarely used and completely unused indexes. you
can perrorm the following steps to resolve this issue
1. Leverage the graphical execution plan for any Missing Index references.
2. Indexing suggestions generated by Database Engine Tuning Advisor
3. Leverage the Missing Indexes DMV or through the SQL Server Performance Dashboard
4. Leverage pre-existing scripts that can use existing DMVs to provide insight into any missing, duplicate,
redundant, rarely used and completely unused indexes, but also if any index reference is hinted/
hard-coded into existing procedures and functions in your database.
Poorly Written T-SQL Statements

SQL Server Query Optimizer can only account for information that is known at compile time. If a work-
load relies on predicates that can only be known at execution time, then the potential for a poor plan
choice increases. For a better-quality plan, predicates must be SARGable, or Search Argumentable. Some
examples of non-SARGable predicates:
● Implicit data conversions, like VARCHAR to NVARCHAR, or INT to VARCHAR. Look for runtime CON-
VERT_IMPLICIT warnings in the Actual Execution Plans. Converting from one type to another can also
cause a loss of precision.
● Complex undetermined expressions such as WHERE UnitPrice + 1 < 3.975, but not WHERE UnitPrice <
32020032.
● Expressions using functions, such as WHERE ABS(ProductID) = 771 or WHERE UPPER(LastName) =
‘Smith’
● Strings with a leading wildcard character, such as WHERE LastName LIKE ‘%Smith’, but not WHERE
LastName LIKE 'Smith%'.
You can use the following steps to resolve these types of issues:
1. Always declare variables/parameters as the intended target data type. This may involve comparing
any user-defined code construct that is stored in the database (such as stored procedures, user-de-
fined functions or views) with system tables that hold information on data types used in underlying
tables (such as sys.columns)
2. If unable to traverse all code to the previous point, then for the same purpose, change the data type
on the table to match any variable/parameter declaration.
3. Reason out the usefulness of the following constructs:
● Functions being used as predicates;

● Wildcard searches;
● Complex expressions based on columnar data – evaluate the need to instead create persisted
computed columns, which can be indexed;
Missed Estimates
For SQL Server to SQL Server migrations, if this issue existed in the source SQL Server, migrating to a
newer version of SQL Server as-is will not fix the issue. Table Valued Functions return a table data type
that can be an alternative to views. While views are limited to a single SELECT statement, user-defined
functions can contain additional statements that allow more logic than is possible in views.
Application configuration and optimization 107
Important: Since the output table of an Multi-Statement Table Valued Function (MSTVF) is not created at
compile time, the SQL Server Query Optimizer relies on heuristics, and not actual statistics, to determine
row estimations. Even if indexes are added to the base table(s), this is not going to help. For MSTVFs, SQL
Server uses a fixed estimation of 1 for the number of rows expected to be returned by an MSTVF (starting
with SQL Server 2014 (12.x) that fixed estimation is 100 rows).
The ways this can be resolved is as follows
- If the Multi-Statement TVF is single statement only, convert to Inline
TVF.
- If you cannot make changes to the code due to the application being a
vendor-based application or other deployment challenges, the SQL Server
2017 database compatibility level 140 may provide the best approach. At
db_compat level 140, Adaptative Query Processing (AQP) may provide perfor-
mance improvements to avoid rewriting the query.
Other Post Migration Steps

The other post migration steps that you should be aware of simply come down to taking advantage of
Azure SQL Database, SQL Database Manage Instance, and SQL Server improvements that have been
made to the product. There are a number of different improvements that have been made at the security
level, performance improvements, troubleshooting and management capabilities, high availability and
disaster recovery, business intelligence, and many other areas of the product that require some configu-
ration in order to take advantage of. For example, Failover groups in SQL Database Managed Instance
provides a very strong method to extend your high availability / disaster recovery approach to another
region. It's a very simple configuration but it does require some intervention to create.
Security technologies such as row level security, dynamic data masking, always encrypted, transparent
data encryption - all of these are an opt-in approach in order to take advantage of the security capabili-
ties. Additionally, technologies such as query store, the newer dynamic management views and functions,
extended events, diagnostic tracing, and auditing are all far improvements compared to previous releas-
es. It is important to get informed on the capabilities of these technologies to be able to leverage them at
the most optimal level.
Finally, once the migration has completed. It is important to get all of your maintenance scripts in place
to rebuild indexes and update statistics. Ensure that there is no orphaned users, Ensure that backups are
executing correctly and successfully and finally you should take in the state of the error log and the
general architecture of the environment.
Lesson Summary
In this lesson, you looked at some of the post migration tasks that may have to be completed, involving
checking that your application can connect to the database, any business intelligence considerations and
post migration tasks that ensure that the databases perform well.
Learning objectives
● Business Intelligence considerations
● Post Migration Considerations
Important
Knowledge Check
Question 1
You have migrated your SQL Server database to an Azure Virtual Machine that hosts the same version and
edition of SQL Server. The database has been migrated using a back and restore and is now online. What
change needs to be made to the application to ensure that it will work with the database?
 Upgrade the .Net framework
 Change the application connection string
 Update the base code of the application
 update the application license
Question 2
You have migrated your SQL Server database 2008 database to an Azure Virtual Machine that hosts SQL
Server 2014. The database has been migrated using a back and restore and is now online. What post
migration checks would you perform to ensure that the database performs?
 Check query performance
 Check for missing indexes
 Rewrite poorly performing queries
Module summary 109
Module summary
Module Summary
In this module, you have learned how you can migrate SQL Server workloads to SQL Server installations
that are running on an Azure Virtual Machine. You then learned the various ways to migrate SQL Server
workloads both offline and online, and then finished up with the post migration tasks that may have to
be taken to ensure that the migrated database performs appropriately.
Learning objectives
● Considerations for migrating to SQL Server on Azure Virtual Machines
● SQL Server workload to Azure Virtual Machine migration options
● Application configuration and optimization
Answers
Question 1
You work as a Data Engineer at Adventureworks who have an Enterprise Agreement that covers the SQL
Servers that are currently installed on thier network. You want to migrate one of your servers to a SQL
Server hosted on a Azure Virtual Machine. Which licensing model should you select when you provision
the virtual machine?
 CAL model
 pay-as-you-go
 Software Assurance
■ bring-your-own-license
Explanation
Should your organization already have licenses in place for existing on-premises SQL Servers, and you
intend to decommision those servers then you should use the bring-your-own-license model when you
provision the virtual machine
Question 2
Which of the tools can be used to help you in the discovery, planning and assessment stages of perform-
ing a migration of an on-premises SQL Server to SQL Server hosted on a Azure Virtual Machine?
■ Data Migration Assistant
■ Microsoft Planning and Assessment
■ Database Experimentation Assistant
Explanation
You should use the Microsoft Planning and Assessment in the discovery stage, the Data Migration Assistant
in the planning stage and the Database Experimentation Assistant in the assessment stage to help you gain
information that will help with a migration of an on-premises SQL Server to SQL Server hosted on a Azure
Virtual Machine
Question 1
You have a SQL Server 2012 instance with a database that contains over 1.2TB of compressed data. You
want to perform a backup of the database so that it can be used as part of a database migration. What
type of disk volume should the backup be made to?
 a simple volume
 A dynamic volume
■ A striped volume
 A mirrored volume
Explanation
The correct answer is a stiped volume. The maximum size of a virtual machine disk is 1TB, so a striped
volume should be used to restore the data too.
Module summary 111
Question 2
You are running a database on SQL Server 2008 R2. You want to perform a migration that minimizes the
downtime. Which migration approach should you use?
 attach and detach database
 Alway On Availability Groups
 Import and Export Service
■ Transactional Replication
Explanation
In order to perform a migration that minimizes the downtime from SQL Server 2008 R2, you should use
transactional replication. Always On Availability Groups are not a feature of SQL Server 2008, and attach
and detach and the Import and Export Service would have a longer downtime period.
Question 1
You have migrated your SQL Server database to an Azure Virtual Machine that hosts the same version
and edition of SQL Server. The database has been migrated using a back and restore and is now online.
What change needs to be made to the application to ensure that it will work with the database?
 Upgrade the .Net framework
■ Change the application connection string
 Update the base code of the application
 update the application license
Explanation
As the SQL Server version and edition is the same, and the database has been backed up and restore, you
would change the applications connection string to connect to the migrated database instance
Question 2
You have migrated your SQL Server database 2008 database to an Azure Virtual Machine that hosts SQL
Server 2014. The database has been migrated using a back and restore and is now online. What post
migration checks would you perform to ensure that the database performs?
 Check query performance
 Check for missing indexes
 Rewrite poorly performing queries
■ All of the above
Explanation
When migrating from one version of SQL Server to another, post migration you will want to check query
performance, Check for missing indexes and rewrite poorly peforming queries to ensure that the database
performs
Module 4 Migrate SQL Workloads to SQL Da-
tabase
Module introduction
Module Introduction
In this module, you will look at how you can migrate SQL Server workloads to Azure SQL Database. It will
begin by exploring the pre migration considerations that need to be taken into account before perform-
ing a migration and how to create an Azure SQL Database. You will then explore the different methods to
perform an offline and online migration and look at ways to ensure service continuity of Azure SQL
Database.
Learning objectives
In this module, you will learn the:
● Considerations of migrating to Azure SQL Database
● Migrate to an Azure SQL Database
● Service Continuity to Azure SQL Database
MCT USE ONLY. STUDENT USE PROHIBITED 114 Module 4 Migrate SQL Workloads to SQL Database
Considerations of migrating to Azure SQL Da-

tabase
Lesson 1: Considerations for migrating to Azure
Database
This lesson explores the considerations for migrating SQL Server workloads to Azure SQL Database. It
explores the benefits of moving to this platform and the tools that you should use to plan your migration.
Learning objectives
In this lesson, you will:
● Understand the migration benefits of Azure SQL Database
● Use the tools to support your migration planning
● Migration planning specific to Azure SQL Database
● Create an Azure SQL Database
What is Azure SQL Database?

Azure SQL Database is the collective term for Microsoft's SQL Server Platform-as-a-Service (PaaS)
offering. It's fully managed and provides organizations with a highly performing, reliable and secure,
general purpose relational database engine in the cloud. There are three products within the Azure SQL
Database family, each providing different benefits:
● Single databases
● Elastic Pools
● Managed Instances
In this module we focus on Single Databases and Elastic Pools. A Single Database has its own resources
and is deployed to a logical SQL Database server where it is managed. There are several tiers of perfor-
mance, each providing different levels of throughput, performance, storage and cost. SQL Database
Elastic Pools provide organizations with a cost-effective way for deploying and managing multiple
databases with different workload characteristics. Elastic Pool databases are deployed onto a single SQL
Database server where resources are shared between all of the databases on that server.
Considerations of migrating to Azure SQL Database 115
Benefits of Azure SQL Database (Single and Elastic Pools)

There are a number of benefits when deploying Single and Elastic pool databases. The sections below
categorise and summarise these benefits.
Backup and Recovery

● Automatic backup
● Point in time restore
● Backup retention 7 days+
● Long Term Backup Retention, stores backups for up to 10 years
High Availability
● 99.99% availability guarantee
● Built-in availability with three secondary replicas
● Zone Redundancy via Azure Availability Zones
Disaster Recovery
● Geo-restore of database backups
● Active-geo replication between Azure Regions
Service Scalability
● Dynamic scale-up and scale-down
● Scale-out with multiple shards
● Share compute between databases using Elastic Pools
Security
● Support for Azure Active Directory authentication
● Cloud-only security features such as Advanced Threat Protection
● Transparent Data Encryption (TDE) enabled by default
● Support for Dynamic and Static Data Masking, Row-Level Security and Always Encrypted
● Firewall whitelist
Licensing
● DTU purchasing model for predictive costing
● vCore purchasing model, enabling storage to be scaled independently of compute
● Combine the vCore purchasing model with Azure Hybrid Benefit for SQL Server to realise cost savings
of up to 30%
Tools to support you migration planning to Az-

ure SQL Database
Azure SQL Database.
1. Microsoft Planning and Assessment-Use this tool in the discovery stage to confirm the source
environment that you are migrating from. This helps you to understand the configuration of your
source SQL Server, how many instances are installed and the components that are running on each
instance. In addition, you can use the tool to confirm the version and configuration of the Windows
Server that it is running on.
2. Azure Database Migrate Service-The Azure Database Migrate Service enables you to perform large
scale database migration from within the Azure Portal. Azure Database Migration Service integrates
some of the functionality of existing tools and services to provide customers with a comprehensive,
highly available solution. The tools include:
3. Data Migration Assistant-Use the Data Migration Assistant in the planning and assessment stage of
a Data Platform Modernization project to check for compatibility issues that can impact database
functionality in SQL Database Managed Instance. You should also use it to review performance and
reliability improvements for your target environment prior to performing the migration so that you
can incorporate them into your plan.
4. Database Experimentation Assistant-If you have concerns surrounding the workloads that will be
operating on the target server, then use the Database Experimentation Assistant to assess if your
target server can handle the workload. Customers who are upgrading from earlier SQL Server versions
to a more recent version of SQL Server on Azure Virtual Machines, can use the analysis metrics to give
comparison data to allow you to make decisions on whether the targeted version would provide a
better experience after a migration.
Migration Planning for Azure SQL Database

Azure SQL Database provides a Platform-as-a-Service (PaaS) host for SQL workloads. It removes the need
to administer and manage infrastructure. High Availability and Disaster Recovery are built-in to the
platform. When migrating to an Azure SQL Database it is important to recognize that this product
although similar to SQL Server is a distinctly separate application, and there are consideration that need
to be planned for prior to the migration.
SQL Agent Jobs

Azure SQL Database (singleton and elastic pool) do not provide functionality to host SQL Server Agent
jobs, these must be migrated to complementary technologies such as:
● Azure Automation
● Elastic Database Jobs
Security settings
Authentication with security principals in Azure SQL Database supports two types of authentication:
● SQL Authentication
● Azure Active Directory Authentication
Any Windows Authentication logins should be changed to use a supported authenticated method.
Azure role-based access control (RBAC) can be used to control access of Azure resources. Azure SQL
Database supports the following built-in roles:
● SQL DB Contributor
● SQL Security Manager
● SQL Server Contributor
Read Scale-Out
Read Scale-Out allows for read only SQL workloads to be serviced by a secondary replica. This allows for
great efficiency of resource usage as the workload is transferred away from the primary replica. Read
Scale-Out is enabled free of charge on Premium and Business Critical service tier, it cannot be enabled in
Basic, Standard, or General Purpose service tiers
Connecting to Read Scale-Out replica

Connecting to a read-only replica requires that the connection string is altered to specify an additional
option. The ApplicationIntent=ReadOnly option specify that workload is read-only and can be directed
to a non-writable replica.
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;Application-
Intent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connec-
tion=False; Encrypt=True;
Retry Application Connections

When accessing any cloud service it is important to understand the requirements for retry logic so that
an application can recover from temporary issues and problems.
Retry Service Specific1
Feature Comparison
There are a number of distinct features and capabilities that are specific to Azure SQL Database (Single of
Elastic Pool) versus Azure SQL Database managed instance. The following table provides clarity on which
configuration support which SQL Server feature.
1 https://docs.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific
SQL Feature Supported by single databases Supported by managed instanc-

and elastic pools es
Active geo-replication Yes - all service tiers other than No, seeAuto-failover groups
hyperscale (https://docs.microsoft.com/
en-us/azure/sql-database/
sql-database-auto-failover-group)
Auto-failover groups Yes - all service tiers other than Yes, inpublic preview (https://
hyperscale docs.microsoft.com/en-us/azure/
sql-database/sql-database-auto-
failover-group)
Always Encrypted Yes - seeCert storeandKey vault Yes - seeCert store (https://docs.
microsoft.com/en-us/azure/
sql-database/sql-database-al-
ways-encrypted)andKey vault
(https://docs.microsoft.com/
sql-database-always-encrypt-
ed-azure-key-vault)
Always On Availability Groups High availability (https://docs. High availability (https://docs.
microsoft.com/en-us/azure/ microsoft.com/en-us/azure/
sql-database/sql-data- sql-database/sql-data-
base-high-availability) is includ- base-high-availability)is included
ed with every database. Disaster with every database. Disaster
recovery is discussed in Over- recovery is discussed inOver-
view of business continuity view of business continuity
with Azure SQL Database with Azure SQL Database
(https://docs.microsoft.com/ (https://docs.microsoft.com/
en-us/azure/sql-database/ en-us/azure/sql-database/
sql-database-business-continuity) sql-database-business-continuity)
Attach a database No No
Automatic tuning (indexes) Yes No
BACPAC file (export) Yes - seeSQL Database export Yes
sql-database-export)
BACPAC file (import) Yes - seeSQL Database import Yes
sql-database-import)
BACKUP command No, only system-initiated System-initiated automated
automatic backups - seeAuto- backups and user initiated
mated backups (https://docs. copy-only backups - seeBackup
microsoft.com/en-us/azure/ differences (https://docs.
sql-database/sql-database-auto- microsoft.com/en-us/azure/
mated-backups) sql-database/sql-database-man-
aged-instance-transact-sql-infor-
mation#backup)
Built-in functions Most - see individual functions Yes - seeStored procedures,
functions, triggers differences

Change data capture No Yes
Collation - server/instance No, defaultSQL_Latin1_General_ Yes, can be set when theinstance
CP1_CI_ASis always used. is created (https://docs.microsoft.
com/en-us/azure/sql-database/
scripts/sql-managed-in-
stance-create-powershell-az-
ure-resource-manager-template)
and cannot be updated.
Columnstore indexes Yes -Premium tier, Standard Yes
tier - S3 and above, General
Purpose tier, and Business
Critical tiers (https://docs.
microsoft.com/sql/relational-da-
tabases/indexes/columnstore-in-
dexes-overview)
Common language runtime No Yes, but without access to file
(CLR) system - seeCLR differences
sql-database-managed-in-
stance-transact-sql-information#-
clr)
Contained databases Yes Nodue to defect in RESTORE
including point-in-time
RESTORE (https://docs.microsoft.
com/en-us/azure/sql-database/
cannot-restore-contained-data-
base)
Cross-database queries No - seeElastic queries (https:// Yes, plusElastic queries (https://
docs.microsoft.com/en-us/azure/ docs.microsoft.com/en-us/azure/
sql-database/sql-database-elas- sql-database/sql-database-elas-
tic-query-overview) tic-query-overview)
Cross-database transactions No Yes, within the instance. SeeL-
inked server differences
stance-transact-sql-informa-
tion#linked-servers)for cross-in-
stance queries.
Database mail No Yes
Database mirroring No No
Data Quality Services (DQS) No No
Database snapshots No No

DBCC statements Most - see individual statements Yes - seeDBCC differences
tion#dbcc)
DDL statements Most - see individual statements Yes - seeT-SQL differences
stance-transact-sql-information)
DDL triggers Database only Yes
Distributed partition views No Yes
Distributed transactions - MS No - seeElastic transactions No - seeLinked server differ-
DTC (https://docs.microsoft.com/ ences (https://docs.microsoft.
en-us/azure/sql-database/ com/en-us/azure/sql-database/
sql-database-elastic-transac- sql-database-managed-in-
tions-overview) stance-transact-sql-informa-
tion#linked-servers)
DML triggers Most - see individual statements Yes
DMVs Most - see individual DMVs Yes - seeT-SQL differences
Elastic pools Yes Built-in - a single Managed
Instance can have multiple
databases that share the same
pool of resources
Event notifications No - seeAlerts (https://docs. No
sql-database/sql-database-in-
sights-alerts-portal)
Extended events Some - seeExtended events in Yes - seeExtended events
SQL Database (https://docs. differences (https://docs.
sql-database/sql-database- sql-database/sql-database-man-
xevent-db-diff-from-svr) aged-instance-transact-sql-infor-
mation#extended-events)
Extended stored procedures No No
Files and file groups Primary file group only Yes
Filestream No No
Full-text search Third-party word breakers are Third-party word breakers are
not supported not supported

Functions Most - see individual functions Yes - seeStored procedures,
stored-procedures-functions-trig-
gers)
Geo-restore Yes - all service tiers other than Yes - usingAzure PowerShell
hyperscale (https://medium.com/az-
ure-sqldb-managed-instance/
geo-restore-your-databases-on-
azure-sql-instanc-
es-1451480e90fa).
In-memory optimization Yes -Premium and Business Yes -Business Critical tier only
Critical tiers only (https://docs. (https://docs.microsoft.com/
microsoft.com/en-us/azure/ en-us/azure/sql-database/
sql-database/sql-data- sql-database-managed-instance)
base-in-memory)
Language elements Most - see individual elements Yes - seeT-SQL differences
Linked servers No - seeElastic query (https:// Only to SQL Server and SQL
docs.microsoft.com/en-us/azure/ Database
sql-database/sql-database-elas-
tic-query-horizontal-partitioning)
Log shipping High availability (https://docs. High availability (https://docs.
base-high-availability)is included base-high-availability) is includ-
with every database. Disaster ed with every database. Disaster
recovery is discussed inOver- recovery is discussed in Over-
Master Data Services (MDS) No No
Minimal logging in bulk import No No
Modifying system data No Yes
OLE Automation No No

OPENDATASOURCE No Yes, only to other Azure SQL
Databases and SQL Servers.
SeeT-SQL differences (https://
docs.microsoft.com/en-us/azure/
sql-database/sql-database-man-
mation)
OPENQUERY No Yes, only to other Azure SQL
Databases and SQL Servers.
SeeT-SQL differences (https://
docs.microsoft.com/en-us/azure/
mation)
OPENROWSET Yes, only to import from Azure Yes, only to other Azure SQL
Blob storage. Databases and SQL Servers, and
to import from Azure Blob
storage. SeeT-SQL differences
Operators Most - see individual operators Yes - seeT-SQL differences
Point in time database restore Yes - all service tiers other than Yes - seeSQL Database recovery
hyperscale - seeSQL Database (https://docs.microsoft.com/
recovery en-us/azure/sql-database/
sql-database-recovery-us-
ing-backups#point-in-time-re-
store)
Polybase No No
Policy-based management No No
Query Notifications No Yes
Query Performance Insights Yes No
R Services Yes, inpublic preview No
Resource governor No Yes
RESTORE statements No Yes - seeRestore differences
tion#restore-statement)

Restore database from backup From automated backups only - From automated backups -
seeSQL Database recovery seeSQL Database recover
sql-database-recovery-us-
ing-backups)y and from full
backups - seeBackup differenc-
es (https://docs.microsoft.com/
tion#backup)
Semantic search No No
Service Broker No Yes, but only within the instance.
SeeService Broker differences
service-broker)
Server configuration settings No Yes - seeT-SQL differences
Set statements Most - see individual statements Yes - seeT-SQL differences
SMO Yes Yesversion 150(preview)
(https://www.nuget.org/packages/
Microsoft.SqlServer.SqlManage-
mentObjects)
SQL Data Sync Yes No
SQL Server Agent No - seeElastic jobs Yes - seeSQL Server Agent
differences (https://docs.
mation#sql-server-agent)
SQL Server Analysis Services No -seeAzure Analysis Services No - seeAzure Analysis Servic-
(SSAS) es (https://azure.microsoft.com/
services/analysis-services/)

SQL Server Auditing No - seeSQL Database auditing Yes - seeAuditing differences
tion#auditing)
SQL Server Integration Services Yes, with a managed SSIS in Yes, with a managed SSIS in
(SSIS) Azure Data Factory (ADF) Azure Data Factory (ADF)
environment, where packages environment, where packages
are stored in SSISDB hosted by are stored in SSISDB hosted by
Azure SQL Database and Managed Instance and executed
executed on Azure SSIS Integra- on Azure SSIS Integration
tion Runtime (IR), seeCreate Runtime (IR), seeCreate Az-
Azure-SSIS IR in ADF (https:// ure-SSIS IR in ADF (https://docs.
docs.microsoft.com/azure/ microsoft.com/azure/data-facto-
data-factory/create-azure-ssis-in- ry/create-azure-ssis-integra-
tegration-runtime). tion-runtime).
SQL Server Management Studio Yes Yesversion 18.0 and higher
(SSMS) (https://docs.microsoft.com/sql/
ssms/download-sql-server-man-
agement-studio-ssms#ssms-180-
rc1)
SQL Server Profiler No - seeExtended events Yes
SQL Server Replication Transactional and snapshot Yes, inpublic preview (https://
replication subscriber only docs.microsoft.com/sql/relation-
al-databases/replication/replica-
tion-with-sql-database-man-
aged-instance)
SQL Server Reporting Services No -see Power BI (https://docs. No -see Power BI (https://docs.
(SSRS) microsoft.com/power-bi/) microsoft.com/power-bi/)
System stored functions Most - see individual functions Yes - seeStored procedures,
gers)
System stored procedures Some - see individual stored Yes - seeStored procedures,
procedures functions, triggers differences
gers)

System tables Some - see individual tables Yes - seeT-SQL differences
System catalog views Some - see individual views Yes - seeT-SQL differences
Temporary tables Local and database-scoped Local and instance-scoped
global temporary tables global temporary tables
Time zone choice No Yes(preview) (https://docs.
microsoft.com/azure/sql-data-
base/sql-database-managed-in-
stance-timezone)
Trace flags No No
Transparent data encryption Yes - General Purpose and Yes (https://docs.microsoft.com/
(TDE) Business Critical service tiers only en-us/azure/sql-database/
transparent-data-encryption-az-
ure-sql)
VNet Partial - seeVNet Endpoints Yes, Resource Manager model
(https://docs.microsoft.com/ only
sql-database-vnet-service-end-
point-rule-overview)
Windows Server Failover Cluster- High availability (https://docs. High availability (https://docs.
ing microsoft.com/en-us/azure/ microsoft.com/en-us/azure/
base-high-availability) is includ- base-high-availability)is included
ed with every database. Disaster with every database. Disaster
recovery is discussed in Over- recovery is discussed inOver-
Create an Azure SQL Database

In order to create a single database in Azure SQL Database using the Azure portal, perform the following
steps:
Create an Azure SQL Database - Single Database configu-

ration
1. Sign in to the Azure portal2 with your subscription
2. Select Create a resource in the upper-left corner of the Azure portal.
3. Locate managed instance, and then select SQL Database.
4. Select Create.
5.
6. On the Basics tab, in the Project Details section, type or select the following values:
● Subscription: Drop down and select the correct subscription, if it doesn't appear.
● Resource group: Select Create new, type cto, and select OK.
2 https://portal.azure.com
● `
7. In the Database Details section, type or select the following values:
● Database name: Enter mySampleDatabase.
● Server: Select Create new and enter the following values and then select Select.
● Server name: Type mysqlserver; along with some numbers for uniqueness.
● Server admin login: Type azureuser.
● Password: Type a complex password that meets password requirements.
● Location: Choose a location from the drop-down, such as West US 2.
●
8. In the “Want to use SQL elastic pool”: Select the No option.
9. In Compute + storage: Select Configure database and for this quickstart, select vCore-based pur-
chasing options
10.
11. Select Serverless.
12.
● Review the settings for Max vCores, Min vCores, Auto-pause delay, and Data max size. Change
these as desired.
● Accept the preview terms and click OK.
● Select Apply.
13. Select the Additional settings tab.
14. In the Data source section, under Use existing data, select None.
15. Leave the rest of the values as default and select Review + Create at the bottom of the form.
16. Review the final settings and select Create.
17. On the SQL Database form, select Create to deploy and provision the resource group, server, and
database.
Lesson Summary
In this lesson you explored the considerations for migrating SQL Server workloads to Azure SQL Data-
base. You also explored the benefits of moving to this platform and the tools that you should use to plan
your migration.
Learning objectives
● Understand the migration benefits of Azure SQL Database
● Migration planning specific to Azure SQL Database
● Create an Azure SQL Database
Important
Knowledge Check
Question 1
You planning to deploy multiple single Azure SQL Database to support a new application. Your company
currently licenses its SQL Server Enterprise Core licenses with Software Assurance (SA) coverage. Which
purchasing option allows you to use your SQL Server Enterprise Cores licenses to pay for Azure SQL Data-
base?
 DTU purchasing model
 vCore purchasing model
Question 2
Your company decides to deploy an Azure SQL Database under the DTU purchasing model. What does DTU
stand for?
 Database Throughput Unit
 Database Transaction Unit
Migrating to Azure SQL Database 131
Migrating to Azure SQL Database

Lesson 2: Migrate to Azure SQL Database
In this lesson, the focus is on the tools and methods for migrating SQL Server databases to Azure SQL
Database. You will cover evaluating a database migration approach and explore both offline and online
migration methods
Learning objectives
● Evaluate SQL Database migration
● Migrate using the Data Migration Assistant
● Migrate using BACPAC
● Migrate using Transactional Replication
Evaluating Azure SQL Database Migrations

There are two primary methods for migrating a SQL Server 2005 or later database to a single or pooled
database in Azure SQL Database. The first method is simpler but requires some, possibly substantial,
downtime during the migration. The second method is more complex, but substantially eliminates
downtime during the migration.
It is assumed that all pre-migration checks have been performed with the Data Migration assistant and
the Database Experimentation Assistant to ensure that feature and compatability issues have been
addressed and that workloads have been simulated.
There are a wide variety of compatibility issues that you might encounter, depending both on the version
of SQL Server in the source database and the complexity of the database you are migrating. Older
versions of SQL Server have more compatibility issues. Use the following resources, in addition to a
targeted Internet search using your search engine of choices:
● SQL Server database features not supported in Azure SQL Database3
● Discontinued Database Engine Functionality in SQL Server 20164
● Discontinued Database Engine Functionality in SQL Server 2008 R27
Once you have the information you need, you can either migrate:
1. Using the Data Migration Assistant
2. Using BACPAC
3 https://docs.microsoft.com/en-us/azure/sql-database/sql-database-transact-sql-information
4 https://msdn.microsoft.com/library/ms144262%28v=sql.130%29
3. Using Transactional Replication
Migrate using the Data Migration Assistant

You can use the Data Migration Assistant to help migrate your SQL Server workload to a single or a
pooled Azure SQL database if your organization can tolerate downtime. There are five steps required to
perform this work:
1. Use the Data Migration Assistant to assess the database for compatability issues
2. Use the compatability report to prepare the fixes required in a Transact SQL script
3. Make a copy of the database that is transactionally consistent
4. Deploy the Transact SQL script with the fixes to the copy of the database
5. Migrate the database copy to a new Azure SQL Database by using the Data Migration Assistant.
6.
During the migration itself, there are a number of best practices that you can employ for the best
performance of importing the database into Azure SQL Database which includes:
● Choose the highest service tier and compute size that your budget allows to maximize the transfer
performance. You can scale down after the migration completes to save money.
● Minimize the distance between your BACPAC file and the destination data center.
● Disable auto-statistics during migration
● Partition tables and indexes
● Drop indexed views, and recreate them once finished
● Remove rarely queried historical data to another database and migrate this historical data to a
separate Azure SQL database. You can then query this historical data using elastic queries.
On completion of the migration, perform an update of all the statistics in the database
Migrate to Azure SQL Database using BACPAC

You can import a SQL Server database into a database in Azure SQL Database using a BACPAC file. You
can import the data from a BACPAC file stored in Azure Blob storage (standard storage only) or from local
storage in an on-premises location. To maximize import speed by providing more and faster resources,
scale your database to a higher service tier and compute size during the import process. You can then
scale down after the import is successful.
Import from a BACPAC file in the Azure portal

The Azure portal only supports creating a single database in Azure SQL Database and only from a
BACPAC file stored in Azure Blob storage.
1. To import from a BACPAC file into a new single database using the Azure portal, open the appropriate
database server page and then, on the toolbar, select Import database.
2.
3. Select the storage account and the container for the BACPAC file and then select the BACPAC file from
which to import.
4. Specify the new database size (usually the same as origin) and provide the destination SQL Server
credentials.
5. Click OK.
6. To monitor an import's progress, open the database's server page, and, under Settings, select
Import/Export history. When successful, the import has a Completed status.
7.
You could also use SqlPackage to perform of an import of a bacpac file as it is more performent that
using the Azure Portal method. The following SqlPackage command imports the AdventureWorks2008R2
database from local storage to an Azure SQL Database server called mynewserver20170403. It creates a
new database called myMigratedDatabase with a Premium service tier and a P6 Service Objective.
Change these values as appropriate for your environment.
SqlPackage.exe /a:import /tcs:"Data Source=mynewserver20170403.database.

windows.net;Initial Catalog=myMigratedDatabase;User Id=<your_server_admin_
account_user_id>;Password=<your_server_admin_account_password>" /sf:Adven-
tureWorks2008R2.bacpac /p:DatabaseEdition=Premium /p:DatabaseServiceObjec-
tive=P6
Migrate to Azure SQL Database using Transac-

tional Replication
Where the source system is “Business Critical” and must remain online throughout the migration, Trans-
actional replication can copy the data to the Azure SQL database using an initial snapshot and then keep
the source and target systems in sync until the final cut-over takes place. Configuration of transactional
replication is performed through SQL Server management Studio or by executing Transact-SQL state-
ments on the publisher. The process for seeting this up is the same as the previous module using the
folowing components:
Publisher: database instance that hosts the data to be replicated (Source)
Subscriber(s): database instance that receives the data being replicated by the Publisher (Target(s))
Distributor: database instance that stores the replication changes made at the Publisher (Source) that are
required at the Subscriber(s) (Target(s))
Article: a database object e.g. Table that is included in the Publication
Publication: a collection of one or more articles from the database being replicated
Subscription: a request from a Subscriber for a Publication from a Publisher
However, The publisher and distributor must be at least:
Version
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x) SP1 CU3
SQL Server 2014 (12.x) RTM CU10
SQL Server 2012 (11.x) CU8 or SP3
Transactional Replication Considerations

● Replicated tables must have a primary key
● Transactional replication cannot be configured from the Azure Portal
● Using the latest version of SQL Server management tools is recommended
● The roles that can be used with Azure SQL Database are as follows
Role Single and Pooled databases Instance databases

Publisher No Yes
Distributor No Yes
Pull Subscriber No Yes
Push Subscriber Yes Yes
Once the synchronization is complete and you are ready to migrate, change the connection string of your
applications to point them to your Azure SQL Database. Once transactional replication drains any
changes left on your source database and all your applications point to Azure DB, you can uninstall
transactional replication. Your Azure SQL Database is now your production system.
[!Note]
A pull subscription is not supported when the distributor is an Instance database and the subscriber is
not.
Lesson Summary
In this lesson, you focused on the tools and methods for migrating SQL Server databases to Azure SQL
Database. You covered evaluating a database migration approach and explored both offline and online
migration methods.
Learning objectives
● Evaluate SQL Database migration
● Migrate using the Data Migration Assistant
● Migrate using BACPAC
● Migrate using Transactional Replication
Important
Knowledge Check
Question 1
Before creating the Database Migration Service, which resource provider should be registed in your subscrip-
tion prior?
 Microsoft.DataMigration
 Microsoft.Cache
 Migration.DAta
 Microsoft.Migration
Question 2
Which of the tools would be the best to find compatability issues between the on-premises SQL Server and
Azure SQL Database managed instance?
Service continuity of Azure SQL Database 137
Service continuity of Azure SQL Database

Lesson 3: Service Continuity of Azure SQL Data-
base
In this lesson, you will explore the post migration steps that are required to ensure service continuity of
your database in the areas of backup, high availability, disaster recovery and scalability.
Learning objectives
In this lesson, you will learn:
● Define backup and recovery options for Azure SQL Database
● Define high availability options for Azure SQL Database
● Define disaster recovery options for Azure SQL Database
● Define service scalability options for Azure SQL Database
Define backup and recovery options for Azure

SQL Database
In Azure SQL Database, backups are taken automatically and kept between 7 and 35 days. Under the
DTU model, a databases under the Basic tier benefits from 7 day retention, whereas Standard and
Premium databases have 35 days retention. Under the vCore purchasing model, the default retention
period is 7 days but can be increased up to 35 days.
Backups are stored on Azure read access geo-redundant storage (RA-GRS), ensuring that they are still
available in the event of a data center outage. To provide a point-in-time restore (PITR) capability, Azure
SQL Database performs transaction log backups every 5-10 minutes, with differential backups being
taken every 12 hours. In addition to PITR, Geo-restore can be used to restore databases to another
geographical region, in the event of a region-wide outage.
Backups can be kept for longer than 35 days by leveraging the Long-Term Retention capability. This
allows weekly, monthly or yearly full backups to be kept for up to 10 years in RA-GRS storage containers.
This is ideal for organisations that have to meet legislative or regulatory requirements.
Platform backup feature comparison

Features Azure SQL DB Single/ Azure SQL DB Managed SQL Server on Azure
Elastic Instance VM
Automatic backups Yes Yes Options available to
configure
Point in time restore Yes Yes No
Backup retention 35 Days 7 days+ Depends
Use the Azure portal to configure long-term retention

policies and restore backups
1. In the Azure portal, select your SQL server and then click Manage Backups. On the Configure policies
tab, select the checkbox for the database on which you want to set or modify long-term backup
retention policies. If the checkbox next to the database is not selected, the changes for the policy will
not apply to that database.
2.
3. In the Configure policies pane, select if want to retain weekly, monthly or yearly backups and specify
the retention period for each.
4.
5. When complete, click Apply.
Define high availability options for Azure SQL

Database
Azure SQL Database high availability is provided out of the box to guarantee that your database is up
and running 99.99% of time, without worrying about the impact of maintenance operations and outages.
When the underlying SQL instance fails over, the downtime is not noticeable as long as you employ retry
logic within your application.
It is dependent on Service Fabric for failure detection and recovery, on Azure Blob storage for data
protection, and on Availability Zones for higher fault tolerance. In addition, Azure SQL database leverages
the Always On Availability Group technology from SQL Server for replication and failover. The combina-
tion of these technologies enables applications to fully realize the benefits of a mixed storage model and
support the most demanding SLAs.
There are two high-availability architectural models that are used in Azure SQL Database, which depends
on the service tier that you have selected for your Azure SQL Database:
Basic, Standard, and General Purpose service tier availabil-

ity
High Availability on this tier is achieved by using the high availability and reliability of the remote premi-
um storage tier in partnership with the ability to transfer the compute from the active node to other
nodes.
Premium and Business Critical service tier availability

High Availability on this tier is achieved by using a technology similar to Always On Availability Groups.
Both the compute and storage are replicated to additional nodes.
Platform High Availability feature comparison

Features Azure SQL DB Single/ Azure SQL DB Managed SQL Server on Azure
Elastic Instance VM
High availability Built-in Built-in User managed
Availability SLA 99.99% 99.99% 99.9%
Define disaster recovery options for Azure SQL

Database
Azure SQL Database provides the following business continuity capabilities:
● Active geo-replication - provides a readable secondary replica for a given database in the same or
different Azure region. Active-geo replication asynchronously replicates data by using the same
technology as Always On Availability Groups. Up to four secondary replicas are permitted, which can
also be used for read-only workloads. The failover process can be invoked by the application or via a
set of manual procedures using the Azure, PowerShell, Transact-SQL or the REST API.
● Auto-failover groups - builds on the capabilities of Active geo-replication by replicating and failing
over a group of databases on an Azure SQL Database server. This allows multiple databases to be
recovered in the event of an outage.
● Geo-restore - uses geo-redundant backups to recover a database to any Azure SQL Database server
in any region. Backups are stored on geo-replicated storage, which means there is a delay between
when the backup is taken and when it is replicated to the other region.
● To recover a single, pooled, or instance database to a point in time using the Azure portal, open the
page for your database and click Restore on the toolbar.
●
● To recover a deleted database using the Azure portal, open the page for your server and in the
Operations area, click Deleted databases.
●
● Zone-redundant databases - by default, replicas in the premium availability model are located in the
same physical data center. Azure Availability Zones allow different replicas to be hosted in different
zones (data centers) within the same region. This can be enabled at no extra cost since it doesn't
provide any extra database redundancy. However, since the zone redundant replicas are located in
different data centers, the increased network latency may impact the performance of some workloads.
Define service scalability options for Azure SQL

Database
Azure SQL Database supports vertical scaling, known as scale-up and scale-down as well as horizontal
scaling (scaling-out) known as Sharding (an architectural design pattern).
Single and Elastic Pool databases can be scaled-up and down to accommodate increases in application
workload. This may be at a particular point in the day, month or year when the workload peaks or
troughs. Scaling a database up or down will increase or decrease (respectively) the performance objec-
tive of the database.
Single and Elastic Pool databases can be Sharded. Sharding is where the data is distributed across
multiple databases (known as Shards). Each shard is an individual database, which contains data relevant
to that Shard. Relevance is dictated by the Sharding key, which is used to distribute the data via Data
Dependent Routing. Sharding is useful when parts of the data should only be available in different
regions, or where the connections should be load balanced.
Vertical scaling can be performed via the Azure Portal, PowerShell, T-SQL, Azure CLI or the REST API.
Horizontal scaling is performed via the Elastic Database Client Library. The Elastic Database Split-Merge
tool can also be used to split and merge Sharded databases.
Lesson Summary
In this lesson, you focused on the post migration work that has to be completed to ensure that there is
service continuity of the Azure SQL Database to meet business needs. You learned to ensure that the data
is protected, and that measures are in place to ensure the availabilibilty. scalability and recoverability of
the data.
Learning objectives
● Define backup and recovery options for Azure SQL Database
● Define high availability options for Azure SQL Database
● Define disaster recovery options for Azure SQL Database
● Define service scalability options for Azure SQL Database
Important
In this lesson, you will explore the post migration steps that are required to ensure service continuity of
your database in the areas of backup, high availability, disaster recovery and scalability.
Knowledge Check
Question 1
You want to restore an Azure SQL Database backup taken 10 days ago. The service tier for the database is
Standard. Can you restore the database from a backup taken 10 days ago?
 Yes
 No
Question 2
Your new application has a Service Level Agreement of 99.99999%. Will Azure SQL Database meet your SLA
requirement?
 Yes
 No
Module summary
Module Summary
In this module, you have looked at how you can migrate SQL Server workloads to Azure SQL Database.
You explored the pre migration considerations that need to be taken into account before performing a
migration and how to create a SQL Database. You then explored the different methods to perform an
offline and online migration and looked at ways to ensure service continuity of Azure SQL Database.
Learning objectives
● Considerations of migrating to Azure SQL Database
● Migrate to an Azure SQL Database
● Service Continuity to Azure SQL Database
Module summary 145
Answers
Question 1
You planning to deploy multiple single Azure SQL Database to support a new application. Your company
currently licenses its SQL Server Enterprise Core licenses with Software Assurance (SA) coverage. Which
purchasing option allows you to use your SQL Server Enterprise Cores licenses to pay for Azure SQL Data-
base?
 DTU purchasing model
■ vCore purchasing model
Explanation
The vCore purchasing model allows you to use your SQL Server Enterprise Cores licenses to pay for Azure
SQL Database
Question 2
Your company decides to deploy an Azure SQL Database under the DTU purchasing model. What does
DTU stand for?
■ Database Throughput Unit
 Database Transaction Unit
Explanation
DTU stands for Database Throughput Unit
Question 1
Before creating the Database Migration Service, which resource provider should be registed in your
subscription prior?
■ Microsoft.DataMigration
 Microsoft.Cache
 Migration.DAta
Explanation
The Microsoft.DataMigration resource provider should be registed in your subscription prior to creating the
Database Migration Service
Question 2
Which of the tools would be the best to find compatability issues between the on-premises SQL Server
and Azure SQL Database managed instance?
Explanation
The Data Migration Assistant would be the best tool to use to detect any compatability issues between the
on-premises SQL Server and Azure SQL Database managed instance.
Question 1
You want to restore an Azure SQL Database backup taken 10 days ago. The service tier for the database
is Standard. Can you restore the database from a backup taken 10 days ago?
■ Yes
 No
Explanation
Yes. In Azure SQL Database, backups are taken automatically and kept between 7 and 35 days.
Question 2
Your new application has a Service Level Agreement of 99.99999%. Will Azure SQL Database meet your
SLA requirement?
 Yes
■ No
Explanation
Module 5 Migrate SQL Workloads to Managed
Instance
Module introduction
Module Introduction
In this module, you will look at how you can migrate SQL Server workloads to SQL Database Managed
instance. It will begin by exploring the pre migration considerations that need to be taken into account
before performing a migration and how to create a SQL Database Managed Instance. You will then
explore the different methods to perform an offline and online migration. and how to handle the migra-
tions of encrypted databases. You will then look at ways in which you can synchrinize data to and from a
SQL Database Managed instance.
Learning objectives
In this module, you will learn the:
● Considerations of migrating to Azure SQL Database Managed Instance
● Migrate to an Azure SQL Database Managed Instance
● Synchronize data to Azure SQL Database Managed Instance
MCT USE ONLY. STUDENT USE PROHIBITED 148 Module 5 Migrate SQL Workloads to Managed Instance
Considerations of migrating to Azure SQL Da-

tabase managed instance
Lesson 1: What is SQL Database Managed In-
stance
Azure SQL Database Managed Instance is the newest SQL based Platform as a Service (PaaS) capability
that is a part of the Azure SQL Database. The Azure SQL Database family includes the single Azure SQL
Database, Azure SQL Database elastic pools, and Azure SQL Database Managed Instance. The goal of
Azure SQL Managed Instance is to provide SQL Server applications a fully managed PaaS experience in
the Azure cloud. Azure SQL Database Managed Instance is also a fully featured SQL PaaS experience with
all of the critical features and capabilities of the SQL Server platform.
Learning objectives
● Understand the migration benefits of Azure SQL Database Managed Instance
● Migration planning specific to Azure SQL Database Managed Instance
● Create an Azure SQL Database Managed Instance
What is SQL Database Managed Instance?

Azure SQL Database Managed Instance was purposefully designed to enable a ‘lift and shift’ solution for
customers looking to bring their applications, databases, and supporting technologies to Azure PaaS.
Previously, without Azure SQL Database Managed Instance, migration scenarios where an organization’s
application requires access to any technology outside of the database (e.g. SQL Agent jobs, cross data-
base joins, SQL Server Integration Services, etc.) would be prevented from moving to the cloud. The only
way the DBA / developer could migrate an on-prem application would be to employ one of the following
approaches:
1. Move the database and the supporting technologies to an Infrastructure as a Service (IaaS) model.
2. Begin rewriting the application to be built towards a fully Platform as a Service (PaaS) model on Azure
SQL Database with additional development to address migration blockers. (e.g. leveraging Azure Data
Factory over SSIS/DTS or leveraging Azure Automation over SQL Server Agent jobs.)
The discussion usually comes down to whether or not your organization has the resources and capabili-
ties to rewrite the application to fit into a PaaS model on Azure SQL Database. The organization also
would need control over the application code as vendors will usually not support any changes made to
their application. The result is that most organizations looking to migrate their applications to Azure
choose SQL Server on IaaS as the only way to get the full SQL Server experience in Azure while avoiding
the overhead of rewriting their current applications.
While Azure SQL Database is powerful, most existing applications have too many technologies that exist
outside the database scope leading to vendor support challenges and expensive development cycles that
most organizations cannot support. Azure SQL Database Managed Instance, code named ‘Cloud Lifter’,
was specifically designed to eliminate these blockers to migrating your application databases to a SQL
based PaaS solution in Azure without having to redesign your application.
Considerations of migrating to Azure SQL Database managed instance 149
Backwards Compatibility
Azure SQL Database Managed Instance also provides backwards compatibility to SQL Server 2008
databases. Direct migration from SQL Server 2005 database servers is also supported, with the compati-
bility level for migrated SQL Server 2005 databases being updated to SQL Server 2008. This is important
as SQL Server 2005 has been out of mainstream since 4/12/2011 and out of extended support since
4/12/2016. SQL Server 2008/R2 is already out of mainstream support since 7/8/2014 and will be out of
extended support on 7/9/2019.
Azure SQL Database Managed Instance also provides access to newer technologies. As of this writing SQL
Server 2019 CTP 3.0 is being evaluated and SQL Server 2019 is not yet generally available. However, in
Azure SQL Database and Azure SQL Database Managed Instance you can take advantage of database
compatibility level 150 today that enables many additional capabilities.
For a reference of the database compatibilities and the differences between them, use the following
reference1.
Easy Lift and Shift – Nearly 100% compatible to SQL Serv-

er
Azure SQL Database Managed Instance provides a Platform as a Service (PaaS) option with nearly 100%
compatibility to SQL Server and the supporting technologies that most applications need. The nearly
100% compatibility to SQL Server includes core SQL Server components, programmability enhancements,
and instance scoped features such as cross database joins, and management tools that most existing SQL
based applications need in order to function correctly. Ultimately, SQL Database Managed Instance
enables database migration to a fully managed database service, without re-designing the application.
Fully Managed Platform as a Service (PaaS)

The strength of SQL Database Managed Instance is that it’s a blend of the best features of SQL Server
and Azure SQL Database with a target towards application portability. The full set of Azure based features
includes security, performance, monitoring as well as the features of the most recent version of SQL
1 https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-2017#differences-
between-compatibility-level-140-and-level-150
Server, including online operations, automatic plan corrections, and other enterprise performance
enhancements that are enabled in part by the individual database compatibility level.
PaaS benefits includes removing the need for managing hardware and all the overhead that comes from
having to perform physical maintenance on SQL server machines. You also have the benefits of quickly
scaling up and scaling down as well as quickly provisioning resources in the cloud. The SQL Server
operating system, commonly known as the SQLOS is maintained by PaaS with automated patching and
version upgrades. Automated patched, also known as Evergreen, is simply part of the Platform as a
Service model making integration with other platform as a service technology seamless.
Examples of technologies that are present at the database level for Azure SQL Managed Instance includes
Advanced Threat Protection, Data Discovery and Classification, and the Vulnerability Assessment. The
configuration of these features is made at the Managed Instance scope. There is also the ability to
individually configure backup retention at the Azure SQL Managed Instance Database level.
Azure SQL Database Managed Instance also supports all of the strong Azure core features as well such as
Azure Advisor, Azure Monitor, Azure Security Center, secure Activity Log support, support for Azure
Active Directory, tagging and more features. Azure has built-in high availability, monitoring, security, and
more that extends the power of Azure SQL Database Managed Instance as a PaaS technology.
Azure SQL Database Managed Instance security features

You have the capabilities of enabling Advanced Data Security features at the SQL Database Managed
Instance scope just as you do at the database level. These features include the Vulnerability Assessment
and the Advance Threat Protection settings. You also can enable specific Advanced Threat Detection
features and schedule periodic recurring scans that can send security reports to administrators. Finally, at
the Managed Instance level you can configure Transparent Data Encryption and whether you want to
leverage your own key (BYOK) for encryption.
Secure Network Isolation

One of the unique aspects of manage instance is the ability of network security isolation where Managed
Instance has complete security isolation from any other tenant in the Azure cloud. In your typical default
deployment with Azure SQL Managed Instance the SQL endpoint for Managed Instance is exposed only
through a private IP address only allowing connectivity from private Azure networks or hybrid networks.
For on-prem applications to connect to Azure SQL Manage Instance it would require an Azure Express-
Route configuration or a VPN gateway. Recent virtual network capabilities have been added to Managed
Instance allowing the enablement of a public endpoint that would expose your databases to the Internet.
If you enable the public endpoint data access for clients outside of the connected virtual networks will be
allowed.
Instance Failover Groups

Finally, you can enable Instance Failover Groups at the Managed Instance scope. Instance Failover Groups
is a group of databases managed by a single database server or within a single manage instance that can
fail over as a unit to another region in the case all or some of the primary databases have gone offline
due to an outage in the primary region.
This will failover the group containing the user databases in the instance. Only one failover group can be
configured on an instance.
Note: For additional depth on Azure features outside the Azure SQL Database, Azure SQL Database
Managed Instance, and SQL Server on IaaS it is recommended to get the foundational knowledge in the
Azure Fundamentals course (AZ-900) and more depth in the Microsoft Azure Administrator course
(AZ-103).
Tools to support your migration planning to Az-

ure SQL Database Managed Instance
SQL Database Managed Instance.
1. Microsoft Planning and Assessment-Use this tool in the discovery stage to confirm the source
environment that you are migrating from. This helps you to understand the configuration of your
source SQL Server, how many instances are installed and the components that are running on each
instance. In addition, you can use the tool to confirm the version and configuration of the Windows
Server that it is running on.
2. Azure Database Migrate Service-The Azure Database Migrate Service enables you to perform large
scale database migration from within the Azure Portal. Azure Database Migration Service integrates
some of the functionality of existing tools and services to provide customers with a comprehensive,
highly available solution. The tools include:
3. Data Migration Assistant-Use the Data Migration Assistant in the planning and assessment stage of
a Data Platform Modernization project to check for compatibility issues that can impact database
functionality in SQL Database Managed Instance. You should also use it to review performance and
reliability improvements for your target environment prior to performing the migration so that you
can incorporate them into your plan.
4. Database Experimentation Assistant-If you have concerns surrounding the workloads that will be
operating on the target server, then use the Database Experimentation Assistant to assess if your
target server can handle the workload. Customers who are upgrading from earlier SQL Server versions
to a more recent version of SQL Server on Azure Virtual Machines, can use the analysis metrics to give
comparison data to allow you to make decisions on whether the targeted version would provide a
better experience after a migration.
Migration Planning for Azure SQL Database

Managed Instance
In addition to the feature comparison that was made between the different Azure SQL Database configu-
rations in the previous module, there are areas that should be considered that are specific to migrating
your SQL Server Workload to Azure SQL Database Managed Instance.
Licensing
There are six types of subscription models that can be used for Azure SQL Database Managed Instance.
You should assess which on is the most appropriate for your migration scenario.
● Enterprise Agreement (EA)
● Pay-as-you-go
● Cloud Service Provider (CSP)
● Enterprise Dev/Test
● Pay-As-You-Go Dev/Test
● Subscriptions with monthly Azure credit for Visual Studio subscribers
Managed Instance Sizing

There are two generations of Azure SQL Database Managed Instance that have hardware limitations, you
should choose the version that will meet your needs
Gen4 Gen5
Hardware Intel E5-2673 v3 (Haswell) Intel E5-2673 v4 (Broadwell)
2.4-GHz processors, attached 2.3-GHz processors, fast NVMe
SSD vCore = 1 PP (physical core) SSD, vCore=1 LP (hyper-thread)
vCores 8, 16, 24 vCores 4, 8, 16, 24, 32, 40, 64, 80 vCores
Memory (memory/core ratio) 7 GB per vCore 5.1 GB per vCore
Max In-Memory OLTP memory ● Instance limit: 3 GB ● Instance limit: 2.5 GB
per vCore per vCore
● Database limits: ● Database limits:
● 8-core: 8 GB per ● 8-core: 13 GB per
database database
● 16-core: 20 GB per ● 16-core: 32 GB per
database database
● 24-core: 36 GB per
database
Max instance storage (General 8 TB 8 TB
Purpose)
Max instance storage (Business 1 TB 1 TB, 2 TB, or 4 TB depending on
Critical) the number of cores
In addition to selecting the generation of the Azure SQL Database Managed Instance, you also have to
select a service tier. General Purpose and Business Critical
These tiers provide different capabilities, as described in the table below:
Feature General Business

Purpose Critical
Number of
vCores*
Memory
Max instance ● 2 Max storage Determined by Determined by
storage size TB per database the max the max
for storage size storage size
per instance per instance
Max number of 100 100
databases per
instance
Max database Up to 280 32,767 files per
files per database
instance
Feature General Business

Purpose Critical
Data/Log IOPS 500 - 7,500 per 11 K - 110 K
(approximate) file *Depends (1375/vCore)
on the file size
Log through- 3 MB/s per 4 MB/s per
put vCore - Max 22 vCore - Max 48
MB/s per MB/s per
instance instance
Data through- 100 - 250 MB/s N/A
put (approxi- per file - De-
mate) pends on the
file size
IO latency 5-10 ms 1-2 ms
(approximate)
Max tempDB 192 - 1,920 GB No constraints
size (24 GB per - limited by the
vCore) max instance
storage size
Max sessions 30000 30000
Database Compatibility
In order for older databases to run on new versions of SQL Server, there is a feature within SQL Server
known as Database Compatibility levels. You need to know the latest supported compatibility level of the
application that is using SQL Server. Each version of SQL Server introduces a new set of features and
changes, and to ensure that app is using Transact-SQL queries with the right syntax and invoked stored
procedures in the right way, it uses the concept of compatibility levels. SQL Server 2000 has default
compatibility level 80, and each next version of SQL Server has +10 compatibility by default (up to 150 for
SQL Server 2019).
SQL Server 2017 supports compatibility levels from 100 (default for SQL Server 2008) to 140 (default for
SQL Server 2017). If your application requires compatibility level 100 (default for SQL Server 2008), and
you use SQL Server 2014 - you can safely move to SQL Database Managed Instance. But if you use an
application with compatibility level 80, running on SQL Server 2008 (which supported that compatibility
level, which is default for SQL Server 2000), you won't be able to move it to SQL MI since it supports com-
patibility levels 100 and newer. In this situation, you will have to migrate from compatability level 80 to
100 before you can move the database to an Azure SQL Database Managed Instance.
Networking
Azure SQL Database Managed Instance must be deployed within an Azure virtual network and the subnet
dedicated for Managed Instances only. The SQL Database Managed Instance is fully isolated. The com-
pute and storage are placed in a virtual cluster which is fully isolated from all other tenants in Azure.
You can connect your on-premise resources using VPN tunneling or a route gateway to SQL Database
Managed Instances and you can then use them as any other instances in your network. By connecting
your on-premise resources to SQL Database Managed Instance in this way, you can use SQL Database
Managed Instance as an extension of your on-premise data center.
Additionally, if you have any back-end subnets or front-end subnets in your on-premise network you can
establish VNET to subnet connections between these networks. You can then use SQL connections from
your web applications or link Azure SQL Managed Instance to your on-prem database. SQL Database
Managed Instance then becomes just an extension to your on-prem SQL solution and your organization’s
on-prem network.
Application considerations
When you have migrated your SQL Server database to Azure SQL Database Managed Instance, you need
to decide where to host the applications that work with the database. Leaving the applications on-prem-
ises, whilst the database is in Azure will lead to latency issues. As a result, you will want to consider
moving your applications onto Azure as well to keep it close to the database
Automated Backups
You need to check that the automated backup schedules work for your organization. SQL database and
Manage Instance automatically creates database backups that are kept between 7 and 35 days, Azure
read-access and geo-redundant storage is used to make sure that they are preserved even if the data
center is unavailable. This capability is built-in as part of the Azure SQL Database / Managed Instance
experience. If you need backups to be available for an extended period of time (up to 10 years) you can
configure long term retention on single database.
SQL Database create full backups every week, differential backups every 12 hours, and transaction log
backups every 5-10 minutes. The backups are stored in RA-GRS storage blobs that are replicated to a
paired data center for protection against a data center outage. When you restore a database, the service
figures out which full, differential, and transaction log backups need to be restored.
COPY_ONLY backups is the only manual method that is allowed. The reason for this is that the transaction
log must be preserved for the automated backup operations and the point in time restore operations in
Azure SQL database / Managed Instance.
Create an Azure SQL Database managed in-

stance
In order to create an Azure SQL Database managed instance perform the following steps:
Create an Azure SQL Database Managed Instance

1. Sign in to the Azure portal2 with your subscription
2. Select Create a resource in the upper-left corner of the Azure portal.
3. Locate managed instance, and then select Azure SQL Managed Instance.
4. Select Create.
5.
6. Fill out the SQL managed instance form with the requested information by using the information in
the following table.
Setting Suggested value Description

Subscription Your subscription. A subscription that gives you
permission to create new
resources.
Managed instance name Any valid name. For valid names, see Naming
rules and restrictions.
Managed instance admin login Any valid username. For valid names, see Naming
rules and restrictions. Don't use
“serveradmin” because that's a
reserved server-level role.
Password Any valid password. The password must be at least
16 characters long and meet the
defined complexity require-
ments.
Time zone The time zone to be observed by For more information, see Time
your managed instance. zones.
2 https://portal.azure.com

Collation The collation that you want to If you migrate databases from
use for your managed instance. SQL Server, check the source
collation by using SELECT
SERVERPROPERTY(N'Collation')
and use that value. For informa-
tion about collations, see Set or
change the server collation.
Location The location in which you want For information about regions,
to create the managed instance. see Azure regions.
Virtual network Select either Create new virtual If a network or subnet is unavail-
network or a valid virtual able, it must be modified to
network and subnet. satisfy the network requirements
before you select it as a target
for the new managed instance.
For information about the
requirements for configuring the
network environment for a
managed instance, see Configure
a virtual network for a managed
instance.
Enable public endpoint Check this option to enable For managed instance to be
public endpoint accessible through the public
data endpoint, Enable public
endpoint needs to be checked.

Allow access from Select either: Portal experience enables
configuring security group with
● Azure services
public endpoint. Based on your
● Internet scenario, select one of the
● No access following options:
● Azure services -
recommended
when connecting
from Power BI or
other multi-ten-
ant service.
● Internet - use for
test purposes
when you want
to quickly spin up
a managed
instance. It’s not
recommended
for use in
production
environments.
● No access - this
option creates a
deny security
rule. You’ll need
to modify this
rule in order to
make managed
instance accessi-
ble through
public endpoint.
Connection type Choose between a Proxy and a For more information about
Redirect connection type. connection types, see Azure SQL
Database connection policy.
Resource group A new or existing resource For valid resource group names,
group. see Naming rules and restric-
tions.
7.
8. To use the managed instance as an instance failover group secondary, select the checkout and
specify the DnsAzurePartner managed instance. This feature is in preview and isn't shown in the
following screenshot.
9. Select Pricing tier to size compute and storage resources and to review the pricing tier options. The
General Purpose pricing titext boxes to specify the amount of storage and the number of virtual
cores.
10. When you're finished, select Apply to save your selection.
11. Select Create to deploy the managed instance.
12. Select the Notifications icon to view the status of the deployment.
13.
14. Select Deployment in progress to open the managed instance window to further monitor the deploy-
ment progress.
Review resources and retrieve your fully qualified server

name
After the deployment is successful, review the resources that are created and retrieve the fully qualified
server name for use in later quickstarts.
1. Open the resource group for your managed instance. View its resources that were created for you in
the create a managed instance quickstart.
2.
3. Select the route table to review the user-defined route (UDR) table that was created for you.
4.
5. In the route table, review the entries to route traffic from and within the managed instance virtual
network. If you create or configure your route table manually, you must be sure to create these entries
in the route table.
6.
7. Return to the resource group, and select the network security group to review the security rules.
8.
9. Review the inbound and outbound security rules. If you have configured public endpoints for your
managed instance, see the article Configure public endpoint3 for more information.
3 https://docs.microsoft.com/en-gb/azure/sql-database/sql-database-managed-instance-public-endpoint-configure#allow-public-endpoint-
traffic-on-the-network-security-group
10.
11. Return to the resource group, and select your managed instance
12.
13. On the Overview tab, locate the Host property. Copy the fully qualified host address for the
managed instance.
14.
Lesson Summary
In this lesson, you learned the goal of Azure SQL Managed Instance is to provide SQL Server applications
a fully managed PaaS experience in the Azure cloud. That Azure SQL Database Managed Instance is also a
fully featured SQL PaaS experience with all of the critical features and capabilities of the SQL Server
platform.
Learning objectives
● The migration benefits of Azure SQL Database Managed Instance
● The tools to support your migration planning
● Migration planning specific to Azure SQL Database Managed Instance
● How to create an Azure SQL Database Managed Instance
Important
Knowledge Check
Question 1
What is the lowest compatibility level that is supported by Azure SQL Database Managed Instance?
 SQL Server 2005
 SQL Server 2008
 SQL Server 2008 R2
 SQL Server 2012
Question 2
Which of the tools can be used to centralize the management and execution of a migration to Azure SQL
Database Managed Instance?
Migrating to Azure SQL Database managed

instance
Lesson 2: Migrate to SQL Database Managed
instance
In this lesson, the focus is on the tools and methods for migrating SQL Server databases to Azure SQL
Database Managed Instance. We will cover evaluating a database migration approach, choosing the
correct migration method, and breaking down the migration process. Finally, we will focus on how
encryption can impact your migration strategy.
Learning objectives
● Evaluate SQL Database Managed Instance Compatibility
● Migrate using Backup / Restore from URL
● Managing encrypted databases
● Migrate using Database Migration Service
Evaluating SQL Database Managed Instance

Compatibility
In the previous lesson we discussed the compatibility options between Azure SQL Database, SQL Data-
base Managed Instance, and SQL Server VMs. In this lesson we are focusing on the migration process and
migration methods specifically targeted to SQL Database Managed Instance. Before you start moving
databases from your on-prem SQL Server environment it is important to address any compatibility
concerns.
Is SQL Database Managed Instance compatible with my

application
The managed instance deployment option is designed to provide an easy lift and shift migration experi-
ence for most of the applications that use SQL Server on-premises or on virtual machines. However, you
may sometimes require features or capabilities that are not yet supported and the cost of implementing a
workaround is too high.
Features such as cross-database queries, cross-database transactions within the same instance, linked
servers, CLR, global temp tables, instance level views, Service Broker and more are not supported on
Azure SQL Database but are supported with SQL Database Managed Instance. A single feature can cause
you to choose a different migration path for your application. In many cases, the perceived complexity of
migrating large databases and addressing technology blockers has led many organizations to the
decision that they should keep the database on-prem.
Many organizations also see the migration process as too complex and they abandon their migration
efforts because they don’t know how to find out their compatibility level, how to find and resolve block-
ers, and what methods should be used to migrate their databases and the supporting technologies to
Migrating to Azure SQL Database managed instance 167
Azure. Fortunately, Microsoft has created a number of tools to evaluate Azure compatibility and address
migration challenges.

Use Data Migration Assistant (DMA) to detect potential compatibility issues impacting database function-
ality on Azure SQL Database, SQL Managed Instance, SQL Server, and SQL Server IaaS virtual machines.
With DMA you get the ability to perform a migration assessment as well as executing a migration project.
As of DMA 4.3, Data Migration Assistant supports managed instance as an assessment option as well as a
migration destination.
The result of a Data Migration Assistant project is a report of the equivalent features between your source
and destination and a list of any compatibility issues.
Running a Data Migration Assessment

In the steps below, we will execute a simple Data Migration Assistant assessment and examine the output
of the scan. One of the benefits of running an assessment is that you are doing all of the work on the
source system. You are simply evaluating the migration. This project type does not require that you
connect to the destination location.
1. Open Data Migration Assistant
2. Create a new project
3. Choose assessment as the project type
4. Give the project a name so you can go back and evaluate previous executions
5. Next select the source server type and select the target server type. In this case we are choosing
SQL Server as the source server type and the target server type is Azure SQL Database Managed
Instance.
6. Click Create
7.
8. Select the report types. In this case we will check both database compatibility and feature parity.
9.
10. Connect to your source system. In this case we chose SQL Server which is a SQL Server 2017 environ-
ment in this example. We are going with the default authentication type. Click Connect.
11.
12. Next choose the databases that you would like analyzed. Click Add.
13.
14. Click Start Assessment
15.
When you get the output you will have the options to examine SQL Server feature parity and the compat-
ibility issues. We are first examining the SQL Server feature parity report.
Since we chose Managed Instance as our destination, we are seeing a very small list of features that do
not have parity with SQL Server. In our example the only reported issue that PowerShell is not a support-
ed job step type in Azure SQL Managed Instance.
Select ‘Compatibility issues’. You now have a report of all of the compatibility issues per database and for
each applicable database compatibility level. Also note that the output is broken down by breaking
change, behavior change, deprecated feature, and information issues.
The details are given along with the affected objects. You can then open the supporting documentation
and address the issues. Once you have addressed the issues found in the DMA output you should run the
assessment again to ensure that all of the breaking changes are addressed. It is often helpful to complete
a test migration to a non-production system in order to address the behavior changes. In order to
understand the impact of the behavior changes it is important to take note of which technologies and
objects are affected and carefully examine application behavior and the error log / extended events to
ensure the behavior changes are not going to lead to any supportability challenges.
The process of assess, address, and reassess is the best method to ensure that your database migration
completes successfully.
Breaking Changes
If there are some reported blocking issues that are not removed with the managed instance deployment
option, you might need to consider an alternative option, such as SQL Server on Azure virtual machines.
Here are some examples:
● If you require direct access to the operating system or file system, for instance to install third party or
custom agents on the same virtual machine with SQL Server.
● If you have strict dependency on features that are still not supported, such as FileStream / FileTable,
PolyBase, and cross-instance transactions.
● If absolutely you need to stay at a specific version of SQL Server (2012, for instance).
● If your compute requirements are much lower that managed instance offers (one vCore, for instance)
and database consolidation is not acceptable option.
Migrate using Backup and Restore from URL

The managed instance deployment option is an optimal choice when you need to ‘lift and shift’ applica-
tions designed to run on SQL Server that heavily use instance level and / or cross-database functionali-
ties.
Managed instance supports the database migration options for both offline and online migrations. If you
are willing to accept downtime, the restore of a database from a url is a valid method to perform an
offline migration. RESTORE of native backups (.bak files) taken from SQL Server, via Azure Storage, and
finally to Azure SQL MI is one of key capabilities of the managed instance deployment option that
enables quick and easy offline database migration. The migration flow is as follows:
Restore the database from a backup file

In SQL Server Management Studio (SSMS), follow these steps to restore a database to your Managed
Instance. The database backup file is stored in a pre-configured Azure Blob storage account.
1. Open SMSS and connect to your Managed Instance.
2. From the left-hand menu, right-click your Managed Instance and select New Query to open a new
query window.
3. Run the following SQL script, which uses a pre-configured storage account and SAS key to create a
credential in your Managed Instance.
4. CREATE CREDENTIAL [https://mtutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = 'add your shared access signature here'
5. To check your credential, run the following script, which uses a container URL to get a backup file list.
6. RESTORE FILELISTONLY FROM URL =
'https://mtutorials.blob.core.windows.net/databases/dbbu.bak'
7. Run the following script to restore the database.

8. RESTORE DATABASE [database name] FROM URL =
'https://mtutorials.blob.core.windows.net/databases/dbbu.bak'
9. Run the following script to track your restore's status.

10. SELECT session_id as SPID, command, a.text AS Query, start_time, percent_
complete
, dateadd(second,estimated_completion_time/1000, getdate()) as estimat-
ed_completion_time
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
11. When the restore completes, view it in Object Explorer.

It is important to remember that the migration of instance-level objects that your application depends
on, including logins, credentials, SQL Agent Jobs and Operators, and server level triggers should be
evaluated by using DMA where you may also need to script out some of the dependencies and make
adjustments to ensure compatibility is addressed.
Managing Encrypted Databases

Transparent Data Encryption (TDE) is a SQL Server technology that ensures databases are encrypted at
rest and can only be read when the certificate used to encrypt the data is leveraged to decrypt the
database and database backups at the destination. By enabling TDE customers are further ensuring the
databases are secure in transit to their destination in the Azure cloud. When migrating a database
protected by TDE to a managed instance using native restore, the certificate from the on-premises SQL
Server must be migrated before database restore.
Note: After the TDE certificate is used to decrypt the database in Azure for the restore, the migrated
certificate gets replaced by either service-managed certificate or asymmetric key from the key vault,
depending on the type of the transparent data encryption you set on the instance.
In order to address TDE enabled databases you can either leverage Azure Database Migration Service
(DMS) or take the manual approach of decrypting the database backups using a certificate export tool
and PowerShell.
Manually migrate the certificate of TDE protected data-

base to Azure SQL Database Managed Instance
In order to migrate the certificate of TDE databases to Azure SQL DB MI you will need the following:
● Pvk2Pfx is a command-line tool4 installed on the on-premises server. It requires access to the
certificate exported as a file.
● Windows PowerShell5 version 5.0 or higher must be installed.
● Azure PowerShell module must be installed and updated.
● You also need to install the Az.Sql module with following commands in PowerShell to install/update
the PowerShell module:
● ```Powershell
Install-Module -Name Az.Sql
Update-Module -Name Az.Sql
Export TDE certificate to a Personal Information Exchange

(.pfx) file.
The certificate should be exported directly from the source SQL Server, or from the certificate store.
1. Locate certificate details on the source SQL Server
● In SQL Server Management Studio (SSMS), open a new query window and connect to the source
SQL Server.
● Run the following Transact-SQL command to list TDE protected databases and get the name of the
certificate protecting encryption of the database to be migrated:
● USE master
GO
SELECT db.name as [database_name], cer.name as [certificate_name]

FROM sys.dm_database_encryption_keys dek
LEFT JOIN sys.certificates cer ON dek.encryptor_thumbprint = cer.thumb-
print
INNER JOIN sys.databases db ON dek.database_id = db.database_id
WHERE dek.encryption_state = 3
● The output of the query will give you the database name and the certificate for each database you
will get the full path details for the certificate from this script.
2. BACKUP the TDE Certificate
● In SSMS, execute the following script to export the certificate to a pair of files (.cer and .pvk),
keeping the public and private key information:
● USE master
GO
4 https://docs.microsoft.com/windows-hardware/drivers/devtest/pvk2pfx
5 https://docs.microsoft.com/powershell/azure/install-az-ps
BACKUP CERTIFICATE TDE_Cert

TO FILE = 'c:\full_path\TDE_Cert.cer’
WITH PRIVATE KEY (
FILE = 'c:\full_path\TDE_Cert.pvk’,
ENCRYPTION BY PASSWORD = '<SomeStrongPassword>’
)
3. Copy certificate to a Personal Information Exchange (.pfx)

● Use PowerShell console to copy certificate information from a pair of newly created files to a
Personal Information Exchange (.pfx) file, using Pvk2Pfx tool:
● .\pvk2pfx -pvk c:/full_path/TDE_Cert.pvk -pi "<SomeStrongPassword>"
-spc c:/full_path/TDE_Cert.cer -pfx c:/full_path/TDE_Cert.pfx
4. Upload certificate to Azure SQL Database Managed Instance using Azure PowerShell cmdlet
● The first script is a preparation step in PowerShell:
● # Import the module into the PowerShell session
Import-Module Az
# Connect to Azure with an interactive dialog for sign-in
Connect-AzAccount
# List subscriptions available and copy id of the subscription target
Managed Instance belongs to
Get-AzSubscription
# Set subscription for the session (replace Guid_Subscription_Id with
actual subscription id)
Select-AzSubscription Guid_Subscription_Id
● Run the following commands to upload base-64 encoded certificate to the target Managed
Instance:
● $fileContentBytes = Get-Content 'C:/full_path/TDE_Cert.pfx' -Encoding
Byte
$base64EncodedCert = [System.Convert]::ToBase64String($fileContentBytes)
$securePrivateBlob = $base64EncodedCert | ConvertTo-SecureString -As-
PlainText -Force
$password = "SomeStrongPassword"
$securePassword = $password | ConvertTo-SecureString -AsPlainText -Force
Add-AzSqlManagedInstanceTransparentDataEncryptionCertificate -Resource-
GroupName "<ResourceGroupName>" -ManagedInstanceName "<ManagedInstance-
Name>" -PrivateBlob $securePrivateBlob -Password $securePassword
The certificate is now available to the specified Managed Instance and backup of corresponding TDE
protected database can be restored successfully.
Transparent Data Encryption and Azure Key Vault

Transparent Data Encryption (TDE) with Azure Key Vault integration allows you to encrypt the Database
Encryption Key (DEK) with a customer-managed asymmetric key called the TDE Protector. This is also
known as Bring Your Own Key (BYOK) support for Transparent Data Encryption. With BYOK, the TDE
Protector is stored in a customer-owned and managed Azure Key Vault. This is Azure’s cloud-based
external key management system. The TDE Protector can be generated by the key vault or transferred to
the key vault from an on premises HSM device. The TDE database encryption key (DEK), which is stored
on the boot page of a database, is encrypted and decrypted by the TDE Protector stored in Azure Key
Vault, where it never leaves. SQL Database needs to be granted permissions to the customer-owned key
vault to decrypt and encrypt the DEK.
If permissions of the logical SQL server to the key vault are revoked, a database will be inaccessible, and
all data is encrypted. For Azure SQL Managed Instance, the TDE protector is set at the instance level and
it is inherited by all encrypted databases on that instance. With TDE with Azure Key Vault integration,
users can control key management tasks including key rotations, key vault permissions, key backups, and
enable auditing/reporting on all TDE protectors using Azure Key Vault functionality. TDE with Azure Key
Vault integration provides the following benefits:
● Increased transparency and granular control with the ability to self-manage the TDE protector
● Ability to revoke permissions at any time to render database inaccessible
● Central management of TDE protectors (along with other keys and secrets used in other Azure
services) by hosting them in Key Vault
● Separation of key and data management responsibilities within the organization, to support separa-
tion of duties
● Greater trust from your own clients, since Key Vault is designed so that Microsoft does not see or
extract any encryption keys.
● Support for key rotation
Creating the Azure Database Migration Service

The Azure Database Migration Service (DMS) is a fully managed service designed to enable seamless
migrations from multiple database sources to Azure Data platforms with minimal downtime. This service
streamlines the tasks required to move existing third party and SQL Server databases to Azure. DMS is a
free service that supports migrations of different databases to Azure database offerings. It can migrate
MySQL, PostgreSQL, MariaDB databases to Azure Database for MySQL/PostgreSQL/MariaDB, and it also
supports SQL Server migrations, including SQL MI.
The service uses the Data Migration Assistant to generate assessment reports that provide recommenda-
tions to guide you through the changes required prior to performing a migration. It's up to you to
perform any remediation required. When you're ready to begin the migration process, Azure Database
Migration Service performs all of the required steps. You can fire and forget your migration projects with
peace of mind, knowing that the process takes advantage of best practices as determined by Microsoft.
DMS is the recommended method of migration for your enterprise workloads, and will perform the
following steps when used
1. Create an instance of Azure Database Migration Service.
2. Create a migration project and start online migration by using Azure Database Migration Service.
3. Monitor the migration.
4. Cutover the migration when you are ready.
Azure Database Migration Service prerequisites

In order for this to work successfully, the following prerequisites must be met:
● Create an Azure Virtual Network (VNet) for the Azure Database Migration Service by using the Azure
Resource Manager deployment model, which provides site-to-site connectivity to your on-premises
source servers by using either ExpressRoute or VPN.
● If you use ExpressRoute with network peering to Microsoft, add the following service endpoints to the
subnet in which the service will be provisioned:
● Target database endpoint (for example, SQL endpoint, Cosmos DB endpoint, and so on)
● Storage endpoint
● Service bus endpoint
● You must provide the full database backup and subsequent log backups using the CHECKSUM option
in the SMB network share that the service can use to migrate your databases
● Provide an SMB network share that contains all your database full database backup files and subse-
quent transaction log backup files the Azure Database Migration Service can use for database migra-
tion.
● Ensure that the service account running the source SQL Server instance has write privileges on the
network share that you created and that the computer account for the source server has read/write
access to the same share.
● Make a note of a Windows user (and password) that has full control privilege on the network share
that you previously created. The Azure Database Migration Service impersonates the user credential
to upload the backup files to Azure storage container for restore operation.
● To perform an online migration, you should create an instance based on the Premium pricing tier.
● Ensure that your VNet Network Security Group rules don't block the following inbound communica-
tion ports to Azure Database Migration Service: 443, 53, 9354, 445, 12000.
● Configure your Windows Firewall for source database engine access.
● Open your Windows Firewall to allow the Azure Database Migration Service to access the source SQL
Server, which by default is TCP port 1433.
● If you're running multiple named SQL Server instances using dynamic ports, you may wish to enable
the SQL Browser Service and allow access to UDP port 1434 through your firewalls
● If you're using a firewall appliance in front of your source databases, you may need to add firewall
rules to allow the Azure Database Migration Service to access the source database(s) for migration, as
well as files via SMB port 445.
● Ensure that you have an Azure SQL Database managed instance
● Ensure that the logins used to connect the source SQL Server and the target managed instance are
members of the sysadmin server role.
● Create an Azure Active Directory Application ID that generates the Application ID key that DMS
Service can use to connect to target Azure Database managed instance and Azure Storage Container.
● Create or make a note of Standard Performance tier, Azure Storage Account, that allows DMS service
to upload the database backup files to and use for migrating databases. Make sure to create the
Azure Storage Account in the same region as the DMS service created.
Register the Microsoft.DataMigration resource provider

1. Sign in to the Azure portal, select All services, and then select Subscriptions.
2.
3. Select the subscription in which you want to create the instance of the Azure Database Migration
Service, and then select Resource providers.
4.
5. Search for migration, and then to the right of Microsoft.DataMigration, select Register.
6.
Create an Azure Database Migration Service instance

1. In the Azure portal, select + Create a resource, search for Azure Database Migration Service, and then
select Azure Database Migration Service from the drop-down list.#
2.
3. On the Azure Database Migration Service screen, select Create.
4.
5. On the Create Migration Service screen, specify a name for the service, the subscription, and a new
or existing resource group.
6. Select the location in which you want to create the instance of DMS.
7. Select an existing VNet or create one. The VNet provides the Azure Database Migration Service with
access to the source SQL Server and target Azure SQL Database managed instance.
8. Select a SKU from the Premium pricing tier as this supports an online migration
9.
Note: If you use SQL Server Integration Services (SSIS) on your SQL Server on premises, DMS does not
yet support migrating SSIS catalog (SSISDB) that stores SSIS packages, but you can provision Azure-SSIS
Integration Runtime (IR) in Azure Data Factory (ADF) that will create a new SSISDB in a managed instance
and then you can redeploy your packages to it.
Migrate using the Azure Database Migration

Service
After an instance of the Azure Database Migration Service is created, then you create a new migration
project.
Create a migration project

1. In the Azure portal, select All services, search for Azure Database Migration Service, and then select
Azure Database Migration Services.
2. On the Azure Database Migration Service screen, search for the name of the instance that you
created, and then select the instance.
3. Select + New Migration Project.

4. On the New migration project screen, specify a name for the project, in the Source server type text
box, select SQL Server, in the Target server type text box, select Azure SQL Database Managed
Instance, and then for Choose type of activity, select Online data migration.
5.
6. Select Create and run activity to create the project.
Specify source details

1. On the Migration source detail screen, specify the connection details for the source SQL Server.
2. If you haven't installed a trusted certificate on your server, select the Trust server certificate check
box.
When a trusted certificate isn't installed, SQL Server generates a self-signed certificate when the
instance is started. This certificate is used to encrypt the credentials for client connections.
3.
4. Select Save.
5. On the Select source databases screen, select the database for migration.
6.
7. Select Save.
Specify target details

1. On the Migration target details screen, specify the Application ID and Key that the DMS instance
can use to connect to the target instance of Azure SQL Database managed instance and the Azure
Storage Account. For information, see the article Use portal to create an Azure Active Directory
application and service principal that can access resources6.
2. Select the Subscription containing the target instance of Azure SQL Database managed instance, and
then select the target instance.
3. Select the Azure SQL Database managed instance.
4. Provide SQL User and Password to connect to the Azure SQL Database managed instance.
6 https://docs.microsoft.com/azure/azure-resource-manager/resource-group-create-service-principal-portal
5.
6. Select Save.
Select source databases

1. On the Select source databases screen, select the source database that you want to migrate.
2.
Configure migration settings

1. On the Configure migration settings screen, provide the following details:
● SMB Network location share
● The local SMB network share that contains the Full database backup files and transaction log
backup files that the Azure Database Migration Service can use for migration. The service account
running the source SQL Server instance must have read\write privileges on this network share.
Provide an FQDN or IP addresses of the server in the network share, for example, ‘\servername.
domainname.com\backupfolder’ or '\IP address\backupfolder'.
● User name
● Make sure that the Windows user has full control privilege on the network share that you provided
above. The Azure Database Migration Service will impersonate the user credential to upload the
backup files to Azure storage container for restore operation.
● Password
● Password for the user.
● Subscription of the Azure Storage Account
● Select the subscription that contains the Azure Storage Account.
● Azure Storage Account
● Select the Azure Storage Account that DMS can upload the backup files from the SMB network
share to and use for database migration. We recommend selecting the Storage Account in the
same region as the DMS service for optimal file upload performance
●
2. Select Save.
Review the migration summary

1. On the Migration summary screen, in the Activity name text box, specify a name for the migration
activity.
2. Review and verify the details associated with the migration project.
3.
Run and monitor the migration

1. Select Run migration.
2. On the migration activity screen, select Refresh to update the display.
3.
Performing migration cutover

After the full database backup is restored on the target instance of Azure SQL Database managed
instance, the database is available for performing a migration cutover.
1. When you're ready to complete the online database migration, select Start Cutover.
2. Stop all the incoming traffic to source databases.
3. Take the [tail-log backup], make the backup file available in the SMB network share, and then wait
until this final transaction log backup is restored.
4. At that point, you'll see Pending changes set to 0.
5. Select Confirm, and then select Apply.
6.
7. When the database migration status shows Completed, connect your applications to the new target
instance of Azure SQL Database managed instance.
Note: Azure Database Migration Service and Transparent Data Encryption.
The Azure Database Migration Service wizard leverage the TDE Settings If you're migrating the source
databases with Transparent Data Encryption (TDE) enabled. You need to have write privileges on the
target Azure SQL Database managed instance. You need to Select the subscription in which the Azure
SQL Database managed instance provisioned from the drop-down menu and select the target Azure SQL
Database Managed Instance in the drop-down menu.
Lesson Summary
In this lesson, you have focused on the tools and methods for migrating SQL Server databases to Azure
SQL Database Managed Instance. You have covered evaluating a database migration approach, choosing
the correct migration method, and breaking down the migration process. Finally, you focused on how
encryption can impact your migration strategy.
Learning objectives
● Evaluate SQL Database Managed Instance Compatibility
● Migrate using Backup / Restore from URL
● Managing encrypted databases
● Migrate using Database Migration Service
Important
Knowledge Check
Question 1
Before creating the Database Migration Service, which resource provider should be registed in your subscrip-
tion prior?
 Microsoft.DataMigration
 Microsoft.Cache
 Migration.DAta
Question 2
Which of the tools would be the best to find compatability issues between the on-premises SQL Server and
Azure SQL Database managed instance?
Synchronizing data to Azure SQL Database

managed instance
Lesson 3: Synchronizing Data to SQL Database
Managed Instance
Data synchronization becomes an important part of our data store experience as models of hub-and-
spoke design continue to flourish. Whether you need to replicate all data, some of your data, or a
transformed version of your data – data stores rarely stay isolated. In this lesson we will cover the most
common and recommended approaches to synchronize your data to and from SQL Database Managed
Instance.
Learning objectives
● Connectivity options with on-premises servers
● Options to synchronize data to SQL Database Managed Instance
● Import and Export data with a BACPAC file
● Load data using SSIS/Azure Data Factory
● Using Transactional Replication to synchrinize data
Connectivity options with on-premises servers

When synchronizing data, it usually takes place between data that is stored on-premises with a data store
in Azure. Before you even consider a data synchronization methos, it is important to ensure that you
have connectivity that is secure. There are three different connectivity options available to establish
communication between computers on-premises and with resources in Azure including Azure SQL
Database, Azure SQL Managed Instance, and SQL Server on IaaS VMs.
● Point-to-Site (P2S)-A Point-to-Site (P2S) VPN gateway connection lets you create a secure connec-
tion to your virtual network from an individual client computer. This is a really strong option for
developers / DBAs and smaller teams using leveraging Azure for DevTest scenarios. This solution is
also useful for telecommuters who want to connect to Azure VNets from a remote location, such as
from home or a conference. SQL Database Managed Instance gives you the quickstart portal instruc-
tions on how you can leverage a Point-to-Site VPN connection after you have deployed a SQL
Database Managed Instance. The image below shows the typical portal experience after the deploy-
ment is completed.
● Site-to-Site-Site to Site is used to connect an entire on-prem site to the Azure network. You need
either a dedicated VPN device or configure RRAS (Routing and Remote Access Services) in Windows.
You also need at least one publicly facing ipV4 address for your router.
● ExpressRoute-Azure ExpressRoute enables you to create private connections between Azure data-
centers and on-prem infrastructure or infrastructure in a colocation environment. ExpressRoute
connections do not go over the public Internet, and offer more reliability, faster speeds, lower laten-
cies and higher security than typical connections over the Internet. With ExpressRoute, you can
establish connections to Azure at an ExpressRoute location (Exchange Provider facility) or directly
Synchronizing data to Azure SQL Database managed instance 193
connect to Azure from your existing WAN network (such as a MPLS VPN) provided by a network
service provider.
SQL DB Managed Instance - Public Endpoint – Secure Ac-

cess
Public endpoint for Azure SQL Database Managed Instance provides the ability to connect to Azure SQL
Database Managed Instance from the Internet without using a VPN and is designed for data communica-
tion only. Public endpoint for data can simultaneously coexist with the private endpoint. For security
reasons, the implementation allows for Separation of Duties (SoD) between a database administrator and
a network administrator when enabling the public endpoint. The public endpoint for managed instance
can be enabled/disabled via PowerShell script and it can also be enabled in the Azure portal.
To enable public endpoint for managed instance, two steps are required, and for separation of duties two
separate roles with the following database and network permissions need to perform these steps:
● Database administrator who has RBAC permissions in scope Microsoft.Sql/managedInstances/* needs
to run a PowerShell script to enable public endpoint for managed instance.
● A network administrator who has RBAC permissions in scope Microsoft.Network/ * needs to open the
port 3342 used by the public endpoint on NSG and provide UDR route to avoid asymmetric routing.
●
The public endpoint support with SQL Database Managed Instance enables manage instance to have all
of the connectivity scenarios that you would have with Azure SQL Database. This enables any data
synchronizations scenario that Azure SQL Database also supports.
Options to Synchronize data to and from SQL

Database Managed Instance
There are a number of methods that can be used to synchronize data from a SQL Database Managed
Instance to an on-premises server and visa versa. Each methods have their own considerations that
should be taken into account when you slect a method
Backup/restore
Backup and restore options have been covered in previous lesson as a means of getting your databases
from on-prem to Azure. When attempting to bring your databases back on-premises, one important
point to understand is that the official statement from Microsoft is that backup and restore from SQL
Database Managed Instance to on-premises is not supported and likely would not work because SQL
Database Managed Instance is always at the latest build of the SQLOS engine. You cannot restore
backups from a higher version to earlier version.
BACPAC file using SqlPackage

A BACPAC file is simply a zipped version of your metadata and the data from your database. This is a
deployment method that you can use for Azure SQL DB, but Managed instance does not support migrat-
ing a using BACPAC in the Azure portal. Instead you must use the SQLPackge utility to leverage the
BACPAC file.
Bulk Copy Program (BCP)

BCP is a command line tool that exports tables to files so you can import them. This technology uses a
similar approach of an initial transactional replication snapshot You can use this approach to migrate
from a single Azure SQL Database to Azure SQL Managed Instance and back.
SQL Server Integration Service

SQL Server Integration Services (SSIS) is an ETL technology that grew from Data Transformation Services
(DTS) in previous releases of SQL Server. SSIS is primarily used for ETL processes, but its control flow is
robust enough to create a system level execution engine and the data flow is powerful enough to handle
any volume of data transformation and manipulation tasks with auditing, debugging, and full source
control support. SSIS has grown and has a number of rich, built-in transformations.
Azure Data Factory

Azure Data Factory is primarily built for data movement and orchestration and is primarily designed for
extract, load, transform executions with the focus on ingestion. ADF has the integration runtime support
to run SSIS packages and with the public internet support for SQL Database Managed Instance makes it a
strong option for SQL Database Managed Instance.
Transactional replication
Transactional replication can copy data from your Managed Instance to any SQL Server. Transactional
Replication is a very convenient approach for migrating data to and from a Managed Instance. Below are
the supported replication types:
● Transactional
● Snapshot
● One-way
● Bidirectional
Import and Export data with a BACPAC file

When you need to export a database for archiving or for moving to another platform, you can export the
database schema and data to a BACPAC file. A BACPAC file is a ZIP file with an extension of BACPAC
containing the metadata and data from a SQL Server database. A BACPAC file can be stored in Azure Blob
storage or in local storage in an on-premises location and later imported back into Azure SQL Database
or into a SQL Server on-premises installation. This can be used for restoring to SQL databases to Azure
SQL Database and SQL Server IaaS VMs.
However, Managed instance does not support migrating a database into an instance database from a
BACPAC file using the Azure portal. Instead you must use the SQLPackge utility to leverage the BACPAC
file. You should always use the latest version of SQLPackage. SSMS / SQL Server Data Tools has the latest
versions of SQLPackage. You can also download the latest version from the internet.
SQLPackage example - Export

The following SqlPackage command imports the AdventureWorks2008R2 database from local storage to
an Azure SQL Database server called mynewserver20170403. It creates a new database called myMi-
gratedDatabase with a Premium service tier and a P6 Service Objective. Change these values as appropri-
ate for your environment.
SqlPackage.exe /a:import /tcs:"Data Source=mynewserver20170403.database.
windows.net;Initial Catalog=myMigratedDatabase;User Id=<your_server_admin_
account_user_id>;Password=<your_server_admin_account_password>" /sf:Adven-
tureWorks2008R2.bacpac /p:DatabaseEdition=Premium /p:DatabaseServiceObjec-
tive=P6
To connect to a managed instance, you must have a point-to-site connection or an express route connec-
tion.
The latest version of SQLPackage supports migration to Azure SQL Managed Instance (MI) from multiple
SQL sources such as Azure SQL Database.
SQLPackage example - Import

If the environment that contains the exported bacpac file does not have access to the destination
Managed Instance, move the exported bacpac file “backup150.bacpac” to an environment that can access
your Azure SQL Managed Instance. Using the following steps, you can import the bacpac into an Azure
SQL Managed Instance using the same SQLPackage utility for export.
1. Download and run the DacFramework.msi installer for Windows.
2. Open a new Command Prompt window, and run the following command.
3. cd C:\Program Files\Microsoft SQL Server\150\DAC\bin
4. Run the following command to import into the Managed Instance

5. sqlpackage.exe /a:Import /TargetServerName:ManagedInstancename.appname.
database.windows.net /TargetDatabaseName:dbname /TargetUser:username /
TargetPassword:password /SourceFile:C:\Users\user\Desktop\backup150.bacpac
Synchonizing data using SQL Server Integration

Services or Azure Data factory
SQL Server Integration Services (SSIS) has long been the ETL tool of choice for migrating data from point
A to point B and taking advantage of the powerful control flow and data flow capabilities it allows with
nearly limitless amounts of data manipulation, many data transformation options, ability to execute in
parallel, and other features SSIS provides. You can still run SQL server integration services packages from
SQL Server on-premises and from SQL Server virtual machines in the cloud. Running SSIS may still be a
preferred option for many organizations that have a large investments of development already in the
SSIS space. However, now that we have Azure SQL Database as well as SQL Database Managed Instance
organizations are looking for a way to take their ETL strategies and move them to a more cloud-centric
model.
Azure Data Factory is essentially a fully-managed data integration as a service in the cloud that can be
leveraged for your ELT and ETL workloads. The managed compute infrastructure provides data connec-
tors (so you do have to go learn an API for example to pull data), data conversions and column mapping
transformations, as well as activity dispatching to run and monitor activities in other services like data-
bricks, HDInsight, etc. all in one place.
Which technology should you use?

There are a couple of choices here. First, you can continue leveraging your SSIS packages and have them
run in the cloud by leveraging Azure Data Factory. You also have the choice of creating a brand-new
Azure Data Factory pipeline to execute your data movement activities. The previous challenge in getting
Azure Data Factory to be able to work with SQL Database Manage Instance is that you would have to
configure an integration runtime connection to the Manage Instance Virtual Network. Now, SQL Data-
base Managed Instance now supports public end points making is much easier to leverage ADF.
SSIS catalog considerations

Consider hosting the SSIS Catalog database in Azure SQL Database with virtual network service end-
points/Managed Instance. If the SSIS catalog is hosted in Azure SQL Database with virtual network service
endpoints, or Managed Instance, you can join your Azure-SSIS Integration Runtime(IR) to:
● The same virtual network
● A different virtual network that has a network-to-network connection with the one that is used for the
Managed Instance
If you host your SSIS catalog in Azure SQL Database with virtual network service endpoints, make sure
that you join your Azure-SSIS IR to the same virtual network and subnet. If you join your Azure-SSIS IR to
the same virtual network as the Managed Instance, make sure that the Azure-SSIS IR is in a different
subnet than the Managed Instance.
If you join your Azure-SSIS IR to a different virtual network than the Managed Instance, we recommend
either virtual network peering (which is limited to the same region) or a virtual network to virtual network
connection. In all cases, the virtual network can only be deployed through the Azure Resource Manager
deployment model.
Network security group

If you need to implement a network security group (NSG) for the subnet used by your Azure-SSIS
integration runtime, allow inbound/outbound traffic through Outbound TCP ports (1433, 11000-11999,
14000-14999) which would need to be opened to the SQL destination. The reason being is that the nodes
of your Azure-SSIS integration runtime in the virtual network use these ports to access SSISDB hosted by
your Azure SQL Database server - This purpose is not applicable to SSISDB hosted by Managed Instance.
synchronizing data with Transactional-Replica-

tion
Transactional replication enables you to replicate data into an Azure SQL Database Managed Instance
database from a SQL Server database or another instance database. You can also use transactional
replication to push changes made in an instance database in Azure SQL Database managed instance to a
SQL Server database, a single database in Azure SQL Database / pooled database in an Azure SQL
Database elastic pool. There is a lot of flexibility with Azure SQL Database Managed Instance as managed
instance can be a publisher, distributor, and subscriber for SQL databases.
In fact, one of the use cases of using transactional replication with managed instance is the ability to
migrate databases from one SQL Server or Managed Instance to another database by continuously
publishing the changes. Replication works off of the publishing metaphor of a publisher, distributor, and
any number of subscribers. You have to have a publisher that has the source data. From there you will
decide which tables you will replicate and how much of the data you will replicate. Replication is one of
the few technologies that allows you to replicate parts of a table. We refer to these tables parts as
“articles”. This data is then sent to a distributor which is essentially a supplier of the data to any number
of subscribers.
Publisher
The Publisher is an instance or server that publishes changes made on some tables (articles) by sending
the updates to the Distributor. Publishing to any Azure SQL database from an on-premises SQL Server is
supported by the following versions of SQL Server:
● SQL Server 2019 (preview)
● SQL Server 2016 to SQL 2017
● SQL Server 2014 SP1 CU3 or greater (12.00.4427)
● SQL Server 2014 RTM CU10 (12.00.2556)
● SQL Server 2012 SP3 or greater (11.0.6020)
● SQL Server 2012 SP2 CU8 (11.0.5634.0)
Distributor
The Distributor is an instance or server that collects changes in the articles from a Publisher and distrib-
utes them to the Subscribers. The Distributor can be either Azure SQL Database Managed Instance or
SQL Server (any version as long it is equal to or higher than the Publisher version).
Subscriber
The Subscriber is an instance or server that is receiving the changes made on the Publisher. Subscribers
can be either single, pooled, and instance databases in Azure SQL Database or SQL Server databases.
Azure SQL Managed Instance Databases supports the following replication types:
● Transactional
● Snapshot
● One-way
● Bidirectional
Common configurations
Publisher with local Distributor on a Managed Instance

Publisher and distributor are configured within a single Managed Instance and distributing changes to
other Managed Instance, single database, pooled database, or SQL Server on-premises. In this configura-
tion, publisher/distributor Managed Instance cannot be configured with Geo-replication and auto
failover-groups.
Publisher with remote distributor on a Managed Instance

In this configuration, one Managed Instance publishes changes to distributor placed on another Man-
aged Instance that can serve many source Managed Instances and distribute changes to one or many
targets on Managed Instance, single database, pooled database, or SQL Server.
Publisher and distributor are configured on two Managed Instances. In this configuration, the following
requirements should be met:
● Both Managed Instances are on the same vNet.
● Both Managed Instances are in the same location.
● Managed Instances that are hosting published and distributor databases cannot be geo-replicated
using auto failover-groups.
Publisher and distributor on-premises with a subscriber on a

single, pooled, and instance database
In this configuration, an Azure SQL Database (single, pooled, and instance database) is a subscriber. This
configuration supports migration from on-premises to Azure. If a subscriber is on a single or pooled
database, it must be in push mode.
Troubleshooting
One of the most common issues customer contend with when setting up replication with Azure SQL
Database Managed Instance is the network security layer. Managed Instance is secure by default and out
of the gate most ports and protocols are not going to have access to the managed instance virtual
network. Proper security access is required in order to ensure that replication components can communi-
cate with each other effectively. Azure SQL DB Managed Instance is locked down and isolated from other
resources by design. In order to leverage replication effectively certain protocols and ports must be
enabled in order for replication to work correctly. Other considerations around replication is that the
distributor can be a SQL Database Managed Instance SQL Server, but it has to be a version equal to or
higher to the configured publisher.
Requirements
● Connectivity uses SQL Authentication between replication participants.
● An Azure Storage Account share for the working directory used by replication.
● Port 445 (TCP outbound) needs to be open in the security rules of the Managed Instance subnet to
access the Azure file share.
● Port 1433 (TCP outbound) needs to be opened if the Publisher/Distributor are on a Managed Instance
and the subscriber is on-premises.
Note: You may encounter error 53 when connecting to an Azure Storage File if the outbound network
security group (NSG) port 445 is blocked when the distributor is an instance database and the subscriber
is on-premises. Update the vNet NSG to resolve this issue.
Connecting applications to a Managed Instance

A SQL Database managed instance must be placed inside an Azure virtual network subnet that's dedicat-
ed to managed instances. Through this deployment you get a secure private IP address and there's also
the ability to connect to on-premises networks. Via Managed instances you can connect the management
since to a linked server or another on Prem data store and we can also connect the management since to
Azure resources.
The managed instance database is exposed through the Azure portal, PowerShell, Azure CLI, and the
REST API.
Managed instances depend on Azure services such as Azure Storage for backups, Azure Event Hubs for
telemetry, Azure Active Directory for authentication, Azure Key Vault for Transparent Data Encryption
(TDE) and a Azure platform services that provide security and supportability features.
The managed instances makes connections to these services.
All communications are encrypted and signed using certificates. To check the trustworthiness of commu-
nicating parties, managed instances constantly verify these certificates through certificate revocation lists.
If the certificates are revoked, the managed instance closes the connections to protect the data.
Lesson Summary
Data synchronization is an important part of data migration. Whether you need to replicate all data, some
of your data, or a transformed version of your data – data stores rarely stay isolated. In this lesson, you
have learned the most common and recommended approaches to synchronize your data to and from
SQL Database Managed Instance.
Learning objectives
● Connectivity options with on-premises servers
● Options to synchronize data to SQL Database Managed Instance
● Import and Export data with a BACPAC file
● Load data using SSIS/Azure Data Factory
● Using Transactional Replication to synchrinize data
Important
Knowledge Check
Question 1
You are considering you connectivity choices between your work premises and Azure datacenters. You want
to create private and secure connections between Azure datacenters and on-premises infrastructure. Which
would be the best option?
 Site-to-Site
 Point-to-Site
 ExpressRoute
 Modem
Module summary
Module Summary
In this module, you have looked at how you can migrate SQL Server workloads to SQL Database man-
aged instance. You explored the pre migration considerations that need to be taken into account before
performing a migration and how to create a SQL Database managed instance. You then explored the
different methods to perform an offline and online migration, and how to handle the migrations of
encrypted databases. You then looked at ways in which you can synchronized data to and from a SQL
Database Managed instance.
Learning objectives
In this module, you have learned how to:
● Considerations of migrating to Azure SQL Database Managed Instance
● Migrate to an Azure SQL Database Managed Instance
● Synchronize data to Azure SQL Database Managed Instance
Module summary 203
Answers
Question 1
What is the lowest compatibility level that is supported by Azure SQL Database Managed Instance?
 SQL Server 2005
■ SQL Server 2008
 SQL Server 2008 R2
 SQL Server 2012
Explanation
The lowest compatibility level that is supported by Azure SQL Database Managed Instance is SQL Server
2008 database.
Question 2
Which of the tools can be used to centralize the management and execution of a migration to Azure SQL
Database Managed Instance?
■ Azure Database Migration Service
Explanation
You should use the Azure Database Migration Service to centralize the management and execution of a
migration to Azure SQL Database Managed Instance. it can make use of the Database Migration Assistant,
SQL Server Migration Assistant and Data Experimentation Assistant to perform the assessments and
migration to Azure SQL Database Managed Instance.
Question 1
Before creating the Database Migration Service, which resource provider should be registed in your
subscription prior?
■ Microsoft.DataMigration
 Microsoft.Cache
 Migration.DAta
Explanation
The Microsoft.DataMigration resource provider should be registed in your subscription prior to creating the
Database Migration Service
Question 2
Which of the tools would be the best to find compatability issues between the on-premises SQL Server
and Azure SQL Database managed instance?
Explanation
The Data Migration Assistant would be the best tool to use to detect any compatability issues between the
on-premises SQL Server and Azure SQL Database managed instance.
Question 1
You are considering you connectivity choices between your work premises and Azure datacenters. You
want to create private and secure connections between Azure datacenters and on-premises infrastruc-
ture. Which would be the best option?
 Site-to-Site
 Point-to-Site
■ ExpressRoute
 Modem
Explanation
Azure ExpressRoute enables you to create private connections between Azure datacenters and on-prem
infrastructure or infrastructure in a colocation environment. ExpressRoute connections do not go over the
public Internet

DP 050T00A ENU TrainerHandbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DP 050T00A ENU TrainerHandbook

Uploaded by

Copyright:

Available Formats

Microsoft

© 2019 Microsoft Corporation. All rights reserved.

MICROSOFT LICENSE TERMS

c) If you are a MPN Member:

LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES.

■ Module 0 Welcome ................................................................ 1

Welcome to the course

About this course

Module 1: Introducing Data Platform Modernization

Module 2: Choose the right tools for Data Migration

Module 3: Migrate SQL Workloads to Azure Virtual Ma-

Module 4: Migrate SQL Workloads to Azure SQL Databases

Module 5: Migrate SQL Workloads to Azure Managed In-

Understand data platform modernization

What is Data Platform Modernization

Why Perform Data Platform Modernization

The 7 R Considerations to Migration

# Phase Description Benefit

# Phase Description Benefit

# Phase Description Benefit

Understanding the stages of migration

Initiate and Discovery Stage

Taking stock of the current environment

Check for dependencies between existing Applications

List the workload types of your systems

Current Workload Assessment

Workload Criteria Assessment

Platform target options

Choosing the right target platform

Choosing target platform by features

Migrating SSAS, SSIS and SSRS to an Azure fully managed

Choosing target platform by cost

Offline versus online migrations

Transform and Optimize Stage

Install pre-migration version upgrades

Fix any errors that are identified by the migration assess-

Implement database schema changes

Migrate existing integrated database services into Azure

Handling SSIS workloads in the cloud

Assess what new features may be available on the target

Re-structure workloads into more cost effective or perfor-

Choose the highest service level and performance tier dur-

Ensure workloads are right-sized

Minimize the distance between your BACPAC file and the

Disable auto-statistics during migration

Partition tables and indexes

Drop indexed views and recreate them once finished

Migrate, validate and remediate

Migration, validation and remediation considerations

Understand your workload requirements as a starting point

Select non-critical workloads or low priority databases for

Run a test migration with chosen tool

Test database for issues

Test the plan to mitigate risk associated with downtime and

Assess migration tools based on disruption to help lower the

Repeat issue fixes until the database is fixed

Continually iterate on your migration process

Consider the maintenance windows that are available to the

Take old databases and application offline

Test third-party applications

Create new disaster recovery and maintenance plans

Use toolsets to give you greater insight into your environ-

Data migration technologies

SQL Server on a Virtual Machine