Help Center/ Migration Center/ FAQs/ Risk Assessment/ How Do I Assess Database Migration Risks?
Updated on 2026-06-30 GMT+08:00

How Do I Assess Database Migration Risks?

Risk assessment is available for MySQL, PostgreSQL, MongoDB, and SQL Server databases. This section describes the check items and their required information for database migration risk assessment.

MySQL

The table below lists the check items, required information, and purposes for MySQL migration risk assessment.

Figure 1 MySQL migration risk assessment

Table 1 Check items for MySQL migration risk assessment

Check Item

Required Field

Check Purpose

Source database version

Source database version

Query the source database version and compare it with the versions supported by DRS.

Source database form

Whether the source database is in a primary/standby setup

Incremental migration cannot be performed if the source database is a standby database.

Binlog retention period

Binlog retention period

Short Binlog retention periods may cause migration failures. A minimum retention period of 3 days is recommended.

Binlog format

Binlog format

For incremental migration, Binlog must be enabled on the source database and the Binlog format must be set to ROW.

Maximum packet size allowed by the source database

Maximum packet size allowed by the source database

If there is a large amount of data or there are too many fields to be migrated, and the maximum packet size allowed by the source database is smaller than 16,777,216 bytes, the migration task may fail.

Tables without primary keys

Service tables without primary keys

Tables without primary keys lack unique row identifiers, making data comparison impossible. This may also cause data inconsistency between the source and target databases in case of network instability. You are advised to add primary keys to the tables before the migration.

Data types

Data types

Check whether the source database contains data types that are not supported for DRS data comparison, such as TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT.

Primary key data types

Primary key data types

Check whether the source database contains primary key data types that are not supported for DRS data comparison, such as TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT, FLOAT, TIMESTAMP, DATE, DATETIME, BINARY and VARBINARY.

Large tables

Table size

Check whether any single table contains more than 100 GB of data or its total row count exceeds 10 million.

Tables with LOB data types

Tables containing longtext/mediumtext or longblob/mediumblob fields

OOM may occur during migration of tables containing LOB data types.

PostgreSQL

The table below lists the check items, required information, and purposes for PostgreSQL migration risk assessment.

Figure 2 PostgreSQL migration risk assessment

Table 2 Check items for PostgreSQL migration risk assessment

Check Item

Required Field

Check Purpose

Source database version

Source database version

Query the source database version and compare it with the versions supported by DRS.

Source database form

Whether the source database is in a primary/standby setup

Incremental migration cannot be performed if the source database is a standby database.

Maximum number of replication slots that can be created

Maximum number of replication slots that can be created

The maximum number of replication slots that can be created in the source database must be greater than the number of used replication slots. Otherwise, the synchronization may fail.

Maximum number of WAL sender processes that can run simultaneously

Maximum number of WAL sender processes that can run simultaneously

The maximum number of concurrent WAL sender processes in the source database must be greater than the number of used replication slots. Otherwise, the synchronization may fail.

wal_level setting

WAL level

The WAL level in the source database must be set to logical. If the WAL level is not set to logical, incremental logs of the source database cannot be logically decoded, making incremental synchronization impossible.

Tables without primary keys

Service tables without primary keys

Tables without primary keys lack unique row identifiers, making data comparison impossible. This may also cause data inconsistency between the source and target databases in case of network instability. You are advised to add primary keys to the tables before the migration.

Unlogged tables

Unlogged tables

DRS cannot synchronize DML operations for unlogged tables.

Primary key data types

Primary key data types

Check whether the source database contains primary key data types that are not supported for DRS data comparison, such as REAL, DOUBLE PRECISION, MONEY, TEXT, BYTEA, TIMESTAMP WITHOUT TIME ZONE, TIMESTAMP WITH TIME ZONE, DATE, TIME WITHOUT TIME ZONE, TIME WITH TIME ZONE, INTERVAL, BOOLEAN, ENUMERATED TYPES, POINT, LINE, LSEG, BOX, PATH, POLYGON, CIRCLE, CIDR, INET, MACADDR, MACADDR8, BIT, BIT VARYING, TSVECTOR, TSQUERY, XML, JSON, ARRAY, COMPOSITE TYPES, INT4RANGE, INT8RANGE, NUMRANGE, TSRANGE, TSTZRANGE, and DATERANGE.

Large tables

Table size

Check whether any single table contains more than 100 GB of data or its total row count exceeds 10 million.

Tables with LOB data types

Tables containing longtext/mediumtext or longblob/mediumblob fields

OOM may occur during migration of tables containing LOB data types.

SQL Server

The table below lists the check items, required information, and purposes for SQL Server migration risk assessment.

Figure 3 SQL Server migration risk assessment

Table 3 Check items for SQL Server migration risk assessment

Check Item

Required Field

Check Purpose

Source database version

Source database version

Query the source database version and compare it with the versions supported by DRS.

CDC status

Whether Change Data Capture (CDC) is enabled on the source database

Incremental synchronization from SQL Server is implemented based on CDC provided by SQL Server. If CDC of the source SQL Server database is abnormal (for example, CDC is disabled or the transaction log is full), incremental synchronization will be affected.

CDC data retention period

CDC data retention period on the source database

If the CDC data retention period of the source database is less than one day, the incremental synchronization will be abnormal. Change the retention period to 1,440 minutes (one day) or longer. The recommended value is 4,320 minutes (three days).

Tables without primary keys

Service tables without primary keys

Tables without primary keys lack unique row identifiers, making data comparison impossible. This may also cause data inconsistency between the source and target databases in case of network instability. You are advised to add primary keys to the tables before the migration.

Data types

Data types

Check whether the source database contains data types that are not supported for DRS data comparison, such as TEXT, NTEXT, IMAGE, BINARY, VARBINARY, HIERARCHYID, XML, and TIMESTAMP.

Primary key data types

Primary key data types

Check whether the source database contains primary key data types that are not supported for DRS data comparison, such as FLOAT, REAL, DATE, DATETIME, DATETIME2, DATETIMEOFFSET, TIME, TIMESTAMP, TEXT, NTEXT, IMAGE, BINARY, VARBINARY, HIERARCHYID, XML, and BIT.

Large tables

Table size

Check whether any single table contains more than 100 GB of data or its total row count exceeds 10 million.

Tables with LOB data types

Tables containing longtext/mediumtext or longblob/mediumblob fields

OOM may occur during migration of tables containing LOB data types.

MongoDB

The table below lists the check items, required information, and purposes for MongoDB migration risk assessment.

Figure 4 MongoDB migration risk assessment

Table 4 Check items for MongoDB migration risk assessment

Check Item

Required Field

Check Purpose

Source database version

Source database version

Query the source database version and compare it with the versions supported by DRS.

Collection balancer status (only for sharded clusters)

Whether the collection balancer is enabled

If the migration task involves incremental migration from a source sharded cluster, the balancer on the source cluster must be disabled.

Oplog status (only for replica sets)

Whether Oplog is enabled

During incremental migration, the Oplog on the source database must be enabled.

Collection index count check

Collection index count

During MongoDB migration, the number of indexes affects the overall migration time. DRS checks whether the source database contains collections with more than 10 indexes. If such collections exist, the migration speed will be affected. You need to confirm whether migrating all indexes is necessary.

Collection _id index check

List of collections without _id indexes

If the source database contains collections without _id indexes, the migration may fail.

Collection TTL index check

Collections with TTL indexes

TTL indexes may cause data inconsistency after migration due to time zone and clock differences between the source and target databases.

Collection name check

Collections with invalid characters in their names

Traverse the collections in the source database and check whether their names comply with the naming rules. Collection or view names cannot contain the following characters: '<>