Migrating a self-managed SQL Server database to ApsaraDB RDS for SQL Server using the physical protocol gateway transfers data at the block level via the native SQL Server backup protocol. This method delivers higher throughput and more stable migration compared to logical data migration (JDBC-based), making it suitable when your source runs SQL Server on Windows and you can accept a brief destination database outage during migration.
Choose the right migration method
Before starting, confirm that physical gateway migration fits your scenario.
| Factor | Physical gateway migration | Logical data migration | When to use physical gateway |
|---|---|---|---|
| Migration principle | Native physical backup protocol writes data as blocks | JDBC protocol reads SQL statements and writes to destination | You need maximum throughput and your source runs SQL Server on Windows |
| Operating system | SQL Server on Windows only (desktop: Windows XP or later; server: Windows Server 2003 or later) | No restriction | Your source OS is Windows |
| Gateway required | Install physical protocol gateway on the source server | No gateway required | You can install software on the source server |
| Network | Source server must connect to Alibaba Cloud network | Database port must be open, or a leased line must be established | Your source server has internet or VPC access to Alibaba Cloud |
| Source database permissions | sysadmin role | SELECT (schema and full migration); sysadmin (incremental migration) | You have sysadmin access to the source database |
| Destination database version | Same or later than source | Earlier or later than source | Your destination version is the same or newer |
| Destination database access | Inaccessible during migration | Readable and writable during migration | Brief destination downtime during migration is acceptable |
| Unsupported data | Memory tables; FileStream and FileTables fields | See logical migration limits | Your database does not use memory tables or FileStream/FileTables |
| Migration scenarios | Self-managed databases on ECS instances, in data centers, or on third-party cloud servers | Self-managed or cloud-hosted databases | Your source is a self-managed database, not an RDS instance |
| Migration efficiency | High | Medium | — |
| ETL support | Not supported | Supported | You do not need data transformation during migration |
| Table-level filtering | Not supported | Supported | You do not need to filter specific tables |
| Database-level filtering | Supported | Supported | — |
If your source server cannot access the internet directly but uses a bastion host, see Migrate data from a self-managed SQL Server database to an ApsaraDB RDS for SQL Server instance by using the physical gateway on a bastion host.
Prerequisites
Before you begin, make sure that you have:
-
A self-managed SQL Server database running SQL Server 2019, 2017, 2016, 2014, 2012, 2008 R2, or 2005, hosted on an ECS instance, in a data center, or on a third-party cloud server (not on an RDS instance)
-
An ApsaraDB RDS for SQL Server instance running SQL Server 2019, 2017, 2016, 2012, or 2008 R2, at the same or a later major version than the source database
-
The physical protocol gateway of Data Disaster Recovery installed on the same server as the source database, in the same region as the destination RDS instance — see Appendix: Create a physical protocol gateway
-
An AccessKey pair (AccessKey ID and AccessKey secret) for authentication when registering the gateway — see Obtain an AccessKey pair
-
(Resource Access Management (RAM) users only) The AliyunDBSFullAccess permission to add a backup gateway — see Grant permissions to a RAM user
The AliyunDBSFullAccess permission is granted to your Alibaba Cloud account by default when you activate Data Disaster Recovery. After you add a backup gateway, it is visible in the Data Disaster Recovery console to all RAM users in your account.
Limitations
| Category | Description |
|---|---|
| Source database | - SQL Server on Windows only. Desktop OS: Windows XP or later. Server OS: Windows Server 2003 or later.<br>- Source database size cannot exceed the remaining storage of the destination RDS instance.<br>- Source server must have internet access.<br>- Source database name cannot match the destination database name on the RDS instance.<br>- Source database name cannot use reserved names: master, tempdb, msdb, model, distribution, rdscore, sys_info.<br>- Network requirements: if the source firewall is disabled and the database is on an ECS instance, connect over a virtual private cloud (VPC) or the internet; if the source firewall is disabled and the database is not on an ECS instance, connect over the internet; if the source firewall is enabled, allow requests from *.aliyuncs.com. |
| Database version and edition | Destination SQL Server version must be the same or later than the source. Version order: 2019 > 2017 > 2016 > 2012 > 2008 R2 > 2005. Edition order: Developer > Standard > Web > Express. For supported mappings by edition, see Supported migration mappings by SQL Server edition. |
| In-Memory OLTP and Mirroring | If the In-Memory Online Transaction Processing (OLTP) feature is enabled on the source database, the destination RDS instance cannot be High-availability Edition (Mirroring is incompatible with In-Memory OLTP). |
| Number of databases | The destination RDS instance has a maximum database limit based on instance type. Verify the limit before migrating multiple databases. See Maximum number of databases. |
| Other | - You cannot back up databases while a physical migration is in progress. To back up during migration, enable COPY_ONLY.<br>- FileStream and FileTables fields cannot be migrated.<br>- Memory tables cannot be migrated.<br>- You can migrate a single database, multiple databases, or the entire instance. |
Usage notes
-
During migration, data can still be written to the source database incrementally. Stop writing to the source during the workload switchover to prevent data inconsistency.
-
During incremental migration, the destination RDS instance becomes temporarily unavailable. Switch workloads to the RDS instance only after incremental migration completes.
Supported migration mappings by SQL Server edition
| Source edition | Destination edition |
|---|---|
| SQL Server Developer, Standard, Web, and Express | SQL Server Enterprise |
| SQL Server Standard, Web, and Express | SQL Server Standard |
| SQL Server Web and Express | SQL Server Web |
Migrate your data
Step 1: Open the Data Migration page
Use one of the following methods to open the Data Migration page, then select the region where the migration instance resides.
DTS console
-
Log on to the DTS console.
-
In the left-side navigation pane, click Data Migration.
-
In the upper-left corner, select the region where the migration instance resides.
DMS console
The actual navigation may vary based on your DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console.
-
Log on to the DMS console.
-
In the top navigation bar, move the pointer over Data + AI > DTS (DTS) > Data Migration.
-
From the drop-down list to the right of Data Migration Tasks, select the region where the migration instance resides.
Step 2: Configure the migration task
-
Click Create Task.
-
Configure the source and destination databases using the parameters in the following table.
WarningAfter configuring the source and destination databases, read the Limits displayed at the top of the page. Skipping this step may cause task failure or data inconsistency.
Section Parameter Description N/A Task Name The name of the DTS task. DTS generates a name automatically. Specify a descriptive name to identify the task. The name does not need to be unique. Source Database Select a DMS database instance Select an existing database instance to auto-populate parameters, or leave blank to configure manually. Database Type Select SQL Server. Access Method Select Physical Protocol. Instance Region The region where the source SQL Server database resides. Physical Protocol Gateway (DBS Backup Gateway) The physical protocol gateway to use. To install one, see Appendix: Create a physical protocol gateway. Hostname or IP address The hostname or IP address of the source SQL Server database. Default: localhost.Port Number The service port of the source SQL Server database. Default: 1433. Destination Database Select a DMS database instance Select an existing instance to auto-populate parameters, or leave blank to configure manually. Database Type Default: SQL Server. Access Method Default: Alibaba Cloud Instance. Instance Region The region where the destination ApsaraDB RDS for SQL Server instance resides. Instance ID The ID of the destination ApsaraDB RDS for SQL Server instance. Database Account The database account for the destination instance. See Create a privileged account or a standard account and Modify the permissions of an account. Database Password The password for the destination database account. -
Click Test Connectivity and Proceed.
-
In the CIDR Blocks of DTS Servers dialog box, click Test Connectivity and Proceed. DTS automatically adds its CIDR blocks to the IP address whitelist or security group rules of Alibaba Cloud database instances and ECS-hosted databases. For databases hosted across multiple ECS instances, or databases in data centers or on third-party cloud servers, manually add the DTS CIDR blocks. See Add the CIDR blocks of DTS servers.
WarningAdding public CIDR blocks of DTS servers to a database whitelist or ECS security group introduces security risks. Before proceeding, take preventive measures such as strengthening credentials, limiting exposed ports, authenticating API calls, auditing whitelist rules regularly, and blocking unauthorized CIDR blocks. Alternatively, connect DTS to your database using Express Connect, VPN Gateway, or Smart Access Gateway.
-
Select the objects to migrate and configure the following settings.
Parameter Description Task Stages Select Full Data Migration (required) for a one-time migration. Select both Full Data Migration and Incremental Data Migration to keep data in sync during migration and minimize downtime. NoteIf you do not select Incremental Data Migration, stop writing data to the source during migration to ensure data consistency.
Source Objects Select one or more objects from the Source Objects section and click the right arrow icon to move them to Selected Objects. You can migrate a single database, multiple databases, or the entire instance. Selected Objects The objects to migrate. -
Click Next: Advanced Settings and configure the following settings.
Parameter Description Monitoring and Alerting Configure alerting for the migration task. If the task fails or migration latency exceeds the threshold, alert contacts receive notifications. Select No to skip, or Yes to configure the alert threshold and notification settings. See Configure monitoring and alerting when you create a DTS task. Retry Time for Failed Connection The retry duration after a connection fails. Valid values: 10–1440 minutes. Default: 720 minutes. Set a value greater than 30 minutes. If DTS reconnects within the retry window, the migration resumes. Otherwise, the task fails. NoteIf multiple tasks share the same source or destination database, the shortest retry time applies. DTS instance charges accrue during retries — set the retry window to match your business requirements.
Step 3: Save and precheck
-
Click Next: Save Task Settings and Precheck.
DTS runs a precheck before starting migration. The task cannot start until it passes all checks. If a check fails, click the info icon next to the failed item to view the cause, fix the issue, and run the precheck again. You can also ignore the failed items and start a new precheck.
-
After Success Rate reaches 100%, click Next: Purchase Instance.
Step 4: Purchase and start
-
On the buy page, read and accept the terms of service.
-
Click Buy and Start, then click Confirm to start the migration task.
To view migration progress, click the task ID on the Data Migration Tasks page and open the Task Management tab.
You can also track progress in the ApsaraDB RDS console. Go to the Instances page, click the instance name, then click Backup and Restoration.
Step 5: Switch workloads to the cloud
-
When full migration reaches 100% and incremental migration is in the Running state, go to Task Management > Incremental Data Migration and click the button to switch workloads to the cloud.
-
In the confirmation dialog, click Start Now and wait for the switchover to complete.
To ensure data consistency, stop writing data to the source instance before initiating the switchover. The switchover takes several minutes.
Appendix: Create a physical protocol gateway
A physical protocol gateway is a local agent that enables DTS to read native SQL Server backup data from your source server.
Prerequisites
Assign the sysadmin role to the NT AUTHORITY\SYSTEM account by running the following SQL statement on the source server:
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT AUTHORITY\SYSTEM]
GO
Usage notes
AliyunDBSAgent sets the recovery model of the migrated database to Full. If data is continuously written to the database during migration, this consumes disk space on the source server. After migration completes, run the following statement to reset the recovery model:
ALTER DATABASE <database_name> SET RECOVERY Simple;
Installation steps
-
On the Configure Source and Destination Databases page, click Create Physical Protocol Gateway.
-
In the Installation Command dialog box, configure the Region of Backup Gateway and Network Type of Backup Gateway parameters. Then copy the installation command and download the installation package.
Select Public Network to access Data Disaster Recovery using a public IP address. Select ECS Private Network/VPC to access Data Disaster Recovery using an Alibaba Cloud leased line.
-
Install AliyunDBSAgent on the Windows server where the source database runs: To confirm that the gateway installed successfully, check the log file at
C:\Program Files\aliyun\dbs_agent\logs\agent.log. A heartbeat message in the log indicates a successful installation.-
Double-click the
setup.exefile from the downloaded package. -
Select the installation language, click OK, then click Next.
-
Accept the license agreement and click Next.
-
Select Physical Protocol Gateway (DBS Backup Gateway) and click Next.
-
Select an installation directory, click Next, then click Yes.
-
Confirm the region in the Agent Region field, enter the AccessKey ID and AccessKey secret, then click Next. > Important: The region must match the region of the destination RDS instance. The AccessKey pair is stored in plaintext in
.\config\dbs-agent.confin the installation directory. -
Confirm the component packages to install and click Next. Installation takes approximately 1–5 minutes.
-
Click Done.
-
-
In the Installation Command dialog box, click Installed.
-
Verify that the AliyunDBSAgent service is running:
-
Open the Run dialog box, type
services.msc, and click OK. -
In the Services manager, check whether AliyunDBSAgent is running. If not, right-click AliyunDBSAgent and select Start.
The system starts the backup gateway service automatically. You can also start or stop it manually in the Services manager.
-
-
Confirm the gateway appears in the Data Disaster Recovery console: on the Backup Gateways page, click Refresh in the upper-right corner. The newly created gateway name starts with
DTS_.
Related topics
-
Migrate data from a self-managed SQL Server database to an ApsaraDB RDS for SQL Server instance by using the physical gateway on a bastion host — if your source server cannot access the internet directly
-
Migrate data from a self-managed SQL Server database to an ApsaraDB RDS for SQL Server instance — for logical migration using JDBC
-
Permissions required for database accounts — detailed permission requirements for logical migration