Merge pull request #35593 from rwestMSFT/rw-1017-vm-portal-migration

[Azure DMS] SQL VM migration via Azure portal

Author: denrea

.openpublishing.publish.config.json

@@ -188,6 +188,7 @@
   "redirection_files": [
     ".openpublishing.redirection.azure-sql.json",
     ".openpublishing.redirection.azure-data-studio.json",
+    ".openpublishing.redirection.data-migration.json",
     ".openpublishing.redirection.powershell.json",
     ".openpublishing.redirection.ssms.json",
     ".openpublishing.redirection.stretch-database.json",

.openpublishing.redirection.data-migration.json

@@ -0,0 +1,9 @@
+{
+  "redirections": [
+    {
+      "source_path": "data-migration/sql-server/virtual-machines/database-migration-service.md",
+      "redirect_url": "/data-migration/sql-server/virtual-machines/database-migration-service-offline",
+      "redirect_document_id": false
+    }
+  ]
+}

data-migration/includes/create-database-migration-service-instance.md

@@ -9,8 +9,6 @@ ms.collection:
 ms.custom: sfi-image-nochange
 ---
 
-### Create a Database Migration Service instance
-
 **Step 1:** In the [Azure portal](https://portal.azure.com/#browse/Microsoft.DataMigration%2Fservices), navigate to the **Azure Database Migration Service** page. Create a new instance of Azure Database Migration Service, or reuse an existing instance that you created earlier.
 
 #### Use an existing instance of Database Migration Service

data-migration/includes/data-migration-storage-access.md

@@ -0,0 +1,83 @@
+---
+author: rwestMSFT
+ms.author: randolphwest
+ms.date: 12/10/2025
+ms.service: azure-database-migration-service
+ms.topic: include
+---
+
+Make sure your resources can access the Azure Storage account. Depending on your database backup location and desired storage account network settings, refer to the following table for the various migration scenarios and network configurations:
+
+| Scenario | SMB network share | Azure Storage account container |
+| --- | --- | --- |
+| **Enabled from all networks** | No extra steps | No extra steps |
+| **Enabled from selected virtual networks and IP addresses** | [On-premises self-hosted integration runtime (SHIR)](?tabs=dms-on-prem-shir#dms-backup-storage) | [Backups stored in Azure Storage container](?tabs=dms-backups-azure-storage#dms-backup-storage) |
+| **Enabled from selected virtual networks and IP addresses + private endpoint** | [Azure VM self-hosted integration runtime (SHIR)](?tabs=dms-azure-vm-shir#dms-backup-storage) | [Backups stored in Azure Storage container (Private endpoint)](?tabs=dms-backups-private-endpoint#dms-backup-storage) |
+
+<a id="dms-backup-storage"></a>
+
+### [On-premises SHIR](#tab/dms-on-prem-shir)
+
+#### On-premises self-hosted integration runtime (SHIR)
+
+If you install your SHIR on your on-premises network, follow these steps:
+
+1. Connect to the Azure portal from the SHIR machine.
+
+1. Open your Azure Storage account, and go to the **Networking** pane.
+
+1. Make sure **Public network access** is set to **Enabled from selected virtual networks and IP addresses**.
+
+1. In the **Firewall** section, select the **Add your client IP address** checkbox.
+
+1. Enter the client IP address of the host machine, and select **Save**.
+
+### [Azure VM SHIR](#tab/dms-azure-vm-shir)
+
+#### Azure VM self-hosted integration runtime (SHIR)
+
+If you host your SHIR on an Azure VM, add the virtual network of the VM to the Azure Storage account, because the VM has a non-public IP address that you can't add to the IP address range section.
+
+1. Connect to the Azure portal, and open your Azure Storage account.
+
+1. Open your Azure Storage account, and go to the **Networking** pane.
+
+1. Select the **Add existing virtual network** checkbox.
+
+1. Select the subscription, virtual network, and subnet of the Azure VM hosting the SHIR. You can find this information on the **Overview** page of the Azure Virtual Machine. The subnet might say **Service endpoint required**. If so, select **Enable**.
+
+1. Select **Save**.
+
+### [Azure Storage](#tab/dms-backups-azure-storage)
+
+#### Backups stored in Azure Storage container
+
+If you place your backups directly into an Azure Storage container, you don't need to perform the preceding steps because there's no Integration Runtime communicating with the Azure Storage account.
+
+However, you still need to ensure that the target SQL Server instance can communicate with the Azure Storage account to restore the backups from the container.
+
+1. Connect to the Azure portal, and open your Azure Storage account.
+
+1. Open your Azure Storage account, and go to the **Networking** pane.
+
+1. Select the **Add existing virtual network** checkbox.
+
+1. Specify the target SQL Server instance virtual network, and select **Save**.
+
+### [Azure Storage (Private endpoint)](#tab/dms-backups-private-endpoint)
+
+#### Backups stored in Azure Storage container (Private endpoint)
+
+If you set up a private endpoint on your Azure Storage account, follow these steps:
+
+1. Connect to the Azure portal, and open your Azure Storage account.
+
+1. Open your Azure Storage account, and go to the **Networking** pane.
+
+1. Select the **Add existing virtual network** checkbox.
+
+1. Specify the subnet of the private endpoint, and select **Save**.
+
+The private endpoint must be hosted in the same virtual network as the target SQL Server instance. If it isn't, create another private endpoint using the process in the Azure Storage account configuration section.
+
+---

data-migration/includes/prerequisites-base.md

@@ -0,0 +1,53 @@
+---
+author: rwestMSFT
+ms.author: randolphwest
+ms.date: 12/10/2025
+ms.service: azure-database-migration-service
+ms.topic: include
+---
+
+- Create a target instance of [SQL Server on Azure Virtual Machines](/azure/azure-sql/virtual-machines/windows/create-sql-vm-portal).
+
+  If you have an existing Azure VM, register it with the [SQL Server IaaS Agent extension in Full management mode](/azure/azure-sql/virtual-machines/windows/sql-server-iaas-agent-extension-automate-management#management-modes).
+
+- Ensure that the logins you use to connect to the source SQL Server instance are members of the **sysadmin** server role, or have `CONTROL SERVER` permission.
+
+- Provide an SMB network share, Azure Storage account file share, or Azure Storage account blob container that contains your full database backup files and subsequent transaction log backup files. Azure DMS uses the backup location during database migration.
+
+  - Always use a dedicated storage account for migration. Sharing it with other workloads can lead to conflicts and security risks.
+
+  - Once migration is done, either rotate the Storage Account Key to keep backups secure, or delete the storage account if it's no longer needed.
+
+  - Azure DMS doesn't take database backups, and doesn't initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.
+
+  - If your database backup files are in an SMB network share, [create an Azure Storage account](/azure/storage/common/storage-account-create) that allows Azure DMS to upload the database backup files, and to migrate databases. Make sure you create the Azure Storage account in the same region where you create your instance of Azure DMS.
+
+  - You can write each backup to either a separate backup file or to multiple backup files. Appending multiple backups such as full and transaction logs into a single backup media isn't supported.
+
+  - You can provide 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.
+
+- If you're migrating a database protected by transparent data encryption (TDE), migrate the certificate from the source SQL Server instance to SQL Server on an Azure VM before you migrate data. For more information, see [Move a TDE protected database to another SQL Server](/sql/relational-databases/security/encryption/move-a-tde-protected-database-to-another-sql-server).
+
+  > [!TIP]  
+  > If your database contains sensitive data protected by [Always Encrypted](/sql/relational-databases/security/encryption/configure-always-encrypted-using-sql-server-management-studio), the migration process automatically migrates your Always Encrypted keys to your target instance of SQL Server on an Azure VM.
+
+- If your database backups are on a network file share, provide a computer on which you can install a [self-hosted integration runtime](/azure/data-factory/create-self-hosted-integration-runtime) to access and migrate database backups. The migration wizard gives you the download link and authentication keys to download and install your self-hosted integration runtime.
+
+  In preparation for the migration, ensure that the computer on which you install the self-hosted integration runtime has the following outbound firewall rules and domain names enabled:
+
+  | Domain names | Outbound port | Description |
+  | --- | --- | --- |
+  | Public cloud: `{datafactory}.{region}.datafactory.azure.net`<br />or`*.frontend.clouddatahub.net`<br /><br />Azure Government: `{datafactory}.{region}.datafactory.azure.us`<br />Microsoft Azure operated by 21Vianet: `{datafactory}.{region}.datafactory.azure.cn` | 443 | Required by the self-hosted integration runtime to connect to Azure DMS.<br />For a newly created data factory in a public cloud, locate the fully qualified domain name (FQDN) from your self-hosted integration runtime key, in the format `{datafactory}.{region}.datafactory.azure.net`.<br />For an existing data factory, if you don't see the FQDN in your self-hosted integration key, use `*.frontend.clouddatahub.net` instead. |
+  | `download.microsoft.com` | 443 | Required by the self-hosted integration runtime for downloading the updates. If you disable autoupdate, you can skip configuring this domain. |
+  | `*.core.windows.net` | 443 | Used by the self-hosted integration runtime that connects to the Azure Storage account to upload database backups from your network share |
+
+  > [!TIP]  
+  > If you already store your database backup files in an Azure Storage account, you don't need a self-hosted integration runtime during the migration process.
+
+- If you use a self-hosted integration runtime, make sure that the computer on which the runtime is installed can connect to the source SQL Server instance and the network file share where backup files are located.
+
+- Enable outbound port 445 to allow access to the network file share. For more information, see [recommendations for using a self-hosted integration runtime](/azure/dms/migration-using-azure-data-studio#recommendations-for-using-a-self-hosted-integration-runtime-for-database-migrations).
+
+- If you're using Azure DMS for the first time, make sure that the `Microsoft.DataMigration` [resource provider is registered in your subscription](/azure/dms/quickstart-create-data-migration-service-portal#register-the-resource-provider).

data-migration/sql-server/database/database-migration-service.md

@@ -384,6 +384,8 @@ Now, you can migrate both the database schema and data using Database Migration
 > [!NOTE]  
 > If no tables exist on the Azure SQL Database target, or no tables are selected before starting the migration, the **Next** button isn't available to initiate the migration. If no table exists on the target, then you must select the schema migration option to move forward.
 
+### Create a Database Migration Service instance
+
 [!INCLUDE [create-database-migration-service-instance](../../includes/create-database-migration-service-instance.md)]
 
 ### Start a new migration