Quick answer
Oracle Fusion 26C is the third quarterly release of 2026, spanning Financials, SCM, HCM, CX, EPM, Projects, Risk & Compliance, and Platform. Oracle’s official Feature Listing shows 811 features as of the July 3 report, with nearly 60% flagged for Redwood UI, 139 involving AI capabilities, and SCM carrying the largest share of changes.
As with every quarterly update, test environments update on the first Friday of the update month, with production following two weeks later on the third Friday. For 26C, Cohort A customers see test environments update August 7, 2026, with production following August 21. Cohort B follows in September (test September 4, production September 18) and Cohort C in October (test October 2, production October 16). Check the Oracle Cloud Console if you’re unsure of your cohort. Oracle’s 26C readiness content, including the What’s New documentation and the weekly Feature Listing report, is already live, which gives every cohort at least a month of lead time.
That’s a substantial change footprint, arriving on top of whatever configuration drift your environments accumulated from 26A and 26B. For teams that treat quarterly updates as testing events, 26C is going to be a busy two weeks. For teams that treat them as structured release and configuration events, it’s a manageable cycle.
The distinction is worth naming. DevOps is how you manage the release process: pipelines, promotion gates, automation, traceability. Configuration management is how you control what your environments actually contain: what’s configured, how it differs across environments, what changed and when. Oracle quarterly updates require both. The release process gets the update from test to production safely. Configuration management ensures what lands in production matches what was validated in test, and that the audit trail exists to prove it.
Practically, that means capturing a configuration baseline before your test environment updates, running an environment comparison as soon as the patched environment is available, and remediating any changes identified — especially user access, system profile options, and opt-in features. Flexagon Configuration Management is the tool most of this post assumes you’re using to do that work: it captures baselines, runs environment comparisons, and helps generate the documentation your audit trail needs, across both Oracle Fusion Cloud and E-Business Suite environments.
This post covers what 26C changes in your Oracle Fusion environment, what it means for your DevOps pipeline, what it requires from a configuration management perspective, and what your team should be doing before your test environment updates — with specific notes on where Flexagon Configuration Management’s functionality applies at each stage.
What 26C changes in your environment
26C continues themes introduced in 26A and 26B. Of its 811 features, 473 carry Oracle’s Redwood flag, 139 involve AI capabilities, and SCM alone accounts for 342. Four categories of change carry the most operational weight.
Redwood UI conversions
Oracle’s ongoing migration to the Redwood UI framework continues in 26C, and it is the defining feature of this release: 473 of the 811 features in the 26C Feature Listing carry the Redwood flag, nearly 60% of the release. Oracle Supply Chain Management has moved into its mandatory Redwood transition phase, with full adoption required by 26D in Q4 2026. (Source: Oracle Fusion to Redwood Migration Guide, USDM)
For configuration management purposes, Redwood conversions matter because they change the underlying structure of the pages being redesigned. Functional setups tied to previous page behavior need to be validated against the new interface. Any customizations built on legacy Oracle Page Composer will not carry forward to Redwood pages automatically.
The practical implication for your team: review which modules are converting to Redwood in 26C, confirm that your existing functional configuration validates correctly in the new UI, and plan any required rework before your production cutover date. Redwood conversions are part of Oracle’s quarterly release cadence and will continue in 26D and beyond.
Where Flexagon Configuration Management helps: baseline the functional configuration behind a converting module before the switch, then re-run the comparison once the Redwood version is live. The report shows which setup values carried forward cleanly and which didn’t, so validation can focus on what actually changed rather than a full manual walk-through of every screen.
AI agent configuration
26B introduced Oracle’s first wave of Fusion Agentic Applications: a Security Command Center, Ledger Agent, Payables Agent, Expenses Agent, and Payment Agent across Finance and ERP, plus ten agentic apps across Supply Chain and Manufacturing, and several agentic apps across HCM covering hiring, employee support, learning, and workforce management. (Source: Oracle 26B Roadmaps, Fusion Insider) 26C expands these capabilities further, with 139 AI-flagged features in the Feature Listing: 109 agent features, 18 agentic apps, 9 generative, and 3 predictive. HCM and SCM carry the largest share.
26C also retires the standalone AI Configurator in favor of AI Agent Studio, a single environment for managing prompts and agents together. Existing prompts need to be copied into the new environment and revalidated rather than migrating automatically — worth flagging to whoever owns AI configuration testing before your cutover date.
Each AI agent capability requires enabling configuration, and that configuration needs to be consistent across environments before you can meaningfully test agent behavior in test prior to production cutover. The broader context for this risk is covered in Flexagon’s Oracle AI readiness guide and the follow-up post on preparing Oracle environments for AI-driven change.
Where Flexagon Configuration Management helps: The AI Agent setup can impact various areas of existing configuration including: Opt-In Features, Offerings / Implementation Projects, Profile Options, Profile Option Values, Job Roles, Duty Roles, Abstract Roles, Aggregate Roles, Data Roles, Privileges, Data Roles, Security Profiles, Descriptive Flexfield Segments, Extensible Flexfields, Standard Lookups / HCM Common Lookups. Using the pre-patch baselines and comparing them to the post patch live environments you can readily see where changes have been introduced and take action accordingly.
OIC and integration dependencies
Integration changes are where configuration management and DevOps converge most directly. Oracle Integration Cloud follows its own release cadence alongside the Fusion quarterlies, but a Fusion quarterly update can change the application behavior your integrations depend on. A functional configuration change in one Fusion module can affect integration behavior downstream, including Oracle Integration Cloud, connected enterprise platforms, and reporting environments. Changes to OIC integration configurations need to travel through your environments with the same discipline as application configuration changes. See Flexagon’s Oracle Cloud Integration solutions for how this is managed in practice.
Where Flexagon Configuration Management helps: Flexagon Configuration Management baselines and compares the Fusion-side configuration these integrations depend on, such as value sets, flexfields, and security setup, so a relevant change surfaces in the same comparison report as everything else rather than only showing up when an integration breaks downstream. It doesn’t manage the OIC integration objects themselves; that’s what Flexagon’s dedicated Oracle Cloud Integration tooling is for, working alongside Flexagon Configuration Management rather than in place of it.
SOX and GDPR audit hardening
26C also touches the areas auditors care about: the Feature Listing includes a large-scale Applications Security change and multiple Local Compliance & Reporting features that require setup. For Oracle Financials environments under compliance scope, these changes deserve specific attention. Audit hardening modifications can alter how configuration changes are logged, how access controls are enforced, and how approval workflows behave. These are exactly the areas your compliance team and auditors focus on. An audit hardening change that applies differently across your environments is not just a testing problem. It is a compliance posture problem.
Flexagon Configuration Management supports this as follows. Environment comparison — catching a control or access change to existing roles / users that behaves differently in one environment than another. Change Tracking, which captures who changed a specific record, when.
What 26C means for your DevOps pipeline
This is where most quarterly update guidance stops short. The focus tends to be on functional testing and release notes. But 26C has direct implications for how your Oracle DevOps pipeline operates. Those implications are worth thinking through before your test environment updates, not after.
Post-update environment comparison as a pipeline gate
A DevOps team managing Oracle Fusion releases should treat the two-week window between test and production updates as a structured pipeline stage rather than an unstructured testing period. That means running a formal environment comparison after test environments update, documenting the delta, and using that comparison as a gate before promoting to production.
In practice, most Oracle DevOps pipelines do not include this step explicitly. Environment comparison is treated as a manual activity rather than a documented gate with a clear pass/fail condition. 26C, given its breadth across modules, is exactly the kind of release where the difference between a structured gate and an informal check becomes visible. A field-level comparison between test and production environments before production cutover, covering the modules impacted by 26C, gives your team a defensible record of what changed and what was validated. Flexagon’s enterprise DevOps capabilities guide covers environment comparison as a core platform capability and the questions worth asking about your current tooling.
Flexagon Configuration Management’s monitor and scheduling functionality can run comparison reports automatically and on a recurring basis rather than depending on someone remembering to kick one off — useful for treating the post-update comparison as a scheduled gate rather than an ad hoc task.
Configuration management as the foundation for release confidence
A DevOps pipeline without configuration management underneath it is a fast way to move changes between environments that may not be consistent with each other. The pipeline enforces process; configuration management enforces state. For Oracle Fusion environments going through 26C, both matter.
In practice this means: before your test environment updates, you need a documented baseline of your environment state. During the testing window, you need a comparison that tells you what 26C changed and what was already different. Before production cutover, you need confidence that test and production are consistent on the configurations relevant to this release. After production updates, you need a record that proves it. That is configuration management discipline applied to a quarterly release cycle.
This is what Flexagon Configuration Management, integrated with the former FlexDeploy platform, is built to deliver across both Oracle Fusion Cloud and E-Business Suite environments: point-in-time baselines, live environment and baseline-to-baseline comparison, and configuration migration to promote validated deltas from test into production rather than reconfiguring by hand. Paired with FlexDeploy, now the Flexagon platform, that comparison and baseline data feeds into a deployment record that documents what was released and when, supporting standards like Sarbanes-Oxley through automated reporting.
The two-week window is a release event, not just a testing event
For a DevOps team managing Oracle Fusion, the window between test and production updates is the equivalent of a controlled release cycle. You have a known change arriving on a known date. You have a two-week validation period. You have a production cutover date. That is a release. It should be managed like one: with a pre-update baseline, a comparison run after test updates, documented changes, and a post-production validation to confirm the environment matches what was tested. Flexagon’s enterprise DevOps platform capabilities guide covers what that release discipline looks like at scale.
What to do before your test environment updates
The preparation work before a quarterly update is primarily configuration management work. The goal is to understand the current state of your environments well enough that when the update arrives, you can isolate what it changed from what was already different. Three activities have the most impact.
Capture a pre-update baseline
Before your test environment updates, document the current configuration state of your test environment. This is the reference point for understanding what 26C actually changed in your specific Oracle environment, as distinct from what Oracle’s release notes describe as changing across all environments. Without a pre-update baseline, you cannot reliably separate 26C-induced changes from pre-existing environment inconsistencies during the testing window. 26C is also a forcing point for previously optional features: the Feature Listing shows opt-in windows expiring at 26C for Intercompany Processing and Process Manufacturing features, with more expiring at 26D across Maintenance, Manufacturing, and the Sales Redwood user experience. A feature that switches itself on is an environment change no one requested, and a baseline is how you catch it.
Flexagon Configuration Management baselines can be scoped by “Process” (user-definable template) and run in parallel, so a full pre-update baseline of a large test environment doesn’t have to be a manual, single-threaded task the week before your update lands.
Validate integration dependencies and existing configuration
Before your test environment updates, review which OIC integrations connect to the Fusion modules most affected by 26C, particularly Finance, SCM, and any modules where you have enabled AI agent capabilities. Document the current activation and connection state so post-update changes are visible rather than discovered when something breaks downstream. For Redwood UI modules converting in this release, confirm that your existing functional configuration validates correctly in the new interface and identify any customizations that may need review. Flexagon Configuration Management’s baseline comparison can flag configuration changes in the Fusion setup steps feeding these integrations, even where the integration platform itself is out of scope.
Identify your large-scale and auto-enabled items
Oracle’s Feature Listing flags 34 of the 811 features in 26C as having a large-scale impact to existing processes, with another 314 flagged as small-scale. On the enablement side, 376 features require setup and 164 involve opt-in or potential setup, while roughly 250 list no enablement action at all, meaning they land in your environment automatically. Those auto-enabled changes deserve particular attention because they alter environment state without anyone opting in. The useful exercise is identifying which items are relevant to your specific configuration, including your active modules, your enabled integrations, and your AI agent setup, and concentrating testing effort there rather than treating all changes equally. Flexagon Configuration Management “Processes” can be scoped to exactly those steps, so comparison and testing effort concentrates on what 26C actually touches in your instance rather than everything Oracle changed across the release.
Oracle recommends establishing an interdisciplinary team responsible for assessment, testing, and rollout of new features, staffed by representatives from technical, business, and end-user communities, with executive sponsorship particularly when it comes to adopting new features and navigating any resulting change management. (Source: Oracle Fusion Insider: Quarterly Updates Made Easy). For 26C specifically, that team needs a DevOps or technical representative alongside the functional testing leads, specifically someone who owns the pipeline implications of the OIC changes and AI agent configuration scope.
During the two-week testing window
The two-week window has two parallel workstreams that need to run simultaneously. Functional testing validates that 26C behaves correctly for your users. Configuration management validates that your environments are consistent and that the changes are documented. Most teams run the first workstream well. The second is where gaps appear.
After test environments update, run a comparison against the pre-update baseline — the core Flexagon Configuration Management comparison workflow, whether that’s baseline against live environment or baseline against baseline. This separates 26C changes from pre-existing differences. That separation matters both for testing accuracy and for change management documentation. A test result that behaves unexpectedly could be a 26C change, a pre-existing environment difference, or a combination of both. A baseline comparison tells you which.
Validate integration behavior explicitly. Do not assume that a clean functional test result implies clean integration behavior. OIC changes in 26C can affect how integrations behave downstream, and functional testing of the Fusion application itself does not surface integration failures until they show up in connected systems.
Document what the update changes in your environment. The change management record for 26C in your production environment is part of your SOX ITGC evidence. Flexagon maintains a detailed audit trail of deployment activities — visibility into who made changes, what was modified, and when — supporting compliance with standards like Sarbanes-Oxley through automated reporting. (Source: 5 Ways FlexDeploy and ConfigSnapshot Revolutionize Oracle EBS, Flexagon)
After production updates
After production updates, capture the post-26C production baseline. This is your starting point for 26D preparation, which begins arriving in November for Cohort A customers. Run a comparison between production and test to confirm that what was validated in test is what actually reached production. Compare this new baseline against your pre-update and post-test baselines in Flexagon Configuration Management to confirm what changed at each stage, not just what changed overall.
The teams that find each Oracle quarterly update progressively easier to manage are the ones that treat configuration management as a standing discipline rather than a pre-deployment activity. Each cycle produces a baseline. Each baseline becomes the foundation for the next cycle. Over time, environment consistency becomes the default state rather than something that needs to be recovered before each update.
Frequently asked questions
When does Oracle Fusion 26C update test and production environments?
For Cohort A customers, test environments update August 7, 2026, and production follows on August 21, 2026. Cohort B receives 26C in September (test September 4, production September 18) and Cohort C in October (test October 2, production October 16). Check your Oracle Cloud Console to confirm your cohort.
What is the difference between DevOps and configuration management for Oracle Fusion?
DevOps manages the release process: pipelines, promotion gates, automation, and traceability. Configuration management controls what your environments actually contain: what is configured, how environments differ, and what changed and when. Oracle quarterly updates require both to move safely from test to production with a verifiable audit trail.
What should I do before Oracle Fusion 26C updates my test environment?
- Capture a pre-update configuration baseline of your test environment.
- Validate which OIC integrations connect to the modules affected by 26C, particularly Finance, SCM, and AI agent-enabled modules.
- Identify which large-scale impact and auto-enabled items in 26C apply to your specific configuration.
- Confirm existing functional configuration validates correctly in any modules converting to Redwood UI.
How does Flexagon Configuration Management help with Oracle Fusion 26C specifically?
Flexagon Configuration Management baselines your environment before 26C lands, runs the environment comparison once your test pod updates, and lets you scope that comparison to the modules, AI agent configuration (see details above), and integration-adjacent setup relevant to your instance, rather than treating all 811 features as equally important.
For E-Business Suite environments, Full Audit Tracking adds record-level detail on who changed what and when; for Oracle Fusion Cloud, that same visibility comes from baseline-to-environment comparison rather than continuously logged, record-level tracking.
