Migrating a workload from AWS to Oracle Cloud: the mapping and the parts that do not map
Most services have a counterpart and the translation is mechanical. Three things are not mechanical, and they decide whether the migration is worth doing at all.
The question is rarely "should we move everything". It is "this workload is expensive on AWS for a reason we understand — does moving it make sense". That is a good question, and it has a structured answer.
The mechanical mapping
For the majority of a standard workload, there is a counterpart:
| AWS | OCI |
|---|---|
| EC2 | Compute (flexible shapes) |
| VPC, subnets, security groups | VCN, subnets, NSGs |
| Transit Gateway | Dynamic Routing Gateway |
| S3 | Object Storage |
| EBS | Block Volume |
| EFS | File Storage |
| RDS PostgreSQL / MySQL | Database with PostgreSQL / MySQL HeatWave |
| EKS | OKE |
| Lambda | Functions |
| CloudWatch | Monitoring and Logging |
| IAM roles, instance profiles | Policies, dynamic groups, instance principals |
| KMS, Secrets Manager | Vault |
| Route 53 | DNS |
| CloudFront | a CDN partner, which is a genuine gap |
For containerised, stateless workloads this mapping is close to complete and the migration is largely a pipeline and networking exercise. Build for the right architecture, push to OCI Registry, deploy to OKE, point DNS.
The three things that do not map
Identity is a different model. AWS is JSON policies attached to principals; OCI is policy statements written against compartments and groups. There is no automated translation and you should not attempt one — rewrite the policies from intent, using the smallest verb that works and dynamic groups for workloads. The OCI policy piece covers the traps. Budget real time for this; it is the part teams underestimate most.
The managed service catalogue is smaller. If your workload leans on a specific AWS managed service — Step Functions, Kinesis, DynamoDB with a particular access pattern, a niche analytics service — check the counterpart carefully before committing. Sometimes there is one, sometimes there is a self-managed equivalent you now operate, and sometimes the honest answer is that this workload stays.
Regions and availability domains. Fewer regions, and several regions have a single availability domain where AWS would give you three availability zones. Fault domains within one AD protect against hardware and maintenance failures, not against an AD-level event. If your availability target assumes three independent zones, verify the target region before designing.
The order that works
- Pick a workload with a reason. High egress, ARM-friendly compute, or an Oracle licensing position — the cases where the OCI cost model genuinely differs. A workload with no specific reason to move should not move.
- Build the landing zone first. Compartments, policies, tag namespaces, VCN, logging, Cloud Guard. Two weeks, and the migration lands on something rather than beside it.
- Establish connectivity early. Site-to-site VPN over the DRG is fast; FastConnect has a lead time of weeks. If the migration needs dedicated bandwidth, order it before anything else.
- Move the data first, and keep it in sync. Object Storage has an S3-compatible API and supports bulk transfer; databases use their native replication or a migration service with ongoing replication. Get to a steady state where the target is continuously current.
- Run both in parallel with traffic split. A percentage of production traffic to the OCI stack, watched for a week. This is where you find the latency surprise, the missing NSG rule and the query that regressed.
- Cut over by DNS, keep the source for a fortnight. The rollback plan is repointing, and it only exists while the source is alive.
- Decommission deliberately, including the FastConnect circuit and the peering you set up for the migration, which otherwise bill forever.
What to measure before and after
Latency at p99 from real client locations, cost per unit of work (not per instance hour), egress GB, and error rate. Publish the before numbers before you start, so the after numbers mean something. A migration that improves the bill and quietly degrades p99 is not a success, and without the baseline nobody can tell.
The honest summary
Targeted migrations work. Wholesale ones usually do not pay for themselves unless there is a licensing or contractual reason driving it. The pattern we most often recommend is a split estate: the egress-heavy or Oracle-licensed workload on OCI, the rest where it is, with a clear network path between them.
That is a legitimate architecture, not a failure to commit, and it is why our cloud work spans all four providers — and why Skyline draws the current estate across them before anyone argues about where things should live.
What to do this week
Pick the single workload you most suspect would be cheaper on OCI, and write down why in one sentence. If the sentence is about egress, ARM compute or an Oracle licence, model it properly. If you cannot write the sentence, the workload is not a migration candidate.