Data Transmission Service (DTS) lets you migrate databases between instances through a step-by-step console workflow. This tutorial uses an ApsaraDB RDS for MySQL-to-MySQL migration as the example and covers the full process: connecting your databases, selecting migration objects, running a precheck, purchasing a migration instance, and starting the task.
The steps and parameters in this tutorial are based on a MySQL-to-MySQL migration between ApsaraDB RDS for MySQL instances. Your actual configuration depends on your source and destination database types. For supported scenarios, see Overview of data migration scenarios.
Prerequisites
Before you begin, make sure you have:
Source and destination databases that are created and running supported versions. See Overview of data migration scenarios for supported types and versions.
(For self-managed databases) The required environments prepared. See Preparation overview.
A database account on the source instance with the SELECT, REPLICATION CLIENT, and REPLICATION SLAVE permissions on the objects to migrate.
A database account on the destination instance with read and write permissions on the destination database.
Step 1: Open the Data Migration page
Use either the DTS console or the DMS console to reach the Data Migration page.
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 your migration instance will reside.
DMS console
The exact steps may vary depending on your DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console for details.
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 your migration instance will reside.
Step 2: Create a task
Click Create Task to open the task configuration page.
If the page shows a New Configuration Page button in the upper-right corner, click it to switch to the new version. Skip this step if you see Back to Previous Version instead — you are already on the new version.
The new and previous configuration pages have different parameters. Use the new version.
Step 3: Configure the source and destination databases
After filling in the source and destination database details, read the Limits section displayed at the top of the page before proceeding. Skipping this step can cause task failures or data inconsistency.
The following tables describe the parameters for the source and destination databases. In this example, both are ApsaraDB RDS for MySQL instances within the same Alibaba Cloud account.
Source database
| Parameter | Description |
|---|---|
| Task Name | A name for the DTS task. DTS generates one automatically. Specify a descriptive name to make the task easy to identify. The name does not need to be unique. |
| Select a DMS database instance | Not selected in this example. Configure the database parameters below instead. |
| Database Type | The type of the source database. Select MySQL. |
| Access Method | The access method of the source database. Select Alibaba Cloud Instance. |
| Instance Region | The region of the source ApsaraDB RDS for MySQL instance. |
| Replicate Data Across Alibaba Cloud Accounts | Whether the source database belongs to a different Alibaba Cloud account. Select No for this example. |
| RDS Instance ID | The ID of the source ApsaraDB RDS for MySQL instance. |
| Database Account | A database account with the SELECT, REPLICATION CLIENT, and REPLICATION SLAVE permissions on the objects to migrate. |
| Database Password | The password for the database account. |
| Encryption | Use the default setting for this example. |
Destination database
| Parameter | Description |
|---|---|
| Select a DMS database instance | Not selected in this example. Configure the database parameters below instead. |
| Database Type | The type of the destination database. Select MySQL. |
| Access Method | The access method of the destination database. Select Alibaba Cloud Instance. |
| Instance Region | The region of the destination ApsaraDB RDS for MySQL instance. |
| Replicate Data Across Alibaba Cloud Accounts | Whether the destination database belongs to a different Alibaba Cloud account. Select No for this example. |
| RDS Instance ID | The ID of the destination ApsaraDB RDS for MySQL instance. |
| Database Account | A database account with read and write permissions on the destination database. |
| Database Password | The password for the database account. |
| Encryption | Use the default setting for this example. |
Step 4: Test connectivity
Click Test Connectivity and Proceed at the bottom of the page.
DTS automatically updates firewall settings based on where your databases are hosted:
Alibaba Cloud database instances (such as ApsaraDB RDS for MySQL or ApsaraDB for MongoDB): DTS adds its server CIDR blocks to the instance IP address whitelist.
Self-managed databases on a single Elastic Compute Service (ECS) instance: DTS adds its server CIDR blocks to the ECS security group rules. Make sure the ECS instance can reach the database.
Self-managed databases on multiple ECS instances: Manually add DTS server CIDR blocks to the security group rules of each ECS instance.
On-premises or third-party cloud databases: Manually add DTS server CIDR blocks to the database IP address whitelist. See Add the CIDR blocks of DTS servers.
Adding DTS CIDR blocks to your whitelist or security group rules introduces security risks. Before migrating data, take preventive measures such as strengthening credentials, limiting exposed ports, authenticating API calls, auditing whitelist rules regularly, and using Express Connect, VPN Gateway, or Smart Access Gateway to connect your database to DTS.
Step 5: Configure migration objects
Choose what to migrate
On the Configure Objects page, select the objects and migration types.
For this example, select Schema Migration, Full Data Migration, and Incremental Data Migration under Migration Types, then move the objects to migrate from Source Objects to Selected Objects.
The following table describes the key parameters.
| Parameter | Description |
|---|---|
| Migration Types | Choose based on your goal:<br>• Schema Migration + Full Data Migration — copies existing data once, with no ongoing sync. Avoid writing to the source database during migration to prevent data inconsistency.<br>• Schema Migration + Full Data Migration + Incremental Data Migration — keeps the destination in sync during migration, which maintains service continuity. Use this option if your application must remain online during migration.<br><br> Note If you skip Schema Migration, make sure a database and a table are created in the destination database to receive data and enable object name mapping in Selected Objects. |
| Method to Migrate Triggers in Source Database | How to handle triggers from the source database. Configure this only if you have triggers to migrate. See Synchronize or migrate triggers from the source database. Available only when both Schema Migration and Incremental Data Migration are selected. |
| Enable Migration Assessment | Whether to assess schema compatibility (index length, stored procedures, dependent tables) before migration. Selecting Yes increases precheck time. Results appear under Assessment Result and do not affect precheck pass/fail. Available only when Schema Migration is selected. |
| Processing Mode of Conflicting Tables | How to handle tables in the destination that share names with source tables:<br>• Precheck and Report Errors — fails the precheck if identical table names are found. To work around conflicts, use object name mapping to rename tables at the destination.<br>• Ignore Errors and Proceed — skips the name conflict check. Warning This can cause data inconsistency. During full migration, existing records are retained; during incremental migration, existing records are overwritten. If schemas differ, only some columns may migrate or the task may fail entirely. |
| Capitalization of Object Names in Destination Instance | Capitalization policy for database, table, and column names in the destination. Default is DTS default policy. See Specify the capitalization of object names in the destination instance. |
| Source Objects | Select the columns, tables, or databases to migrate, then click  to add them to Selected Objects. If you select tables or columns, DTS does not migrate views, triggers, or stored procedures unless explicitly selected. |
| Selected Objects | Manage the objects staged for migration:<br>• Rename a single object: right-click it. See Map the name of a single object.<br>• Rename multiple objects: click Batch Edit in the upper-right corner. See Map multiple object names at a time.<br>• Filter rows with SQL conditions: right-click a table and specify WHERE conditions. See Set filter conditions.<br>• Select which DML or DDL operations to migrate: right-click an object and select the operations. |
Configure advanced settings
Click Next: Advanced Settings. The default values work for most scenarios. Adjust the following parameters as needed.
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | By default, DTS uses the shared cluster. For higher task stability, purchase a dedicated cluster. See What is a DTS dedicated cluster. |
| Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database. | Applies when you use DMS or gh-ost for online DDL operations on the source. Important pt-online-schema-change is not supported — using it causes the DTS task to fail.<br>• Yes — migrates temporary table data from online DDL operations. May introduce latency.<br>• No, Adapt to DMS Online DDL — migrates only the original DDL from DMS, not temporary table data. Destination tables may be locked.<br>• No, Adapt to gh-ost — migrates only the original DDL from gh-ost, not temporary table data. Supports filtering gh-ost shadow tables. Destination tables may be locked. |
| Whether to Migrate Accounts | Whether to migrate source database account information. If set to Yes, select the accounts to migrate and verify the permissions of the accounts used in this task. See Migrate database accounts. |
| Retry Time for Failed Connections | How long DTS retries if it loses connectivity to the source or destination database. Valid range: 10–1,440 minutes. Default: 720. We recommend that you set the parameter to a value greater than 30 minutes. If DTS reconnects within this window, the task resumes; otherwise, it fails. Note If multiple tasks share the same source or destination database, the most recently set retry window takes effect. DTS charges accrue during retries. |
| Retry Time for Other Issues | How long DTS retries failed DDL or DML operations. Valid range: 1–1,440 minutes. Default: 10. We recommend that you set the parameter to a value greater than 10 minutes. This value must be less than Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Whether to limit the migration speed during full data migration. During full data migration, DTS uses the read and write resources of the source and destination databases. You can enable throttling based on your business requirements. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s). This reduces the loads of the destination database server. Available only when Full Data Migration is selected. |
| Enable Throttling for Incremental Data Migration | Whether to limit the migration speed during incremental data migration. Configure RPS of Incremental Data Migration and Data migration speed for incremental migration (MB/s). Available only when Incremental Data Migration is selected. |
| Environment Tag | A tag to identify the DTS instance environment. Select based on your environment (for example, production or staging). |
| Configure ETL | Whether to enable extract, transform, and load (ETL) processing on the migrated data. Select Yes to enter data processing statements in the code editor. See Configure ETL in a data migration or data synchronization task. |
| Whether to delete SQL operations on heartbeat tables of forward and reverse tasks | Whether DTS writes SQL operations to heartbeat tables while the instance runs.<br>• Yes — does not write heartbeat SQL. Latency may appear inflated in monitoring.<br>• No — writes heartbeat SQL. Physical backup and cloning of the source database may be affected. |
| Monitoring and Alerting | Whether to configure alerts for task failures or latency exceeding a threshold. Select Yes to set thresholds and notification contacts. See Configure monitoring and alerting when you create a DTS task. |
Configure data verification
Click Next Step: Data Verification to optionally set up a data verification task. See Configure a data verification task.
Step 6: Run the precheck
Click Next: Save Task Settings and Precheck at the bottom of the page.
To view the OpenAPI parameters for this task configuration before saving, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.
DTS runs a precheck before starting the migration. The task can only start after the precheck passes.
Failed items: Click View Details next to the failed item, diagnose the issue, fix it, then click Precheck Again.
Alert items that cannot be ignored: Click View Details, fix the issue, then click Precheck Again.
Alert items that can be ignored: Click Confirm Alert Details > Ignore > OK, then click Precheck Again. Ignoring alerts may result in data inconsistency.
Step 7: Purchase a migration instance
Wait until Success Rate reaches 100%, then click Next: Purchase Instance.
On the Purchase Instance page, configure the instance.
| Parameter | Description |
|---|---|
| Resource Group | The resource group for the migration instance. Default: default resource group. See What is Resource Management? |
| Instance Class | The instance class determines the migration speed. Select based on your data volume and time requirements. See Instance classes of data migration instances. |
Select the Data Transmission Service (Pay-as-you-go) Service Terms check box, then click Buy and Start. Click OK in the confirmation dialog.
The task starts running. Track progress on the Data Migration page.
What's next
Overview of data migration scenarios — explore other supported source and destination database combinations.
Configure a data verification task — verify data consistency after migration completes.
Map object names — rename databases, tables, or columns at the destination.