# Move Azure SQL Database and Virtual Machine resources to another region using Azure Resource Mover.

## Introduction
[**Azure Resource Mover**](https://docs.microsoft.com/en-us/azure/resource-mover/overview) might move resources to different Azure regions to:
* **Align to a region launch**: Move resources to a newly introduced Azure region that wasn't previously available.
* **Align for services/features**: Move resources to take advantage of services or features that are available in a specific region.
* **Respond to business developments**: Move resources to a region in response to business changes, such as mergers or acquisitions.
* **Align for proximity**: Move resources to a region local to your business.
* **Meet data requirements**: Move resources to align with data residency requirements, or data classification needs.
* **Respond to deployment requirements**: Move resources that were deployed in error, or move in response to capacity needs.
* **Respond to decommissioning**: Move resources because a region is decommissioned.

## Scenario

* In this lab, you will move **Azure SQL** databases, elastic pools, **Azure VMs**, and related network/storage resources to a different **Azure** region, using Azure Resource Mover.


## Prerequisites
* If you don't have an **Azure subscription**, create a free account before you begin. Then sign in to the [**Azure portal**](https://portal.azure.com/).
* [**Make sure**](https://docs.microsoft.com/en-us/azure/resource-mover/common-questions) the regions are currently supported
* [**Make sure**](https://docs.microsoft.com/en-us/azure/resource-mover/support-matrix-move-region-azure-vm) the versions that support for moving **Azure VMs** between Azure regions
* [**Make sure**](https://docs.microsoft.com/en-us/azure/resource-mover/support-matrix-move-region-sql) the versions that support for moving **Azure SQL** resources between Azure regions
* Make sure in the target region, create a target server for each source server.

## Step by step

### Step 1: Create a VM

1. Type **virtual machines** in the search.


* Under **Services**, select **Virtual machines**.
* In the **Virtual machines** page, select **+ Add**. And select **+ virtual machine**.


* In the **Basics** tab, under **Project details**, make sure the correct subscription is selected, In **Resource group**, select an existing resource group, or create a new one.


* Under **Instance details**, type the name for the **Virtual machine name**, choose *East US* for your **Region**, and choose Red Hat for your **Image**. Leave the other defaults.


* Under **Administrator account**, select **Password**.
* Under **Inbound port rules** > **Public inbound ports**, choose **Allow selected ports** and then select **SSH (22)** and **HTTP (80)** and **SSH (443)** from the drop-down.
* Leave the remaining defaults and then select the **Review + create** button at the bottom of the page.


2. On the **Create a virtual machine page**, you can see the details about the VM you are about to create. When you are ready, select **Create**.


### Step 2: Create an Azure SQL

1. Sign in to the **Azure portal**

2. In the search box, type *Azure SQL*. Under **Services**, select **Azure SQL**.


3. In **Azure SQL**, select **+New**.


4. In **Select SQL deployment option** > **SQL databases**, select **Single databases**, and select **Create**.


### Step 3: Create an Azure SQL Databases

>Make sure in the target region, create a target server for each source server.

1. Under **Basics** screen.
* In **Resource group**, select an existing resource group for the vault, or create a new one.
* In **Database details** named for your Databases, and select an existing **Server**, or create a new one.


* Select **Yes** for SQL elastic pool, and select an existing **Server**, or create a new one.
* Leave the other defaults, and select **Review + create**


* Select **Create**


### Step 4: Select resources

1. In the **Azure portal**, search for **Resource mover**. Then, under **Services**, select **Azure Resource Mover**.

>You can select any supported resource type in any resource group in the selected source region.

>You move resources to a target region in the same subscription as the source region. If you want to change the subscription, you can do that after the resources are moved.


2. Select **Move access regions**


3. In **Move resources** > **Source + destination**, select the source subscription and region.

4. In **Destination**, select the region to which you want to move the resources. Then click **Next**.


5. In **Resources to move**, click **Select resources**.


6. In **Select resources**, select the resources. You can only add resources supported for the move. Then click **Done**.


7. In **Resources to move**, click **Next**.


8. In **Review**, check the source and destination settings. Verify that you understand that metadata about the move will be stored in a resource group created for this purpose in the metadata region.


9. Click **Proceed**, to begin adding the resources.


10. After the add process finishes successfully, click **Adding resources for move** in the notification icon.


11. After clicking the notification, review the resources on the **Across regions** page.


### Step 5: Resolve dependencies

1. In **Across regions**, if resources show a *Validate dependencies* message in the **Issues** column, click the **Validate dependencies** button. The validation process begins.

2. If dependencies are found, click **Add dependencies**.


3. In **Add dependencies**, leave the default **Show all dependencies** option.

* Show all dependencies iterates through all of the direct and indirect dependencies for a resource. For example, for a VM it shows the NIC, virtual network, network security groups (NSGs), etc.
* Show first-level dependencies only show only direct dependencies. For example, for a VM it shows the NIC, but not the virtual network.

4. In **Add dependencies**, select the dependent resources > **Add dependencies**. Monitor progress in the notifications.


5. Add additional dependencies if needed, and validate dependencies again.

6. On the **Across regions** page, verify that resources are now in a Prepare pending state, with no issues.

### Step 6: Prepare to move the source resource group

>During the Prepare process, Resource Mover generates Azure Resource Manager (ARM) templates using the resource group settings. Resources inside the resource group aren't affected.

1. In **Across regions**, select the source resource group > **Prepare**.


2. In **Prepare resources**, click **Prepare**.


3. After preparing the resource group, it's in the **Initiate move pending** state.


### Step 7: Move the source resource group

1. In **Across regions**, select the resource group > **Initiate Move**


2. ln **Move Resources**, click **Initiate move**. The resource group moves into an **Initiate move in progress** state.


3. After initiating the move, the target resource group is created, based on the generated ARM template. The source resource group moves into a **Commit move pending** state.


4. To commit and finish the move process:

* In **Across regions**, select the resource group > **Commit move**.


* ln **Move Resources**, click **Commit**.


>After committing the move, the source resource group is in a **Delete source pending** state.


### Step 8: Prepare resources to move

>Now that the source resource group is moved, you can prepare to move other resources that are in the **Prepare pending** state.

1. In **Across regions**, verify that resources are now in a **Prepare pending** state, with no issues. If they're not, validate again and resolve any outstanding issues.


* Select the resources you want to prepare.
* Select **Prepare**.



>* During the preparation process, the Azure Site Recovery Mobility agent is installed on VMs, to replicate them.
>* VM data is replicated periodically to the target region. This doesn't affect the source VM.
>* Resource Move generates ARM templates for the other source resources.
>* After preparing resources, they're in an **Initiate move pending** state.


2. Initiate the move

* In **Across regions**, select resources with state **Initiate move pending**. Then click **Initiate move**.


* In **Move resources**, click **Initiate move**.


>* For VMs, replica VMs are created in the target region. The source VM is shut down, and some downtime occurs (usually minutes).
>* Resource Mover recreates other resources using the ARM templates that were prepared. There's usually no downtime.
>* After moving resources, they're in a **Commit move pending** state.

### Step 9: Discard or commit?
>After the initial move, you can decide whether you want to commit the move, or to discard it.

> **Discard**: You might want to discard a move if you're testing, and you don't want to move the source resource. Discarding the move returns the resource to a state of **Initiate move pending**.
> **Commit**: Commit completes the move to the target region. After committing, a source resource will be in a state of **Delete source pending**, and you can decide if you want to delete it.

1. Commit the move

* In **Across regions**, select resources with state **Commit move pending**, and click **Commit move**.

* In **Commit resources**, click **Commit**.


>* After committing the move, VMs stop replicating. The source VM isn't impacted by the commit.
>* Commit doesn't impact source networking resources.
>* After committing the move, resources are in a **Delete source pending** state.


### Step 10: Configure settings after the move
* The Mobility service isn't uninstalled automatically from VMs. Uninstall it manually, or leave it if you plan to move the server again.
* Modify Azure role-based access control (Azure RBAC) rules after the move.

### Step 11: Move the SQL Server

>Assign a target SQL Server in the target region and commit the move.

1. Assign a target SQL Server

* In **Across regions**, for the SQL Server resource, in the **Destination configuration** column, click **Resource not assigned**.


* Select an existing SQL Server resource in the target region


>The source SQL Server state changes to **Commit move pending**.


2. Commit the SQL Server move

* In **Across regions**, select the SQL Server, and then click **Commit move**.


* In **Commit resources**, click **Commit**.


* After the commit, the SQL Server is now in a **Delete source pending** state.


3. Prepare resources to move

>With the source SQL Server moved, you can prepare to move the other resources.

* Prepare an elastic pool
* In **Across regions**, select the source elastic pool, and then click **Prepare**.


* In **Prepare resources**, click **Prepare**.
* When notifications show that the preparation process was successful, click **Refresh**.

>The elastic pool is now in an **Initiate move pending** state.


* In **Across regions**, select the source **elastic pool**, and then click **Initiate move**.
* In **Move resources**, click **Initiate**.
* When notifications show that the preparation process was successful, click **Refresh**.

* In **Across regions**, select the source **elastic pool**, and then click **Commit move**.


* In **Commit resources**, click **Initiate**.
* When notifications show that the preparation process was successful, click **Refresh**.


>The elastic pool is now in a **Delete source pending** state.


4. Prepare a single database

* In **Across regions**, select the single database (not in an elastic pool), and then click **Prepare**.


* In **Prepare resources**, click **Prepare**.
* When notifications show that the preparation process was successful, click **Refresh**.


>The database is now in an **Initiate move pending** state and has been created in the target region.


5. Move databases

>Start to move the databases.

* In **Across regions**, select resources with state **Initiate move pending**. Then click **Initiate move**.


* In **Move resources**, click **Initiate move**.


>Databases are now in a **Commit move pending** state.

### Step 12: Discard or commit?
>After the initial move, you can decide whether you want to commit the move, or to discard it.

> **Discard**: You might want to discard a move if you're testing, and you don't want to move the source resource. Discarding the move returns the resource to a state of **Initiate move pending**.
> **Commit**: Commit completes the move to the target region. After committing, a source resource will be in a state of **Delete source pending**, and you can decide if you want to delete it.

1. Commit the move

* Check that the SQL Server is a **Commit move pending** state.

* Update database connection strings to the target region, before you commit.

* In **Across regions**, select the SQL resources, and then click **Commit move**.

* In **Commit resources**, click **Commit**.


>Some downtime occurs for SQL databases during the commit process. Committed databases and elastic pools are now in a **Delete source pending** state. After the commit, update database-related settings, including firewall rules, policies, and alerts, on the target database.


### Check the resource moved or not.

1. Move to the resource group **ResourceMoverRG-eastus-eastus2-eus2**


2. Move to the resource group **Mover-eastus2**


## Cleanup resources

1. Delete source resources after commit

>After the move, you can optionally delete resources in the source region.
>* A few resources, for example, **key vaults** and **SQL Server servers**, can't be deleted from the portal, and must be deleted from the resource property page.
>* **SQL Server servers** can't be deleted from the portal, and must be deleted from the resource property page.

* In **Across Regions**, click the name of the source resource that you want to delete.
* Select **Delete source**.



2. Delete additional resources created for move

>After the move, you can manually delete the move collection, and Site Recovery resources that were created.

* Locate the resources in resource group ResourceMoverRG-eastus-eastus2-eus2.
* Check that all the **VM** and other source resources in the source region have been moved or deleted. This ensures that no pending resources are using them.




## Conclusion

In this lab, You learn how to:

1. Check prerequisites and requirements.
2. Select the resources you want to move.
3. Resolve resource dependencies.
4. Prepare and move the **SQL Server** to the target region.
5. Prepare and move databases and **elastic pools**.
6. Decide whether you want to **discard** or **commit** the move.
7. Optionally remove resources in the source region after the move.
8. Prepare and move the source resource group.
9. Prepare and move the other resources.