Migrations between clouds get pitched as either trivial ("it's all just Kubernetes") or impossible ("total rewrite required"). Neither is honest. The real experience is closer to: most of the application layer ports over cleanly, and the places it doesn't are predictable once you know where to look.
The service mapping that made planning possible
Before writing a line of migration code, map every AWS service in use to its Alibaba Cloud equivalent and mark the confidence level on each mapping:
| AWS service | Alibaba Cloud equivalent | Migration confidence |
|---|---|---|
| EC2 | ECS | High — near 1:1 |
| S3 | OSS | High — API-compatible SDK path exists |
| RDS (PostgreSQL/MySQL) | ApsaraDB RDS | High — same engines supported |
| EKS | ACK | High — standard Kubernetes underneath |
| Lambda | Function Compute | Medium — event source mapping differs |
| SQS | Message Service (MNS) | Medium — API shape differs enough to need an adapter |
| CloudFront | Alibaba Cloud CDN | Medium — edge behavior rules need rewriting |
| IAM | RAM | High — concepts map directly, syntax differs |
The "High confidence" row items — compute, storage, managed relational databases, Kubernetes — accounted for roughly 70% of the workload's total infrastructure footprint and ported with mechanical, low-risk changes. The "Medium confidence" items were where the actual migration time went.
What went smoother than expected
The Kubernetes layer was closest to a non-event. Application manifests, Helm charts, and the CI/CD deployment logic needed only StorageClass and LoadBalancer annotation changes (covered in my ACK vs. self-managed piece) — the actual application containers didn't change at all.
RDS-to-ApsaraDB was a snapshot-and-restore, not a re-architecture. Both support standard pg_dump/mysqldump workflows, and for a lower-downtime cutover, Alibaba Cloud's Data Transmission Service handled ongoing replication from the AWS-side database until the cutover window.
What turned out to need real rework
Lambda to Function Compute wasn't a drop-in. The trigger and event-source model differs enough — particularly around how event payloads are structured for object-storage triggers — that every function needed its handler signature adjusted, not just redeployed. Budget real engineering time here; this was the single largest line item in the migration.
CloudFront's edge rules needed a full rewrite, not a translation. Alibaba Cloud CDN's rule engine covers the same functional territory — cache behaviors, header manipulation, redirect rules — but the configuration syntax and the console's mental model are different enough that treating it as a port-and-adjust task underestimated the work by roughly 3x against the original estimate.
IAM policies took longer to re-author than expected, not because RAM is harder to use, but because the migration was a good forcing function to actually audit what the AWS policies had accumulated over several years. About a third of the permissions in the original IAM policies turned out to be unused entirely — worth doing this audit regardless of whether a migration is the reason.
The cutover strategy that avoided a big-bang risk
Rather than a single cutover weekend, the migration ran as:
- Stand up the full stack on Alibaba Cloud in parallel, with the database replicating continuously from AWS.
- Shift read traffic first, via weighted DNS, to validate the new stack under real load without risking write-path correctness.
- Shift write traffic in a single short maintenance window, once read-path metrics matched the AWS baseline for two full weeks.
- Keep the AWS stack warm for 30 days post-cutover as a rollback path, then decommission.
That 30-day overlap cost real money in duplicate infrastructure, but it was the single decision that made the whole migration feel low-risk to stakeholders — nobody has to trust a migration is correct on faith when there's a working rollback path sitting right there.
Would I do it again the same way
Yes, with one change: I'd start the RAM/IAM audit in week one instead of treating it as a migration task that happens alongside the infrastructure work. It's genuinely a separate project, and bundling it into the migration timeline made an already multi-variable project harder to estimate accurately.