Migrate databases at scale using automation (Preview)
The Azure SQL Migration extension for Azure Data Studio brings together a simplified assessment, recommendation, and migration experience that delivers the following capabilities:
An enhanced assessment mechanism can evaluate SQL Server instances, identifying databases ready for migration to the different Azure SQL targets.
An SKU recommendation engine (Preview) that collects performance data from the source SQL Server instance on-premises, generating right-sized SKU recommendations based on your Azure SQL target.
A reliable Azure service powered by Azure Database Migration Service that orchestrates data movement activities to deliver a seamless migration experience.
The ability to run online (for migrations requiring minimal downtime) or offline (for migrations where downtime persists through the migration) migration modes to suit your business requirements.
The flexibility to create and configure a self-hosted integration runtime to provide your own compute for accessing the source SQL Server and backups in your on-premises environment.
With automation tools like the PowerShell - Azure DataMigration Service Module or Azure CLI, you can apply the capabilities of the Azure SQL Migration extension together with Azure Database Migration Service to migrate one or more databases at scale (including databases across multiple SQL Server instances).
The following sample scripts can be referenced to suit your migration scenario using Azure PowerShell or Azure CLI:
| Migration scenario | Scripting language |
|---|---|
| SQL Server assessment | PowerShell / Azure CLI |
| SQL Server to Azure SQL Managed Instance (using file share) | PowerShell / Azure CLI |
| SQL Server to Azure SQL Managed Instance (using Azure storage) | PowerShell / Azure CLI |
| SQL Server to SQL Server on Azure Virtual Machines (using file share) | PowerShell / Azure CLI |
| SQL Server to SQL Server on Azure Virtual Machines (using Azure Storage) | PowerShell / Azure CLI |
| SQL Server to Azure SQL Database | PowerShell / Azure CLI |
| SKU recommendations (Preview) | PowerShell / Azure CLI |
| End-to-End migration automation | PowerShell / Azure CLI |
| End-to-End migration automation for multiple databases | PowerShell / Azure CLI |
Prerequisites
Pre-requisites that are common across all supported migration scenarios using Azure PowerShell or Azure CLI are:
Have an Azure account that is assigned to one of the built-in roles listed below:
Contributor for the target Azure SQL Managed Instance, SQL Server on Azure Virtual Machines or Azure SQL Database and, Storage Account to upload your database backup files from SMB network share (Not applicable for Azure SQL Database).
Reader role for the Azure Resource Groups containing the target Azure SQL Managed Instance, SQL Server on Azure Virtual Machines or Azure SQL Database.
Owner or Contributor role for the Azure subscription.
Azure account is only required when running the migration steps and isn't required for assessment or Azure recommendation steps process.
Create a target Azure SQL Managed Instance, SQL Server on Azure Virtual Machine, or Azure SQL Database
If your target is Azure SQL Database you have to migrate database schema from source to target using SQL Server dacpac extension or, SQL Database Projects extension for Azure Data Studio.
If you have an existing Azure Virtual Machine, it should be registered with SQL IaaS Agent extension in Full management mode.
If your target is Azure SQL Managed Instance or SQL Server on Azure Virtual Machine ensure that the logins used to connect the source SQL Server are members of the sysadmin server role or have
CONTROL SERVERpermission.If your target is Azure SQL Database, ensure that the login used to connect the source SQL Server is a member, and the
db_datareaderand login for the target SQL server isdb_owner.Use one of the following storage options for the full database and transaction log backup files:
SMB network share
Azure storage account file share or blob container
If your database backup files are provided in an SMB network share, Create an Azure storage account that allows the DMS service to upload the database backup files. Make sure to create the Azure Storage Account in the same region as the Azure Database Migration Service instance is created.
Make sure the Azure storage account blob container is used exclusively to store backup files only. Any other type of files (txt, png, jpg, etc.) will interfere with the restore process leading to a failure.
Azure Database Migration Service doesn't initiate any backups, and instead uses existing backups, which you might already have as part of your disaster recovery plan, for the migration.
Each backup can be written to either a separate backup file or multiple backup files. However, appending multiple backups (i.e. full and t-log) into a single backup media isn't supported.
Use compressed backups to reduce the likelihood of experiencing potential issues associated with migrating large backups.
Ensure that the service account running the source SQL Server instance has read and write permissions on the SMB network share that contains database backup files.
The source SQL Server instance certificate from a database protected by Transparent Data Encryption (TDE) must be migrated to the target Azure SQL Managed Instance or SQL Server on Azure Virtual Machine before migrating data. For more information about migrating TDE-enabled databases, see Tutorial: Migrate TDE-enabled databases (preview) to Azure SQL in Azure Data Studio.
Tip
If your database contains sensitive data that is protected by Always Encrypted, migration process using Azure Data Studio with DMS will automatically migrate your Always Encrypted keys to your target Azure SQL Managed Instance or SQL Server on Azure Virtual Machine.
If your database backups are in a network file share, provide a machine to install self-hosted integration runtime to access and migrate database backups. The Azure PowerShell or Azure CLI modules provide the authentication keys to register your self-hosted integration runtime. In preparation for the migration, ensure that the machine where you plan to install the self-hosted integration runtime has the following outbound firewall rules and domain names enabled:
Domain names Outbound ports Description Public Cloud: {datafactory}.{region}.datafactory.azure.net
or*.frontend.clouddatahub.net
Azure Government:{datafactory}.{region}.datafactory.azure.us
China:{datafactory}.{region}.datafactory.azure.cn443 Required by the self-hosted integration runtime to connect to the Data Migration service.
For new created Data Factory in public cloud, locate the FQDN from your Self-hosted Integration Runtime key, which is in format{datafactory}.{region}.datafactory.azure.net. For old Data factory, if you don't see the FQDN in your Self-hosted Integration key, use *.frontend.clouddatahub.net instead.download.microsoft.com443 Required by the self-hosted integration runtime for downloading the updates. If you have disabled auto-update, you can skip configuring this domain. *.core.windows.net443 Used by the self-hosted integration runtime that connects to the Azure storage account for uploading database backups from your network share If your database backup files are already provided in an Azure storage account, self-hosted integration runtime isn't required during the migration process.
When using self-hosted integration runtime, ensure that the machine where the runtime is installed can connect to the source SQL Server instance and the network file share where backup files are located.
Outbound port 445 should be enabled to access the network file share.
If you're using the Azure Database Migration Service for the first time, ensure that Microsoft.DataMigration resource provider is registered in your subscription. You can follow the steps to register the resource provider
If your migration target is Azure SQL Database, you don't need backups to perform this migration. The migration to Azure SQL Database is considered a logical migration involving the database's pre-creation and data movement (performed by DMS).
Automate database migrations
Using Azure PowerShell Az.DataMigration or Azure CLI az datamigration, you can migrate databases by automating the creation of the Azure Database Migration Service, configuring database migrations for online migration, and performing a cutover. There are several more commands and functionality that are documented in Azure Samples.
Example of automating the migration of a SQL Server database using Azure CLI: Step 1: Create Azure Database Migration Service, which will orchestrate your database's migration activities.
#STEP 1: Create Database Migration Service
az datamigration sql-service create --resource-group "myRG" --sql-migration-service-name "myMigrationService" --location "EastUS2"
Step 2: Configure and start online database migration from SQL Server on-premises (with backups in Azure storage) to Azure SQL Managed Instance.
#STEP 2: Start Migration
az datamigration sql-managed-instance create `
--source-location '{\"AzureBlob\":{\"storageAccountResourceId\":\"/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/dbbackupssqlbits\",\"accountKey\":\"myAccountKey\",\"blobContainerName\":\"dbbackups\"}}' `
--migration-service "/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.DataMigration/SqlMigrationServices/myMigrationService" `
--scope "/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.Sql/managedInstances/mySQLMI" `
--source-database-name "AdventureWorks2008" `
--source-sql-connection authentication="SqlAuthentication" data-source="mySQLServer" password="<password>" user-name="sqluser" `
--target-db-name "AdventureWorks2008" `
--resource-group myRG `
--managed-instance-name mySQLMI
Step 3: Perform a migration cutover once all backups are restored to Azure SQL Managed Instance.
#STEP 3: Get migration ID and perform Cutover
$migOpId = az datamigration sql-managed-instance show --managed-instance-name "mySQLMI" --resource-group "myRG" --target-db-name "AdventureWorks2008" --expand=MigrationStatusDetails --query "properties.migrationOperationId"
az datamigration sql-managed-instance cutover --managed-instance-name "mySQLMI" --resource-group "myRG" --target-db-name "AdventureWorks2008" --migration-operation-id $migOpId
If you receive the error "The subscription isn't registered to use namespace 'Microsoft.DataMigration'. See https://aka.ms/rps-not-found for how to register subscriptions", run the following command:
Register-AzResourceProvider -ProviderNamespace "Microsoft.DataMigration"