migrating sql server 2012 to azure using azure site ... · pdf filebefore we can get started...

Migration of SQL Server 2012 to Azure using Azure Site Recovery (ASR) Microsoft Corp.

1

Migrating SQL Server 2012 to

Azure Using Azure Site

Recovery (ASR)


2

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS

DOCUMENT.

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, our provision of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property. The

descriptions of other companies’ products in this document, if any, are provided only as

a convenience to you. Any such references should not be considered an endorsement or

support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may

change over time. Also, the descriptions are intended as brief highlights to aid

understanding, rather than as thorough coverage. For authoritative descriptions of these

products, please consult their respective manufacturers. © 2016 Microsoft Corporation.

All rights reserved. Any use or distribution of these materials without express

authorization of Microsoft Corp. is strictly prohibited. Microsoft and Windows are either

registered trademarks or trademarks of Microsoft Corporation in the United States and/or

other countries. The names of actual companies and products mentioned herein may be

the trademarks of their respective owners.


3

Contents

1. Introduction ............................................................................................................................................ 4

2. Target Audience .................................................................................................................................... 4

3. Prerequisites ........................................................................................................................................... 4

4. Source Environment (on-premise) Setup ..................................................................................... 5

5. Migrating SQL Server 2012 (Standalone) to Azure................................................................... 6

5.1. Deploy Mobility Services Agent & Replicate Workload to Azure .............................................. 6

5.2. Create a Recovery Plan for your workloads ..................................................................................... 14

5.3. Initiate Failover & Validate Workload ................................................................................................ 15

5.3.1. Test Failover ............................................................................................................................................................... 15

5.3.2. Failover ......................................................................................................................................................................... 21

6. Next Steps ............................................................................................................................................. 28

7. Additional Resources ......................................................................................................................... 28

8. Support ................................................................................................................................................... 29


4

1. Introduction

This document is a detailed guide describing the steps for migrating on-premise SQL

Server 2012 (Enterprise Edition) workloads to Microsoft Azure using Azure Site Recovery

(ASR). It is only intended to be used as a reference guide by Managed Services Providers

(MSPs) that are part of the MSP - Azure Cloud Migration Program. The goal is to help

MSPs familiarize themselves with the methodologies, processes and steps needed to

migrate on-premise SQL Server workloads by leveraging the capabilities of ASR services

to migrate workloads to Azure.

Although ASR was designed as a Business Continuity and Disaster Recovery (BCDR) tool,

the same techniques can be applied for migrations because of its direct replication

capabilities to Azure with minimal changes required to the on-premise infrastructure.

Specifically, this document covers the migration of SQL Server 2012 (Enterprise Edition)

to Azure.

2. Target Audience

This document is primarily intended for Azure Architects, Solution Specialists and System

Administrators who will be involved in the on-premise to Azure workload migrations. It is

assumed that this audience understands the intricacies of Microsoft Azure and its core

services and has deep insights into its customer’s on-premise workloads to successfully

migrate them to Azure. The document is NOT intended to be a primer or guide on SQL

Server or ASR but rather a guide to migrating SQL Server workloads to Azure.

3. Prerequisites

Before we can get started with migrating SQL Server 2012 to Azure, all items listed below

must be completed or complied with:

1. The source Planning, Discovery, and Assessment (Business risk, Cloud Suitability

Etc.) steps should be completed and the application/workload has been approved to

be migrated to Azure. ☒

2. The Azure Network Planning should be completed. ☒

3. The ASR Capacity Planning and source setup should be completed. ☒


5

4. Typically, SQL Server installation will have a dependency on Active Directory (AD).

Please ensure that your AD infrastructure is already migrated and/or available

in Azure.

5. SQL Server Version(s) supported by ASR are:

SQL Server 2014 Enterprise and Standard

SQL Server 2012 Enterprise and Standard

SQL Server 2008 R2 Enterprise and Standard

Please Note: This document showcases SQL Server 2012 (Enterprise Edition)

version only. Other versions of supported SQL migrations will be similar, but it

is recommended that partners understand the subtle differences to successfully

migrate to Azure.

4. Source Environment (on-premise) Setup

This section covers the lab environment configuration that was used to test the migration

of a SQL Server 2012 Enterprise Server using ASR.

1. We have a single Windows 2012 R2 Standard server (VM) running a local instance of

SQL Server.

2. The Server is domain joined, has a Static IP address and DNS set to the on-premise

AD-DNS server.

3. The SQL version is SQL Server 2012 Enterprise and the configuration mode is

‘Standalone’ (Non-clustered and No High Availability(HA)).

4. The VM has a single dynamic disk (VHD) attached with a base size of 100GB shared

across the Operating System, SQL database(s) & Transactional logs.

The document assumes that these migration procedures would be similar to other

supported versions of standalone SQL Server workloads, but have not been verified. It is

highly recommended that the Architects and System Administrators involved in the

migration effort ensure that they are testing this in their version of the environment.


6

5. Migrating SQL Server 2012 (Standalone) to Azure

Migrating an application to Azure is typically a phased approach that consists of the

following stages:

I. Deploy Mobility Service Agent & Replicate the Workload: Using ASR, the

source workload is replicated to an Azure Recovery Vault. Once the initial

replication is complete, ASR constantly monitors the application in the source and

replicates the deltas to Azure on a regular basis.

II. Test Failover: Once the initial replication is complete, a test failover will spin up

Azure VMs and the application can be tested multiple times without affecting the

production workload running in the source environment.

III. Failover: After the application has been successfully tested and validated to your

satisfaction using test failover process, you will initiate a failover of the application

from the source to Azure and turn off the source VM(s).

5.1. Deploy Mobility Services Agent & Replicate Workload to

Azure

The first step in migrating SQL Server workloads to Azure is to Deploy the Mobility

Services Agent and start replicating the workload using ASR. Once the initial

replication process is complete, ASR constantly monitors the application in the source

and replicates the changes (deltas) to Azure as well. The section below shows the steps

to replicate SQL workload to Azure.

1. Login to the Azure Portal. Under ‘All Resources’ search for the Recovery Vault

name, open it and click on Site Recovery.

2. Click on Step 2: Replicate Application and then click on the Source blade to

select the below options and click OK.

Source – On Premises

Note: This Recovery Vault should have been setup using the ASR Setup Guide

prior to migrating workloads. Please refer to the ASR Setup Guide for more

details.

https://portal.azure.com/


7

Source location - Select the Configuration Server

Machine type –

o Physical Machines – for migrating Physical or Hyper-V VM’s

o Virtual Machines – for migrating VMware VMs

VCenter / VSphere Host – Select the VCenter host [Applies only if you

selected virtual machines for Machine Type]

Process Server – Select the Process server that you want to use for

replication. If you haven’t set up a separate or multiple process server(s), the

configuration server will show up as default


8

3. Under Target choose the following properties and click OK:

Subscription – The subscription to be used for migrations.

Post Failover Resource Group – The Resource Group to be used for

Migrations. (These should have been created as part of the migration

planning process).

Post Deployment failover model – Resource Manager.

Storage Account – Choose the one(s) that were created for handling

migrations during ASR Capacity Planning phase.

Azure Network – Configure now for selected machines.

Post Failover Azure Network - Choose the Azure VNET that was created

for migrations during the Network planning phase.

Subnet – Choose the correct subnet within the Azure VNET.


9

4. Based on the Machine Type chose earlier, the below section(s) will slightly change:

If Machine Type = Virtual Machines: In the Virtual Machines > Select

Virtual Machines blade, select the SQL VM you want to migrate and click

OK


10

If Machine Type = Physical Machines: In the Physical Machines > Select

Physical Machines blade, click on +Physical Machine. Enter the Server

Name, on-premise IP Address, select OS type and click OK. This will

discover the on-premise server from and add it to the vault for protection.

Continue this process to add more SQL servers to be replicated (if

required).

5. Under Notifications you will see that the server is being discovered and if the

mobility services agent is NOT present, it will be installed on this server. You

can always check the progress of this job under Your Recovery Vault > Jobs > Site

Recovery Jobs


11

6. Once the job completes, you can see that newly discovered server in the Azure

Portal.

7. In Properties > Configure Properties blade, either set default values or choose

properties per VM.

Account – Choose the appropriate account that has administrator rights to

the Servers being migrated

Disks to replicate – From the dropdown, select the disks that you want to

include in replication and uncheck the ones that are not required (Ex: Disk

for non-production (temp) data).

8. In Replication settings > Configure replication settings choose the appropriate

policy and click OK with the default values.

You can always modify the replication policy in Your Recovery Vault > Site

Recovery Infrastructure > Replication Policies (For VMware & Physical


12

Machines) > Policy Name > Edit Settings. Changes you apply will be used

for machines that are already replicating as well as new machines.

9. Now click on Enable Replication.


13

10. Track the replication progress by checking at Your Recovery Vault > Replicated

Items. Once the status of a Replicated Item (server) changes to Protected, it

means the application/workload is ready for failover.


14

5.2. Create a Recovery Plan for your workloads

We are now going to create a Recovery Plan in your Azure Vault. The usage of

Recovery Plans helps facilitate easier management and migration of multiple servers

(that make your service/application) into Azure without having to deal with each

component individually. Below are a couple of examples to provide additional context

and the steps below to create and configure a recovery plan.

1. In the Azure Portal, go to Your Recovery Vault > Recovery Plans (Site Recovery

Infrastructure) and click on +Recovery Plan.

2. Provide the following details and click OK.

Name – A meaningful friendly name (Ex: TestRecoveryPlan)

Source – On premise VMware Host / Configuration Server

Target – Microsoft Azure

Allow Items with Deployment Model – Resource Manager

Select Items – From the list of ‘Protected Items’ choose ALL the servers

that comprise of your application / service and click OK.

Examples:

A Recovery Plan for ALL your SQL servers in your environment. This way

you can migrate all SQL servers into Azure cutover at one.

Enterprise applications are mostly multi-tier that are split into multiple

Server roles. Like IIS Web applications are split into Web front end &

back end database servers that can be included in the same recovery

plan & migrated to Azure.

Just about any server(s) that you need to manage & migrate into Azure

at the same time.



15

5.3. Initiate Failover & Validate Workload

5.3.1. Test Failover

Once the initial replication is complete, a test failover can now be initiated to test

your workload in Azure. This can be done multiple times without affecting the

on-premise workload (source independent).

1. Login to the Azure Portal, under ‘All Resources’ search for the Recovery Vault

name and open it.

2. Click on Replicated items, select the replicated server(s) that you want to test

for failover (Ex: BELSYSGLAB02)

3. Click on Compute and Network, ensure the correct values as described below

are set and click Save:

Name – This will be pre-populated with the source server name.

Recommendation is to leave the same or you can modify by clicking

on the Text box.

Resource Group – Choose the correct Resource Group where the new

VMs will be grouped (this should have been decided during planning

phase).

Size – Based on the source server SKU an Azure VM SKU is pre-selected.

Either leave as-is or feel free to change SKU as you see fit.



16

Target Network – Select the Non-Production Azure VNET created for

test failovers (should have been created during Network Planning

phase).

Target Subnet – Ensure the correct subnet is selected (configuration

should have been decided during Network Planning phase).

Target IP – Either provide a Static IP from the Target Subnet or DHCP

will assign any available IP from the Target Subnet.

4. Repeat Steps 2 -3 for all other protected servers that you want to test

failover for.

5. Now to Initiate the Test Failover, go to Your Vault > Recovery Plans (Site

Recovery), click on … against the specific recovery plan choose Test Failover.

6. For Recovery Point choose Latest Processed (most current data). Ensure the

correct Azure VNET is showing (or select from drop down list) and click OK

7. Check the progress in Your Recovery Vault > Jobs > Site recovery jobs. Once

complete, you will see a new VM created with a suffix of -test [Ex:

BELSYSGLAB02-Test].


17

8. Based on your Network planning and whether to use either Site to Site VPN,

ExpressRoute, or a Custom Setup and your enterprise remote access policies,

RDP to this new VM using its Azure-IP Address (You can find this by exploring

the VM properties at All Resources > Type VM Name >Properties > Private

IP address)

9. Login to the SQL Server using Windows AD integrated authentication to

ensure AD connectivity is working.


18

10. Confirm that the status of the Databases is online, free of warnings and errors,

and execute any sample queries to ensure basic functionality, data integrity &

correctness.


19

11. In addition to all the above, please run any other specific tests as directed by

your SQL admin/product team/application owner to ensure its proper working.

12. Once all your application/DB test cases have successfully passed validations,

you can complete the Test Failover scenario by following the steps below.

Please be advised that this decommission the Test VM and related

resources in Azure however, you can always re-initiate a Test failover how

many ever times you want without impacting the source application or

other resources.

In the Azure Portal, go to Your Recovery Vault > Recovery Plans (site

Recovery) > Click … against the Recovery Plan that underwent Test

Failover and click clean test failover

Provide a justification, check Testing is complete, delete test failover

virtual machines and click OK.


20

13. The test infrastructure should now be decommissioned and this also concludes

the Test failover scenario. Optionally, you can also check the progress at Your

Recovery Vault > Jobs > Site Recovery Jobs.


21

5.3.2. Failover

Only after the application, has been thoroughly and successfully validated

using the Test Failover process and other unit tests as required by the

customer’s organization, you should initiate a Failover. This will begin the final

migration of a server/application/workload from the source (on-premise)

environment to Azure.


22

1. Login to the Azure Portal. Under ‘All Resources,’ search for the Recovery Vault

name and open it.

2. Click on Replicated items and then click on the server that has completed the

Test Failover (Status shows as Test Failover Completed).

3. Click on Compute and Network, ensure the correct values are set as described

below, and click Save:

Name – This will be pre-populated with the source server name.

Recommendation is to leave it the same, otherwise you can modify it

by clicking on the Text box.

Resource Group – Choose the correct Resource Group where the new

VMs will be grouped (this should have been decided during planning

phase).

Size – Based on the source server SKU an Azure VM SKU is pre-selected.

Either leave as-is or feel free to change SKU.

Target Network – Select the Production Azure VNET created for test

failovers (This VNET should have been created during Network Planning

phase).

NOTE: Pre-Planned-Failover Checklist

1. When the Failover is initiated, the source server must be shut down

before the failover. This is required to prevent any issues with the same

application operating in both environments.

2. Please communicate the application migration date and time to all

customers and stakeholders.

3. <optional based on your configuration> Any public or private DNS

endpoint updates need to be complete before the Failover is initiated.

4. <optional based on your configuration> Complete re-configuration of

your Global load balancing (GLB) solutions.

5. <optional based on your configuration> Ensure the server has the

appropriate backup/high Availability solutions configured in Azure like

Availability sets.

6. <optional recommendation based on your configuration> Planning

for a Disaster Recovery (DR) strategy in Azure is complete.



23

Target Subnet – Ensure the correct subnet is selected (again

configuration should have been decided during Network Planning

phase).

Target IP – Either provide a Static IP from the Target Subnet selected

above or DHCP will assign any available IP from the Target Subnet.

4. Repeat steps 2 – 3 for all other protected servers that comprise your SQL

application.

5. Now to initiate the Failover, go to Your Vault > Recovery Plans (Site

Recovery), click on … against the specific recovery plan (Ex: TestRecoveryPlan)

choose Failover.

6. Ensure direction is from Source Azure. For Recovery Point choose Latest

Processed (most current data), and check the checkbox to shut down the on

premise VM before the beginning of failover and Click OK and wait for the job

to complete. You can also check the status at Your Recovery Vault > Jobs >

Site Recovery jobs.


24

7. In the Azure Portal, navigate to Virtual Machines in the left-side navigation

menu, and you will now see a new VM has been created.

8. Based on your Network planning and whether to use either Site to Site VPN,

ExpressRoute, or a Custom Setup and your enterprise remote access policies,

RDP to this new VM using its Azure-IP Address (You can find this by exploring

the VM properties. All Resources > Type VM Name >Properties > Private IP

address)



25

9. Login to the SQL Server using Windows AD integrated authentication to ensure

AD connectivity is working.

10. Confirm that the status of the Databases is online, free of warnings and errors,

and execute any sample queries to ensure basic functionality, data integrity &

correctness.


26

11. In addition to all the above, please run any other specific tests as directed by

your admin/product team.

12. Once all your application test cases have successfully passed validations, you

can Commit your Recovery Plan by following below steps.

In the Azure Portal go to Your Vault > Recovery Plans (Site Recovery),

click the Recovery Plan that completed Failover, click More, then

Commit.



27

Read and understand the warning, after which you can click OK. Please

Note that clicking OK will commit the machines in the recovery plan, and

that we cannot change the recovery point of the machine.

13. Once you committed the “Recovery Plan” you can Complete Migration by

following the below steps. This will end ASR protection, remove the server

from Your Vault > Replicated Items, and cleanup all migration related

properties.

In the Azure Portal go to Your Vault > Replicated Items, click the server

that completed Failover, click More, then Complete Migration.

Read and understand the warning, after which you can click OK. Please

Note that clicking OK will finalize the migration of the application to

Azure, and that it cannot be rolled back to the source.



28

14. This concludes the migration guide for SQL Server 2012 (Standalone) to Azure

using Azure Site Recovery (ASR). Your workload should now be operational in

Azure.

6. Next Steps With the application now migrated to Azure, please follow your enterprise policy to start

the application decommission process in the source environment.

7. Additional Resources ASR documentation from Microsoft Azure

Migrate SQL Server to Azure

Best Practices to deploy Mobility Services Agent

Automate Mobility Services Agent Deployment

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-sql

https://azure.microsoft.com/en-us/blog/azure-site-recovery-best-practice-how-to-deploy-mobility-service/

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-automate-mobility-service-install


29

Planning:

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-prereq

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-

planner

Network Design:

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-network-

design

Capacity Planning:

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-

capacity-vmware

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacity-

planner

Step by Step guides:

o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-migrate-to-

azure (Multiple guides)

8. Support For support queries, please refer to our support portal or submit your questions to our

support team via email.

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-prereq

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-planner

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-planner

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-network-design

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-network-design

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacity-planner

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacity-planner

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-migrate-to-azure

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-migrate-to-azure

https://cspmigration.freshdesk.com/support/home

mailto:[email protected]?subject=RE:%20ASR%20Support%20Question

migrating sql server 2012 to azure using azure site ... · pdf filebefore we can get started...

Documents