Single service comparison

Azure Server Migration is a workload module nested inside the Azure Migrate hub: one assessment tool discovers servers, then the same portal drives the replication and cutover. Huawei splits the lifecycle across two products—Server Migration Service (SMS) for OS/application replication and Migration Center (MgC) for portfolio discovery, assessment, and batch orchestration. SMS is agent-based (an AK/SK-authenticated agent per source) and has no native equivalent to Azure's agentless VMware/Hyper-V appliance replication; parity must be validated per vector (control plane, data plane, cutover) rather than assumed.

Replication data paths diverge. Azure streams blocks to a managed cache storage account and converges to managed disks using Azure Site Recovery infrastructure, supporting test failover clones and recovery points. SMS identifies disk-partition and file-system data, transmits concurrently over the public Internet, Direct Connect, or VPN, and uses EVS disks plus EVS snapshots for cutover and cloning; file-level Linux migration retransmits all files on restart, which can be costly for databases. Scaling is per-task, and HA/region failover behavior is not documented to parity with Azure's Recovery Vault model.

Cost and operational responsibility differ materially. Azure Server Migration tiers a documented free period followed by per-instance monthly charges, with target infrastructure billed separately. SMS itself is free; you pay only for the temporary 40-GB EVS disk, EVS snapshots, ECS target, and data-transfer/VPN/Direct Connect traffic consumed during migration. The Huawei operator therefore owns finer-grained infrastructure metering, while Azure's bundled SKU prices the tooling exposure separately from underlying resources.

Start with equivalent Huawei assessment: use MgC for discovery and feasibility assessment across the portfolio, then scope each host with SMS's migration feasibility check before committing. Confirm source OS is among SMS's supported Windows/Linux distributions, decide block-level versus file-level migration, and choose target ECS specs (SMS can auto-recommend). Pick the transport—public Internet, Direct Connect, or VPN—based on data volume and latency, and provision VPC, security groups, and AK/SK credentials.

Run SMS replication: install the SMS agent on each source, start full migration to the target ECS, then enable incremental synchronization to keep the target in sync while the source keeps running. Plan checkpoints and snapshot cadence so a defined rollback point exists before cutover. For database or large-file workloads where file-level retransmission on restart is risky or expensive, evaluate whether DRS/OMS/CDM fit the data plane better than pure SMS, and document which service owns which slice.

Validate target before cutover: confirm OS hardening, application startup order, dependency connectivity, and performance against the source baseline. Define explicit cutover and rollback criteria (,application-level health checks, data consistency checks), then schedule the final SMS incremental sync and cutover window. Do not treat SMS as a one-click equivalence of Azure Migrate: re-run feasibility analysis per host and verify region/quota availability for the temporary EVS, snapshots, and ECS.

Recalculate TCO using Huawei's fee structure, not Azure's free-period-plus-per-instance model. SMS is free, but budget for temporary 40-GB EVS per target, EVS snapshot storage, pay-per-use ECS during migration and post-cutover, egress/Ingress from the source provider, and Direct Connect or VPN if used. Account for potential retransmission costs on failed or restarted Linux file-level jobs, peak-load periods, retention windows, and cross-region traffic before production migration.