Single service comparison

Operating model and lifecycle differ materially. Azure DMS was a purpose-built, Azure-resident migration orchestrator with two tiers—classic (offline, free) and premium (online CDC, hourly billed)—that Microsoft has now retired, directing users to in-product native tools. Huawei DRS remains an active, generally available service exposing three task modes—migration, synchronization, and disaster recovery—each with distinct control planes, object-selection semantics, and lifecycle operations, so the two services are not drop-in equivalents: one is being decommissioned, the other is a current long-term data-flow platform.

Engine matrix and data-plane behavior diverge. Azure DMS targeted a fixed set of Azure destinations (SQL DB, SQL MI, Azure Database for PostgreSQL/MySQL) using SQL Server Integration Services-style task metadata and known limitations per connector. Huawei DRS covers 20-plus relational and non-relational sources, includes homogeneous and heterogeneous flows to RDS, GaussDB, and DDS, supports bidirectional synchronization, workload replay, and DDL during migration. API surfaces, parameterization, pre-migration checks, and reconciliation differ, so engine/version and feature compatibility must be validated task-by-task rather than assumed.

Scaling, HA, and operational responsibility are positioned differently. Azure DMS abstracted the migration runtime behind a managed instance you sized and the platform maintained, with Azure Support owning platform reliability. Huawei DRS provides flow control, resumable transfer, latency monitoring, online data comparison, and built-in rollback, but task sizing, network path (Direct Connect/VPN), and target database HA topology remain shared responsibilities with RDS/GaussDB. Pricing models also differ—Azure billed the premium runtime hourly, while Huawei bills per DRS task mode and resource plus underlying network/storage—so TCO must be recomputed, not reused.

Assess source engine and version against the DRS supported-database matrix and pick the right Huawei target per workload: RDS for MySQL/PostgreSQL for managed self-service, GaussDB for distributed or heterogeneous OLTP, DDS for document workloads. Because Azure DMS is retired, treat DRS, not DMS, as the migration backbone and run DRS pre-checks (object, network, account, version) before committing to a task type—migration for cut-over, synchronization for continuous, DR for standby.

Establish network and security plumbing before provisioning tasks. Route source-to-Huawei traffic over VPN, Direct Connect, or VPC peering, open the required DRS security groups and database accounts, and decide forward vs reverse flows. For Azure-resident sources, account for Azure-to-Huawei egress and inter-region latency; DRS tasks run region-by-region, and cross-cloud transfer cost and bandwidth change the schedule for large initial full loads. Validate TLS, allow-listing, and CDC log retention windows for incremental capture.

Execute full-load plus incremental migration or synchronization, then validate and cut over. Use DRS network and pre-migration checks, the trial-migration feature, online data comparison, and real-time latency monitoring to confirm consistency. Build down-stream application acceptance tests and a rollback plan; where a heterogeneous rewrite is involved (e.g., SQL Server to GaussDB), pair DRS with UGO for schema assessment and conversion, and with workload replay to stress the target before cutover. Do not assume Azure DMS premium-parity; confirm each behavioral requirement on DRS.

Recompute total cost of ownership using Huawei billing units, not Azure units. DRS is billed per task mode and resource plus related RDS/GaussDB compute, storage, backup, and cross-region/interconnect traffic; Azure DMS premium was hourly runtime-independent of target cost. Model peak load, request volume, full-load duration, retention, and cross-cloud egress, and budget separately for UGO assessment and any target-time tooling. Confirm regional DRS availability and quotas for your target region during planning, since these vary by site.