How Cloud‑Native Architecture Is Redefining Migration and Disaster Recovery

Cloud‑Native Development Trend

Cloud native has become a major driver of business growth, reshaping application development and IT skill sets. The 2020 Cloud Native Development Whitepaper highlighted cloud computing’s inflection point, and Snowflake’s IPO demonstrated how cloud‑native data warehouses can disrupt entire industries. This raises the question of whether the next disruption will occur in traditional disaster‑recovery (DR) practices.

Why New Migration and DR Are Needed

Traditional solutions focus on data movement and storage control, ignoring cloud‑native characteristics and business‑level redesign. In the cloud era, resources are consumed like utilities, so migration and DR must align with this model. Traditional DR centers on storage, requiring deep control over physical infrastructure, which is no longer available when workloads run on managed cloud services.

Key concerns include data security, continuous business operation, and avoiding vendor lock‑in. Users must adopt cloud‑native APIs and orchestration to ensure continuity while optimizing total cost of ownership.

Relationship Between Cloud Migration and DR

Migration demand has evolved from physical‑to‑virtual moves to multi‑cloud portability. The classic 6R (now 7R) migration model identifies Rehost, Replatform, Repurchase and Refactor as the primary pathways. Lift‑&‑Shift (Rehost) offers the fastest cloud entry with minimal changes, while Evolve and Go‑Native require more effort but provide deeper cloud integration.

Rehost (Cold and Hot Migration)

Cold Migration examples include converting VMware VMDK files to QCOW2 or RAW using qemu-img, uploading to OpenStack Glance, and injecting virtio drivers. This process can take many hours (e.g., 24 hours for a single host) and requires downtime, making it unsuitable for production workloads.

Physical‑host cold migration can use CloneZilla for block‑level backup, but also demands live‑CD booting and results in prolonged service interruption.

Traditional Hot Migration relies on block‑level or file‑level incremental sync. Block‑level solutions achieve full‑machine moves, while file‑level tools like rsync are limited by OS compatibility and stability.

Traditional hot migration suffers from high manual effort, lack of multi‑tenant support, agent installation overhead, costly one‑to‑one sync, and cumbersome validation.

Cloud‑Native Hot Migration

CloudEndure (acquired by AWS) exemplifies cloud‑native hot migration, using block‑level delta sync with cloud APIs to provide automated, multi‑tenant, agent‑less migrations and cross‑region DR. However, its AWS‑only support limits applicability in China.

As an alternative, the domestically developed HyperMotion platform offers similar capabilities for VMware and OpenStack, supporting major public, private, and hybrid clouds in China.

Replatforming (Platform Re‑Build)

Replatforming leverages cloud‑native services such as RDS, object storage, message queues, and container services to reduce operational overhead. Migration tools like AWS DMS, Alibaba Cloud DTS, and Tencent Cloud DTS enable online database migration using binlog replication for MySQL, PostgreSQL, Redis, MongoDB, etc.

Object storage migration tools (e.g., Alibaba OSSImport, Tencent COS Migration) support incremental uploads, while large‑scale data transfers may use offline devices like AWS Snowball or Alibaba Lightning Cube.

Disaster‑Recovery Architectures

Traditional Architecture Example : A WordPress + MySQL stack deployed on physical servers with load balancers, web servers, shared file systems (GlusterFS), and database servers. DR strategies include load‑balancer failover, web‑server replication, file‑system mirroring, and database backup or continuous data protection (CDP).

Hybrid‑Cloud DR combines object storage and database replication with automated orchestration to achieve cost‑effective DR while maintaining high availability.

Same‑City Cloud DR utilizes cloud services such as DNS, VPC, load balancer, auto‑scaling, cloud hosts, object storage, and RDS. By deploying resources across availability zones and using image‑based scaling, a dual‑active architecture can be achieved with minimal modification.

Cross‑Region DR leverages backup capabilities (e.g., VM images, RDS snapshots) and trigger functions from monitoring alerts to automate failover across regions.

Cross‑Cloud DR faces challenges due to differing service APIs and cost considerations; data backup and configuration alignment are essential, and “cloud‑to‑cloud” migration often incurs higher expenses.

Conclusion

Cloud‑native DR is still in its early stages, with no single platform covering all scenarios. A successful cloud‑native DR solution must be data‑centric, automate orchestration, and exploit cloud‑native resource characteristics to lower total cost of ownership while ensuring business continuity.