On June 1, 2026, Publickey reported that Oracle Database@AWS is now available in the Osaka region. Oracle Database@AWS is a service that brings Oracle Cloud infrastructure inside AWS data centers to deliver Oracle Database on AWS. Previously restricted to the Tokyo region, the addition of the Osaka region enables a two-region domestic architecture, making it much easier to satisfy requirements specific to Japan such as DR (disaster recovery), data sovereignty, and low latency.
For mid-market enterprises managing Oracle Database on-premises or on dedicated hardware, this marks a major decision-making turning point. From our perspective supporting core systems and data platforms through custom development, we view this not as a matter of "whether to abandon Oracle," but as a migration phase to determine "which architecture and risk tolerance level to align Oracle assets with." Building on the DB modernization covered in Custom AWS Aurora Serverless v4 DB modernization (GH Media), the version upgrades in Custom MySQL 9.7 LTS modernization (GH Media), and the DR architecture in Custom AlloyDB hot standby DR design (GH Media), this article outlines how to execute "Oracle DB cloud migrations" from the practical perspective of client project delivery.
Why migrate Oracle DB to the cloud "right now"?
| Dimension | On-premises Oracle (traditional) | Oracle Database@AWS（2026） |
|---|---|---|
| Installation location | In-house DC / colocation | Oracle infrastructure inside AWS DCs |
| Domestic regions | In-house facilities | Tokyo + Osaka |
| DR | Building a remote DC in-house | Inter-region Data Guard |
| AWS service integration | Connected via VPN / dedicated leased lines | Low-latency integration within the same VPC |
| License | In-house ownership / maintenance contract | BYOL / subscription options |
| Scaling | Requires hardware procurement | Elastic resizing |
| Operational responsibility | Entirely in-house | Infrastructure managed by AWS / Oracle |
In other words, this addition means that between "abandoning Oracle entirely to migrate to open source" and "lifting and shifting to the cloud while keeping Oracle as-is," a pragmatic middle ground—"leveraging Oracle while gaining AWS disaster recovery and service integrations"—has now become viable across two domestic regions.
3 evaluation criteria for client projects
Criterion 1: "Full replacement" vs. "lift and shift"
For core systems with heavy dependencies on Oracle-specific features such as PL/SQL, partitioning, and RAC, a full migration to PostgreSQL often entails high costs and risks. In our custom development engagements, we perform dependency scoring and provide a hybrid architecture where deeply dependent areas are lifted to Oracle Database@AWS, while loosely coupled surrounding components are shifted to Aurora/PostgreSQL. This serves as the Oracle adaptation of the framework presented in Custom AWS Aurora Serverless v4 DB modernization (GH Media).
Criterion 2: From "in-house DR" to "inter-region DR"
DR setups that previously required building an in-house remote data center can now be redesigned using Tokyo–Osaka inter-region Data Guard and backups. In our engagements, we design DR architectures backed out from RPO / RTO targets along with failover drills. This is the Oracle counterpart to our work in Custom AlloyDB hot standby DR design (GH Media).
Criterion 3: From "isolated DB migration" to "redesign built around AWS integration"
Because it can integrate with S3, Lambda, Redshift, and SageMaker with low latency within the same VPC, the database can serve as the hub of your AWS data platform. In our custom development work, incorporating insights on distributed databases from Custom Google Spanner on-premise distributed RDB migration (GH Media), we also handle post-migration data utilization design.
The 5 phases of delivering "Oracle DB cloud migration"
Phase 1: Current state assessment (2–3 weeks)
- Oracle asset inventory (versions / options / RAC / character sets)
- Dependency scoring for Oracle-specific features
- License inventory (owned / maintenance / core counts)
- Clarification of RPO / RTO / audit requirements
- Risk + TCO matrix
Phase 2: Design (2–3 weeks)
- Migration strategy selection (lift / Aurora migration / hybrid)
- Licensing strategy (BYOL / subscription)
- Tokyo + Osaka DR architecture design
- AWS service integration design (S3 / Lambda / analytics platform)
- Network / encryption / audit log design
Phase 3: Implementation (4–6 weeks)
- Oracle Database@AWS environment provisioning
- Network provisioning (same VPC / dedicated connections)
- Data Guard / backup configuration
- Reproducibility via IaC (Terraform)
- Monitoring / audit logging (CloudWatch / audit trails)
Phase 4: Data migration and cutover (3–5 weeks)
- Migration rehearsal (full load + differential synchronization)
- Performance verification (production-grade load testing)
- Cutover plan + rollback procedures
- Switchover drills + DR failover drills
Phase 5: Operational review (ongoing)
- Performance / cost optimization (instance sizing)
- Periodic DR drills (semiannual)
- Patch / version management
- License compliance audits
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| DB (lift) | Oracle Database@AWS | Oracle on EC2 |
| DB (migration destination) | Aurora PostgreSQL | RDS for PostgreSQL |
| Migration tools | AWS DMS / SCT | GoldenGate |
| DR | Data Guard / cross-region backups | Manual replication |
| IaC | Terraform | CloudFormation |
| Monitoring | CloudWatch + OEM | Datadog |
| Data integration | S3 / Glue / Redshift | DataSync |
| Encryption | KMS / TDE | In-house key management |
Which projects need this and which do not
| Projects requiring this | Projects not requiring this |
|---|---|
| Approaching maintenance renewal for on-premises Oracle | Already running stably on cloud databases |
| Domestic DR / data sovereignty is mandatory | Lenient DR requirements |
| Deep dependencies on PL/SQL / RAC | Shallow dependencies; ready to migrate immediately to PostgreSQL |
| Desire to integrate with an AWS data platform | Self-contained single database |
| Hardware procurement lead times are a bottleneck | Elasticity is unnecessary |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Migration scope | Target DBs / schemas / integration endpoints | Phase transition boundaries |
| Licensing responsibility | BYOL eligibility verification | Compliance ownership |
| Data migration guarantees | Scope of integrity verification | Demarcation of liability for data loss |
| DR requirements | RPO / RTO achievement criteria | Drill frequency |
| Handover Upon Project Completion | IaC / runbooks / training | Internal operational continuity |
| Cost caps | Instance / data transfer costs | Handling of unexpected charges |
Estimated client ROI (assuming 8 on-premises Oracle instances / custom in-house DR)
| Item | Existing (on-premises + in-house DR) | After Oracle Database@AWS migration | Difference |
|---|---|---|---|
| Hardware / DC costs (annual) | 24 million yen | 15 million yen | -9 million yen |
| DR construction and maintenance (annual) | ¥12,000,000 | 4 million yen | -8 million JPY |
| Hardware procurement lead time | 12 weeks | 1 week | -11 weeks |
| DB operational effort (monthly) | 320 hours | 180 hours | -140 hours |
| Annual benefit | — | — | Equivalent to approx. 28 million yen + faster procurement |
Although migration itself incurs implementation and operational costs, there are numerous cases where avoiding in-house DR builds and hardware renewals alone provides a clear path to recouping the investment. The practical first step is to model your TCO based on your existing asset portfolio.
Five common pitfalls
Pitfall 1: Postponing license compliance verification
Miscalculating BYOL core counts and options (RAC / partitioning) creates the risk of retroactive penalty charges. Complete a license inventory prior to migration.
Pitfall 2: Overlooking character sets and sort orders
In Japanese environments, discrepancies in character encoding and collation orders cause data corruption. Validate them during migration rehearsals.
Pitfall 3: Treating "backups alone" as DR
Backups do not equal DR. Include failover drills that validate RTO targets in the engagement agreement.
Pitfall 4: Failing to perform production-grade performance verification
Testing solely in development environments leads to breakdowns under peak production loads. Mandate production-grade load testing.
Pitfall 5: Rushing into an immediate full PostgreSQL migration
Forcing a core system with deep dependencies to migrate will cause projects to stall. Adopt a phased hybrid approach instead.
90-day action plan
| Week | Action |
|---|---|
| Week 1〜3 | Asset inventory + dependency scoring + TCO calculation |
| Week 4〜6 | Migration strategy + DR + integration design |
| Week 7〜12 | Environment build + IaC + Data Guard |
| Week 13 | Migration rehearsal + performance verification + DR drills |
| Week 13 | Cutover plan sign-off + preparation for operational reviews |
Summary — DB strategies evolve from "discarding vs. keeping Oracle" to "aligning with risk tolerance"
The launch of Oracle Database@AWS in Osaka established a practical path to leverage existing Oracle assets while satisfying domestic DR and data sovereignty. Sorting workloads into lift vs. migration using dependency scoring, designing Tokyo–Osaka DR, and connecting with the AWS data platform—this is the baseline for Oracle DB cloud migrations in 2026.
The roadmap and scale of Oracle DB cloud migrations vary widely depending on asset portfolio, licensing, and DR requirements. If you are facing challenges like "upcoming renewal for on-premises Oracle," "wanting to redesign domestic DR in the cloud," or "wanting to integrate with AWS while preserving Oracle assets," we provide customized estimates after understanding your requirements. Feel free to contact us via our contact form.
Sources
- Oracle Database@AWS launches in the Osaka region (Publickey 2026-06-01)
- Custom AWS Aurora Serverless v4 DB modernization (GH Media)
- Custom MySQL 9.7 LTS modernization (GH Media)
- Custom AlloyDB hot standby DR design (GH Media)
- Custom Google Spanner on-premise distributed RDB migration (GH Media)
- AWS Interconnect Multi-Cloud Custom Development (GH Media)
