Oracle's Cloud Migration Playbook: Cut Egress Fees, Unify Data, and Run AI in the Database

When AI Success Comes Down to One Word

Every company these days is talking about large language models, agents, and AI-ready databases. Oracle prefers to talk about results. "Real AI capability is invisible," says William Wu, Vice President and Managing Director for Oracle China. "What you see is the business outcome."

That blunt framing shapes Oracle's entire approach. Instead of pushing abstract AI concepts, the company wants to pick one high-value scenario, get it into production fast, and prove it either boosts revenue or cuts costs. Only then does Oracle talk about scaling that success across the enterprise.

For cloud migration teams, this is a useful reminder: moving to the cloud isn't the goal. The goal is to make something measurable happen—faster, cheaper, or both.

Cloud Migration as a Data Story

Oracle's AI strategy rests on three pillars: enterprise-grade, cloud-native, and data-driven. But the real insight for cloud migration is about data. Companies operating in both China and overseas often use different models and cloud providers in different regions. Yet the data underneath remains the same core asset. That means the migration challenge isn't just moving workloads—it's keeping data consistent across multiple clouds while letting each region choose its own AI models, tools, and compute.

In the past, companies built separate systems for ERP, MES, CRM, and WMS. That worked fine when humans were the only ones reading data. Now AI reads data too. An agent trying to understand a business needs to see relationships across those systems—how a product defect traces back to a specific process, machine, or raw material. That requires a business semantic layer, not just a bunch of connected databases.

Oracle's answer is to use graph data types inside its multimodel database. This lets agents follow business relationships dynamically instead of hardcoding every possible path into application logic. For migration planners, that means data modeling needs to happen before the move, not after.

AIBS: A Method for Making Migration Pay Off

Oracle China developed a methodology called AIBS, which stands for AI Business Success. It's not a product—it's a delivery framework. The bottom layer is Oracle AI Database 26ai, which serves as a unified data foundation. Above that sit reference architectures, multimodel data, governance, a business semantic layer, agent orchestration, and finally the tools and ecosystem that connect into real workflows.

AIBS projects have strict entry criteria:

• They must go into production—no pilots or proof-of-concepts.
• They must show measurable business value, either increased revenue or reduced cost.
• They should be repeatable, so the first scenario can be copied to other parts of the business.

Oracle admits that most AI projects globally haven't delivered real returns yet. So instead of selling a vision, Oracle picks a high-value scenario, proves it works—and doesn't charge for that initial validation. Then they talk about scaling. It's a pragmatic approach that answers the two questions every CFO asks: Do you have a success story? And what will it actually do for us?

Putting AI Inside the Database—Not Beside It

Oracle's bet is that hybrid AI—mixing public models with private or on-prem models—is inevitable. That creates a new problem: how do you support that mix without moving data around? Oracle's answer is to make the database itself an AI development and runtime platform.

Oracle AI Database 26ai already supports multimodel data and vector search. Now it goes further. Private Agent Factory lets you build agents with no code. Select AI Agent lets you construct agents directly in SQL, calling external models and tools while keeping your data in place. There's also Agent Memory for short-term and long-term context, and full support for document upload, chunking, embedding, and retrieval-augmented generation—all inside the database.

Oracle also supports the Model Context Protocol (MCP), so you can talk to the database in natural language. And because model inference can put heavy load on database servers, a Private Services Container can offload AI workloads to dedicated nodes running private models.

Security Moves Down into the Data Layer

With agents generating SQL and code dynamically, the database's attack surface grows. Application-layer controls are no longer enough. Oracle's security strategy has three parts:

• Source security: Deep Data Security ties end-user identities to fine-grained database controls, with an in-database firewall that inspects SQL patterns.
• Speed: Security patches now come monthly instead of quarterly, and Oracle pushes customers on older versions to upgrade to 19c or 26ai.
• Resilience: For ransomware attacks, zero data loss recovery gets you back online faster.

For migration teams, this means security planning can't be an afterthought. If you're moving to a cloud database, you need to think about how agents and AI tools will access it—and how you'll control that access at the database level.

Multicloud Becomes a Connection Hub, Not a Collection of Tunnels

Oracle's OCI is repositioning itself as a multicloud hub. It started with Azure interconnection in June 2019, added Google Cloud in June 2024, and now has AWS connectivity generally available. The idea is simple: no single cloud does everything, so you should be able to combine the best of each.

This solves three practical problems. First, you don't have to negotiate with separate cloud providers, telecom carriers, and dedicated line vendors—you just turn on the interconnection. Second, when something breaks, you get a single support interface. Third—and this is the big one—Oracle is eliminating egress fees for traffic between OCI and AWS or Google Cloud. The Azure connection still has some one-way outbound charges, but for the others, you pay only port fees, not per-byte.

Egress fees are often the hidden cost that locks you into a cloud. For disaster recovery, cross-cloud analytics, or large data backhauls, those charges can blow up your budget. Oracle's move makes those scenarios feasible again.

What This Means for Your Migration Strategy

Oracle's target audience here is companies expanding overseas or operating globally. The typical architecture: applications run on AWS, Oracle Database sits on OCI, and the two clouds connect over low-latency links. Or you keep a local data center in Europe for regulatory reasons, run steady workloads there, and push dynamic workloads to the cloud.

But Oracle isn't saying the system will automatically choose the best path for you. Instead, they do a free pre-sales engagement where they analyze your existing stack, do a total cost of ownership assessment, and decide together which services stay put and which ones move. Every customer gets a custom design—there's no one-size-fits-all answer.

On the compute side, OCI's AI stack runs from GPU clusters and bare metal instances up to model services like OpenAI, Gemini, Grok, Llama, and Cohere. For Chinese companies going global that still want to use Chinese open-source models like Qwen or Zhipu, Oracle offers a Dedicated AI Cluster with A100, H100, H200, or B200 GPUs, so you can deploy and fine-tune those models in overseas regions while meeting local compliance.

Oracle also sees a future where most AI workloads are inference, and many small models (7B or smaller) don't need GPUs at all. Their Ax series, based on Acceleron networking, will handle AMD, Intel, and Arm CPUs with 100Gb or 200Gb NICs. Low-intensity tasks can run on CPU; heavy ones go to dedicated AI clusters. That keeps you from paying for GPU capacity you don't need.

Given the global squeeze on power and GPU supply, Oracle is taking a practical approach: lock in power and data center space in key regions, co-invest with customers to reduce supply chain risk, and use standardized modules so different accelerators can plug in quickly. They claim a GPU utilization rate of 97.5%.

Bottom Line

Oracle's cloud migration story is really about three things: cutting the cost of moving data between clouds, making the database a smarter place to run AI, and proving value before you scale. If you're planning a migration, don't just think about lifting and shifting. Ask yourself what business outcome you're chasing, how your data will stay consistent across clouds, and whether your security model can handle agents that write their own SQL. That's the migration playbook Oracle is betting on.