Announcements at Oracle AI World sharpen focus on customer migration paths…

​​Premise

Success in AI mandates having a data estate that is coherent, governed and widely accessible to secure agents. At Oracle AI World 2025, the company made several news announcements that strengthen its data and AI platform story. Oracle put forth a vision of Agentic AI, leveraging any cloud platform, including its own OCI and on-premises Cloud@Customer, ironically touting the strongest multicloud story in the industry. In typical Oracle fashion, the company is targeting the most demanding workloads in enterprise AI, capitalizing on its mission-critical database heritage but accommodating an increasing number of data types and formats across all workloads. 

On balance, we believe that customer success in AI will require the delivery of harmonized, high-quality, governed, and secure data, which Oracle is emphasizing and providing pathways to a so-called “single version of the truth–” an industry promise that has remained elusive over the years. Oracle is also strongly emphasizing real-time, low-latency access to data, which is essential to maintain coherency.

Our north star vision for Oracle customers is a single version of the truth that spans multiple clouds and on-prem systems in a unified hybrid mesh that injects intelligence and autonomous operation throughout. While some of this capability exists today, customers will need to plan a path to this goal. 

In this analysis, we update our migration scenarios for Oracle customers and put forth several options we feel organizations should consider as they build their AI strategies. In addition, we will add our commentary on some of the key announcements from Oracle’s recent AI World event in Las Vegas. 

In the exercise, we use our migration and business value framework, applying the concepts to two hypothetical scenarios as described below. In future work, we plan to specifically quantify the costs, risks, and business value for each step in the roadmap to allow customers to compare and contrast business cases. 

In Search of Enterprise AI ROI

Recent industry conversions, most notably around an MIT AI study, have called into question the efficacy of AI investments. The takeaway of the study is that despite $30–40B in GenAI spend and widespread trials of tools like ChatGPT and Copilot, the findings suggest a stark “GenAI Divide,” where only ~5% of integrated pilots generate meaningful P&L impact while ~95% deliver zero return. Importantly, this poor showing is not due to models or regulation, but to brittle workflows, weak contextual learning, and poor fit with day-to-day operations.

Recent data from our partner ETR confirms similar trends from a much larger sample, with somewhat better but still tepid results as shown below.

Our interpretation of these findings is that most organizations struggle with data silos and lack a coherent, unified data model that harmonizes information across departments and processes. This data challenge causes great difficulty when implementing cross-functional automation or Agentic AI projects. We believe recent Oracle announcements demonstrate a clear understanding of this problem, and the company is putting forth the beginnings of a roadmap to address the challenge. 

A new, AI native organization can start with a clean sheet of paper and develop processes that unify data from the start. The vast majority of established enterprises, however, suffer from data fragmentation and stale data, two of the most significant barriers to enterprise AI adoption.

Two Notable Announcements at AI World 

While Oracle put forth a firehose of news at its recent event, two announcements stood out and are relevant to our migration scenarios, specifically: 

Oracle AI Database 26ai

In our view, 26ai represents an architectural convergence that brings vectors, LLM integration, and traditional workloads into a single control plane. Oracle has maintained its converged engine, spanning relational, JSON, XML, spatial, and graph, while adding unified vector search that runs in-database. This architecture eliminates the operational overhead of stand-alone vector databases. The automatic path from 23ai to 26ai via the October ’25 avoids application recertification. We believe this design, along with improved latency and integration, will shorten time-to-value for AI implementations.

Autonomous AI Lakehouse

Bottom line
We believe Oracle is focused on delivering a single database plane for transactional/analytic/AI workloads, plus an Iceberg-first Lakehouse that enables interoperability. For enterprises standardizing on open formats but requiring predictable performance and tight linkage to operational systems, this release is strategically important.

With these new enhancements to the Oracle portfolio, we believe Oracle customers must now accelerate migration paths to get their data house in order and prepare for driving stronger AI outcomes. The following sections explore in detail, customer options with respect to migration paths; with assumptions on starting points (Base Case). The model we’re putting forth allows customers to move from the starting point to a variety of targets as described below.

In this exercise we provide rough guidelines in terms of cost, benefit and migration complexity. In a future note, and after reviewing feedback from several sources, we will quantify the business case for each scenario in detail.

Migration Options for Oracle Customers

The following graphic lays out a visual representation of several migration paths that we feel customers should evaluate.

This section of the report provides details for each stage and applies the framework to different-sized companies, designed to represent real-world examples. We also put forth our assumptions on likely costs, risks, and complexities at each stage. Our ultimate intent, which we’ll publish in the future, is to quantify costs and also highlight the strategic value of improved data quality, reduced complexity, elasticity, and automation. We see this exercise as foundational for enabling cross-process efficiency and agentic AI.

The above graphic outlines a two-to-three-year Exadata modernization plan designed to support a business case for Oracle customers considering future investments. While normally we would suggest a longer time horizon, we feel in this day and age time is of the essence to get your data infrastructure house in order.

The primary purpose of this document is to assist customers in identifying a starting point (i.e., Base Case or other Stage), and assess the essential elements and cost/benefit drivers of the six transition stages (Stages 1-6). In our view, the most significant business value will be achieved for those customers adopting 26ai and AI Lakehouse and getting to Stage 6 (Autonomous DB) as soon as possible. 

Stage 0 Company Profiles and Current State

We define two starting points, including: 

1. Base Case A: A purely on-premises installation of mid-sized company with a mix of Oracle and other databases with both transactional and analytic workloads; and 
2. Base Case B: A hybrid on-premeses/cloud large-scale company environment, with similar workloads using a mix of cloud data warehouses and Oracle databases. 

In the Stage 0 scenario below, both companies operate with a hybrid mix of on-premises and cloud systems, leading to fragmented databases across both environments. This siloed setup results in inconsistent data and duplicate efforts, making the real-time integration of operational and analytical systems virtually impossible. Each company faces high maintenance costs and complexity due to the dispersion of data and infrastructure, resulting in low data quality. 

Base Case A – Mid-sized Company with $1 billion revenue, 3,000 employees. 

Company A’s IT landscape is primarily on-premises with dozens of isolated databases supporting various applications. The IT budget is 4.5% of revenue ($45 million/year). Data quality is low and inconsistent across systems, and the proliferation of separate databases creates significant maintenance overhead, which limits the ability to perform real-time analytics as well as adopt/implement AI. The firm would also have a few specialized databases. We are assuming multiple instances of Oracle and MongoDB, SQL Server, and Pinecone for vector.

The company successfully implemented RPA (robotic process automation) in specific areas to streamline intra-process automation within particular departments. However,  attempts to simplify interdepartmental processes using agentic RPA failed. Data fragmentation and conflicting sources created complexities that more than offset any gains. In one case, Company A found an agentic RPA trying to automate a complex manual rule (choosing a financial figure from the CFO data if available, otherwise from the funding department’s data). They abandoned the attempt.

Base Case B – Large Enterprise Company with $23 billion revenue, 60,000 employees.

Company B is a Large Enterprise with an IT budget north of $1B. Company B’s environment is larger but faces similar issues. The company runs hundreds of separate databases on DIY on-premises infrastructure across its business units. Notably, almost all operational systems run on Oracle and other databases on-premises, which accounts for about half of the IT budget. The other half of Company B’s IT spend, mainly on a raft of different analytic systems, is with a leading cloud provider. This combination results in a patchwork of on-prem Oracle systems and various cloud database services. This “use the right database tool for each application” approach has led to significant data silos and consistency problems at scale. Like Company A, Company B has tried to bridge these gaps with RPA/automation tools and custom integrations, but those efforts encountered significant friction. Staff likened them to “running through quicksand.” 

In summary, at Stage 0, both companies lack a single source of truth, which hinders cross-departmental efficiency, increases labor costs, and makes it challenging to leverage advanced generative AI, Agentic AI, and automation.

Modernization Goals to Meet Business Threats

Both Company A and Company B recognize that their current state is unsustainable in the face of modern business demands. The primary strategic driver for modernization is to prepare the companies’ IT foundations for Agentic AI and automation. Achieving this requires a robust, unified data infrastructure. Agentic AI systems require a single trusted source of data rather than multiple silos. 

The companies have already learned this lesson when attempting to layer AI RPA across disjointed systems. A single source of truth is required to automate by streamlining internal operations and the organization. It is also essential to automate Agentic AI with external parties, such as suppliers, customers, and partners.

Company A and B’s leadership understand that modernizing the database architecture is a prerequisite step in improving data quality. This step means providing a unified database infrastructure as the backbone for all systems. Consolidating multiple operational and analytic database types onto Oracle’s converged database platforms, supporting all the required data types, is the first step on the road to improving data quality and consistency significantly. This single-database converged architecture will enable existing applications to run more efficiently and be given with capabilities, such as real-time analytics, cross-department workflows, and AI-driven automation. The key long-term objective for enabling Generative and Agentic AI is to move aggressively toward building a reliable, single source of truth.

The IT department itself stands to benefit from this transformation through the use of AI. Leveraging AI-driven tools and automation will enable faster and less error-prone migration and system rationalization. For example, emerging Agentic AI solutions can automate code conversion, data mapping, and even complete application migration, significantly reducing modernization timelines. In practice, this means IT can accomplish some tasks far more efficiently, freeing them to focus on higher-value activities and reducing the risk of human error during complex migrations.

Beyond internal efficiency, the competitive context is driving a sense of urgency. New startups are building their businesses with integrated cloud systems and high-quality data from the outset, which enables AI-integrated real-time analytics and operations almost from the beginning. These born-digital firms don’t suffer from legacy silos – their unified data platforms translate into greater agility and productivity. In fact, industry research suggests that the superior data quality and cohesion in startups can yield revenue-per-employee productivity that is 5-10 times better than that of traditional enterprises.

Established companies like A and B, on the other hand, have built-in advantages developed over decades. They have a well-established scale of operations, extensive customer relationships, robust supply chains, strong brand recognition, and in-depth industry expertise. Companies A and B have these significant assets. They can leverage them to great effect – but only if the companies modernize their technology and processes to match or exceed the efficiency of the startups. 

Over 50% of today’s largest enterprises acknowledge in their financial disclosures that AI poses a disruptive threat. To remain competitive, the incumbents must become equally data-driven and AI-enabled. Failing to adapt quickly carries real risk. theCUBE estimates that over half of established companies could fail because they did not embrace AI and streamline their operations at a startup’s pace. Companies A and B are keenly aware of these stakes. They also see that it’s not just startups – peer incumbents are racing to modernize and deploy AI, raising the bar for efficiency across the board.

Data Modernization Journey 

Six Transition Stages 

theCUBE research defines six key transition stages for database modernization. This roadmap moves from a fragmented, DIY environment to a fully managed, cloud-enabled database architecture. These are the options open to Company A and B. Stages 1–4 represent a phased journey (gradually adopting converged DB, then Exadata, then cloud, then autonomous). Stages 5 and 6 represent skipping directly to a cloud-based end-state (either Exadata Database Service or Autonomous DB in Oracle’s public cloud) without each intermediate transition. We will evaluate both phased and “skip ahead” scenarios.

The six transition stages are shown in the diagram above and described in more detail below:

Stage 1 – Converged Database Consolidation

Transition: The company converges dozens of isolated, single-purpose operational databases, reducing the number of different databases and running them on common infrastructure. Instead of maintaining separate databases for each data type (JSON, spatial, etc.), all data types and workloads are brought together in Oracle’s multi-model converged database.

IT Impact: Hardware largely remains the same in Stage 1 (the company continues using most of its existing servers and storage), so infrastructure costs are reduced only slightly. Software licensing costs are improved because some standalone databases and/or tools are retired, using fewer Oracle Database licenses overall. Administrative/operational effort may decrease slightly because there are fewer database systems to maintain. There is a limited benefit to facility costs (power, cooling, data center space) since this is a logical convergence on existing hardware. There are also benefits from improved governance, security and data protection, reducing risk. 

Migration Effort: Low. The IT team must design a unified architecture and merge data from all the source systems into Oracle databases. This may involve some small schema changes for individual databases to optimize for Oracle.   

Business Benefits: Stage 1 does not establish a single source of truth for enterprise data because you haven’t yet harmonized data across the application estate. GoldenGate Data Fabric may help achieve this goal but there are out of scope expectations that we won’t dive into here. Data quality improves somewhat as some duplicate and inconsistent records are eliminated. Business benefits are mostly better data governance, less reliance on scarce and costly skills, easier data integration, less complex and reduced license costs, and a small amount of infrastructure consolidation from running fewer databases on underutilized “standard x86 platforms.”

We believe that Stage 0 customers may want to consider moving to Oracle 26ai and the AI Lakehouse at this stage. However, skipping Stage 1 and moving directly to later stages (see next sections) will likely accelerate business value realization.  

Stage 2 – Migrating DIY Infrastructure to Exadata On-Premises

We would strongly advise moving to Oracle 26ai and the AI Lakehouse at this stage, because the benefits of AI and improved data quality will be more pronounced. Adopting Lakehouse AI will accelerate the integration of analytic data. Assuming these moves, data cleansing costs and data integration tools, as well as consulting and testing costs should be explicitly included in the business case to ensure adequate ROI is achieved. 

This is the stage where infrastructure is more powerful and tuned in a way to justify a converged database strategy. Phase one is lift-and-run on Exadata with minimal migration effort to harvest immediate performance gains. Phase two is to rationalize schemas to consolidate databases, collapse ELT data transfers and shrink operational complexity. This captures the full benefit of a single, converged engine.

Transition: The company moves its Oracle databases from general-purpose DIY servers and storage to an Oracle Exadata Database Machine deployed on-premises. This engineered system is purpose-built and optimized for Oracle Database workloads.

IT Impact: Exadata is acquired as a capital expense (or lease). The upfront hardware cost is significant, but a single Exadata system replaces numerous separate servers and storage arrays. The company can reuse or exchange its existing Oracle licenses, and often needs fewer total database licenses after the move because Exadata’s efficiency lets the same workload run on fewer CPU cores. Exadata’s integrated design and automation tools also reduce ongoing DBA work for tuning, patching, and maintenance.

If you skip from the base case directly to Stage 2 then Exadata’s efficiency and performance may allow you to do everything with the same number of Oracle Database licenses you had in the base case and eliminate the licenses from the other vendors, increasing lock-in risk but delivering immediate business value. In our view, the mandate to get to AI quickly should offset vendor lock-in concerns. 

Migration Effort: Moderate. Migrating from existing Oracle databases to Exadata can be done with minimal downtime using Oracle tools like Zero Downtime Migration, Data Guard or GoldenGate for replication. The project includes setting up and configuring the Exadata system, testing performance, and then migrating production databases to the new environment. DBAs may need some training to fully leverage Exadata features and best practices. Typically, the new Exadata environment is run in parallel with legacy systems during the transition period, which can lead to some overlap in costs in Year 1 that may slightly spill into Year 2 of the plan.

Business Benefits: Stage 2 yields immediate improvements in performance, reliability, and cost efficiency. Reducing the number of schemas, improving data quality and reducing data engineering costs. Exadata’s specialized hardware and software deliver much faster query and transaction processing (~2X by our estimates). Features such as Smart Flash Cache, storage offload processing, and a high-speed RoCE network accelerate I/O and query execution dramatically. Reliability is higher because Exadata’s fully redundant, tested architecture results in far fewer unplanned outages. In terms of cost, Exadata lowers the total cost of ownership versus DIY. With better performance, the company can handle the same workload on less hardware, and Oracle’s automation reduces administrative labor. Our analysis will quantify the actual cost impact over a multi-year period.

Stage 3 – Exadata On-Premises to Exadata Cloud

Stage 3 brings the cloud operating model to all supported workloads and is an optimal path from the base case in our view. All subsequent Stages are now consumed as cloud services (i.e. Opex). 

Transition: The company migrates from an on-premises Exadata setup to an Oracle Exadata Database Service. This can be done via Exadata Cloud@Customer (keeping Exadata hardware on-prem but managed through the Oracle Cloud control plane) or by moving databases to Oracle’s Exadata Database Service in the Oracle public cloud (OCI).

IT Impact: The IT cost model shifts from owning hardware (CapEx) to a cloud subscription (OpEx). Oracle now provides and manages the physical infrastructure. This eliminates on-prem hardware upkeep and reduces data center costs for power, cooling, and floor space. [Note: Cloud@Customer will still incur these costs]. Database administration burdens also decrease as Oracle’s cloud team handles many routine tasks.

Migration Effort: Moderate. Since the databases are already on Exadata and fully compatible with Oracle Cloud, the migration is straightforward technically. The team needs to establish network connectivity (such as VPN or Oracle FastConnect), replicate the data to the cloud environment, and perform the cutover with minimal downtime. Key tasks include planning security and compliance in the cloud deployment and thorough testing of performance and functionality. These one-time migration activities must occur in 18 months less or you risk falling behind in the AI race. Oracle and its partners offer “lift-and-shift” services to assist with this move, but the company should still budget for migration tools and any parallel operations needed during the transition.

Business Benefits: Stage 3 introduces cloud agility and scalability. The company can provision new database instances in minutes and scale resources on demand, rather than procuring and installing hardware for each new project. This speed and flexibility accelerate development and testing cycles for applications and allow the business to respond quickly to changing workloads. Financially, aligning costs to actual usage improves efficiency – there is no need to over-provision capacity for peak times only. We estimate this stage delivers a strong return on investment and will quantify this in our next post to include ROI, NPV and payback periods.  

Stage 4 – Exadata Database Service to Autonomous Database Dedicated (ADB-D)

At this stage, Oracle is autonomously managing the database updates, patches, tuning and other day-to-day operational activities, eliminating many labor costs, improving overall quality and reducing downtime. Keep in mind that Oracle has substantial expertise managing many thousands of customers and, through R&D, is conferring volume learnings into its product offerings. 

Transition: The company enables Oracle Autonomous Database Dedicated on its Exadata cloud deployment. In this stage, Oracle’s cloud automates most database administration tasks, including patching, tuning, backups, and scaling, on a dedicated Exadata infrastructure that is reserved for the company.

IT Impact: The service remains a subscription (OpEx), but now the day-to-day database administration effort is minimal. Oracle’s automation handles routine maintenance and performance optimization. This reduces the risk of human error and virtually eliminates manual downtime for maintenance. The result is even higher availability and less time spent by internal DBAs on basic upkeep.

Migration Effort: Moderate. In Stage 3 the databases already run on Exadata in Oracle Cloud. Moving to Autonomous Database Dedicated requires primarily configuration and policy changes. Oracle enables autonomous features on the existing databases and validates workloads and applications under autonomous mode; significant application rewrites and bulk data migrations are not required. Almost all Oracle Database capabilities carry over. Some edge cases do not fit a fully automated environment and require adjustments. Teams should trim run scripts and make minor application changes. Use Oracle Estate Explorer to identify gaps and remediation tasks. Oracle and partner services can assist. Databases that are not ready can continue to run on the same physical Exadata infrastructure alongside Autonomous. This supports a phased adoption plan – i.e. enable Autonomous where feasible, keep exceptions on Exadata, and avoid a “big bang” cutover.

Business Benefits: Stage 4 provides a significant boost in operational efficiency and reliability. With self-driving database operations, unplanned downtime can drop by up to 90% based on our estimates, due to proactive issue prevention and fast, automated recoveries. DBAs are freed from most maintenance tasks – their productivity (or capacity to take on strategic work) increases by a meaningful percent (that we will quantify in the future) because the platform manages itself. Developers also become more productive but at least 30% as they can get new environments and performance optimizations instantly, without waiting on IT. This stage positions the company to leverage advanced, Agentic AI process automation, since the data platform is now converged, consolidated, highly optimized and managed by AI.

Autonomous Database adjusts consumption to match aggregate workloads in real time. It monitors active SQL and automatically scales elastic compute up or down, increasing performance under load and reducing spend when demand falls. Costs for software are included and BYOL tracks the ECPU usage. As in Stage 3, Oracle APEX is included. Stage 4 adds Developer Studio and additional tools at no additional cost. These tools speed application development, reduce code volume (Oracle claims APEX can cut lines of code by up to 90%), simplify maintenance, and lower operating costs.

Stage 5 – DIY to Exadata Database Service on Exascale Infrastructure (ExaDB-XS)

Step 5 is an alternative path to step 4 that enables the ability to run small to medium workloads on shared infrastructure and allows customers to maintain full control over their database while also gaining the cost benefits of a serverless-style elasticity for Exadata performance workloads.

Transition: In Stage 5, the company jumps straight to Oracle’s Exadata Database Service on Exascale Cloud Infrastructure (ExaDB-XS) from its legacy on-prem systems. This is Oracle’s latest multi-tenant Exadata cloud offering designed mainly for smaller firms. Most large companies would migrate to Stage 6 (see below). 

IT Impact: If coming from stages prior to Stage 3, infrastructure is obtained as a cloud service (100% OpEx). The company pays for database capacity on a usage basis, running on Oracle’s high-end Exadata cloud platform. On-premises hardware and associated facility costs are eliminated entirely. One financial consideration: because this move happens in one leap, the company may have to write off or accelerate the depreciation of its existing data center hardware that is being retired earlier than planned.

Migration Effort: Low-to-Moderate depending on the starting point. A direct move to the ExaDB-XS cloud environment requires a one-time migration of data and applications. The IT team must plan and execute the transfer of all databases to the cloud, which involves data migration, reconfiguration, and testing efforts happening in parallel. This approach demands some upfront work. Oracle has tooling and migration services to assist and can minimize business disruption.  

Business Benefits: Stage 5 allows the company to realize the end-state benefits of a modern Exadata cloud platform as soon as the migration is complete, rather than waiting through multiple intermediate steps. Immediately, the company gains the performance and reliability advantages of Exadata in the cloud – for instance, downtime can be reduced and query performance improved. IT staff can refocus on innovation, since Oracle now handles infrastructure and database management. This approach is projected to deliver significant ROI for companies. More importantly, reaching an advanced cloud architecture sooner gives the business a head start in deploying AI-driven, agentic process automation, which significantly improves its chances of surviving and thriving against fast-moving competitors.

Stage 6 – DIY to Autonomous Database Shared (ADB-S)

Elastic resource pools are integrated into this stage. Oracle claims additional simplification and consolidation benefits within a Serverless Autonomous Database, instead of running each database separately.

Transition: In Stage 6, the company is now in a cloud-native end state, but here it adopts Oracle Autonomous Database using Serverless. This is the desired end state of the journey where you get the most advanced features and automation. Cost should be optimized as these features are all rolled into one experience. Customers may arrive here from Stage 2 or three or directly from the base case. 

 IT Impact: As in earlier stages (after Stage 3), the entire IT infrastructure for databases becomes an on-demand cloud service (OpEx). The company is billed based on consumption (for example, per CPU-second of database usage), meaning costs exactly align with business activity. There are no traditional on-prem hardware, storage, or data center expenses anymore. As with Stage 5, an immediate cloud move can render existing hardware investments obsolete, potentially requiring a one-time financial write-down of those assets.

Migration Effort: Variable depending on workloads migrated and starting point. This migration could involve moving all data and database workloads to the Autonomous Database platform at once or doing so in increments from previous stages. The effort is comparable to Stage 5 in scale. The autonomy features may require some adjustments (for example, ensuring that automated indexing or scaling doesn’t conflict with application expectations), but no major custom infrastructure work is needed since Oracle handles the platform. The planning and execution are of moderate intensity, but once done, any remnants of the legacy environment can be fully decommissioned. Once again, Estate Explorer can help identify gaps and remediation tasks. 

Business Benefits: Stage 6 immediately provides the full benefits of Oracle’s most advanced cloud database service. The company gains Exadata-level performance and availability from day one, and additionally benefits from fully autonomous operation – the databases handle patching, tuning, scaling, and fault management by themselves. This results in a major reduction in downtime and significantly faster query and transaction performance without manual intervention. New databases or expansions are available instantly on demand, supporting rapid development and scaling of applications. The anticipated ROI is high thanks to the elimination of infrastructure management costs and improved productivity across IT and development teams. Achieving this state early gives the company the fastest path to implementing agentic AI process automation and strengthens its competitive position for the future.

The following table reflects our most current assessment of costs, migration effort and business benefits.

 Conclusions

In our view, Oracle’s AI World announcements signal a practical path to close the AI ROI gap by standardizing on the latest converged database technologies. Our playbook calls for the collapse of data silos, standardizing on a converged database plane (26ai), and adopting an Iceberg-friendly lakehouse that federates catalogs across clouds and Cloud@Customer. The strategy trades vendor “lock-in” debates for measurable gains – governed data access, simpler operations, and predictable performance built into operational systems. Our initial research premise suggests the highest payback comes from moving quickly off DIY sprawl to Exadata services, then enabling Autonomous capabilities to cut labor costs, shrink downtime, and speed releases. The north star remains a single, governed truth spanning clouds; 26AI and the Autonomous AI Lakehouse, which we believe in concert move customers materially closer to an infrastructure that can support an “intelligent enterprise” vision.

The mandate now is execution. We believe leaders should:

• Sequence migrations to Exadata services, including 26ai and AI Lakehouse; then flip on Autonomous where feasible to capture Opex and resilience gains; assess the business case for skipping stages and moving directly to more advanced infrastructure to accelerate AI ROI.
  
• Prioritize Iceberg interoperability and a “catalog of catalogs” approach to access distributed data without re-platforming.
  
• Consider retiring standalone vector stores and brittle ELT systems as 26ai unifies vectors, real-time analytics, and workloads in-database.

Enterprises that follow this path have the opportunity to make huge strides in developing a single version of the truth, compress time-to-production for agentic workflows, and shift spend from integration technical debt to business outcomes.