Oracle Fusion quarterly updates: how to test inside the two-week window

On SAP you can sometimes argue about when to take an upgrade. On Oracle Fusion Cloud ERP you cannot. Oracle updates every environment four times a year, the updates are mandatory, and production follows your test pod by two weeks. If you sign off Oracle releases, that two-week window is the most important date range in your year. This guide covers the calendar, what Oracle tells you in advance, and a test routine that fits.

The calendar you are signing up for

Oracle delivers new features and major enhancements in quarterly updates, named by year and letter: 26A, 26B, 26C and 26D in 2026. They are mandatory for all customers, and your applications are unavailable during the maintenance window^[1]. Each environment family is assigned one of three month groups: February, May, August and November; March, June, September and December; or April, July, October and January. Payroll customers are fixed to the first group. You cannot change the group after the family is created^[1].

Within your update month, non-production environments are updated the weekend after the first Friday, and production the weekend after the third Friday. Middle East regions use the first and third Thursday instead^[1],[2]. Oracle emails notifications 30 days and 7 days before each maintenance event^[1]. Applying that rule to 26D gives these dates. Check them against your own notices.

For 26C, ERP Today reported the first cohort’s test update on August 7, 2026 and production on August 21, with the other cohorts following in September and October^[5]. That matches the rule. Monthly patching is separate: it carries bug fixes only and is optional for most customers, though mandatory for families with Oracle’s PCI compliance service and for US and UK government customers^[1].

What Oracle tells you before the update

Oracle publishes a What’s New document per product well before the update reaches your test pod. The Financials 26D edition was created on September 4, 2026 and was still being revised on October 13^[4]. Read it more than once.

Two columns in its feature summary do most of the triage for you. “Impact to existing processes” rates each feature as larger scale, small scale, report, or none. Oracle says to focus acceptance testing on the larger-scale features. A rating of none means the feature is not delivered enabled. “Action to enable” tells you whether you must opt in, do setup, or raise a service request^[4]. In the Financials 26D summary as revised on October 13, 5 of the 49 features listed are delivered enabled; the other 44 wait for you to act^[4].

The two-week window is shorter than it looks

Three constraints shrink the window. First, you cannot refresh test from production inside it. A production-to-test refresh needs source and target on the same update and patch level. Oracle blocks refreshes in the 5 days before the target’s maintenance and between two different maintenance dates. A target can be refreshed once every 7 days, and a refresh typically takes up to 48 hours^[3]. So test data has to be right before the test pod updates.

Second, problems need Oracle. The Quest Oracle Community’s advice is to log a service request as soon as you find an issue in the test pod, so it can be fixed before production^[13]. That only works if you find issues in the first week, not on the second Thursday.

Third, business testers have day jobs. If finance first hears about the window when it opens, you will lose days to scheduling.

What breaks: three examples from Oracle’s own documentation

Roles. Oracle recommends copying predefined roles rather than assigning them as shipped. It also says updates can change predefined roles, and that bringing those changes into your custom roles is ongoing work^[6]. The Security Console’s Compare Roles function exists for exactly this: compare your copy from the earlier update with the role as shipped in the new one, then decide what to adopt^[7].

Integrations. When Oracle Integration invokes a file-based import through the ERP Cloud adapter, a separate callback integration receives an event when the import finishes. Oracle raises it whether the job succeeds or fails^[8]. After instances moved to 25C, integrations still using the older SOAP-based callback failed with a 401 Unauthorized error until they were rebuilt on the event-based design^[9]. A regression that only ran the happy path in the test pod would have caught that one. One that never ran the integrations would not.

Evidence. Oracle automatically purges file-based import interface data older than 30 days^[10]. If your regression includes data loads, save the import reports with the test result.

What goes in the core regression

The core suite is the part you run every quarter, whatever the What’s New says. Keep it small enough to finish in the first week, and make every expected result checkable: a journal posted, an amount, a status, a file accepted by the bank. “Screen opens” is not a result.

• Record to report: post a manual journal, import journals through the file-based import, run create accounting, and compare a trial balance with the last update’s baseline.
• Procure to pay: requisition, approval, purchase order, receipt, invoice match and validation, and a payment run that produces the bank file.
• Order to cash: a Receivables transaction with tax, an imported transaction, and a receipt applied to it.
• Integrations: one success and one failure case for each integration that moves money or posts to the ledger.
• Security: one positive and one negative test per critical job role, plus the role compare.
• Reports and scheduled processes: the reports finance closes the month with, and the recurring jobs with saved parameters.

Everything else is scoped by the triage: the features Oracle rates larger scale, any feature delivered enabled in a module you use, and the processes behind features you plan to opt into.

A routine that fits the window

1. Before the test pod updates (two weeks or more ahead): download the feature summary for every product you use. Mark each feature enabled, opt-in, or not used, and list opt-in expirations. Confirm test data and roles are in place, because you cannot refresh later.
2. Day 1 to 5 of the window: run a fixed core regression of your top 20 processes, every integration that moves money or posts to the ledger, a role check per critical job role, and key reports. Test the larger-scale features Oracle flagged. Raise service requests the same day.
3. Day 6 to 10: retest fixes, test any opt-in features you plan to enable, run Compare Roles, and collect the business sign-off.
4. Before the third Friday: a named person signs that production can update, based on evidence: critical pass rate, open defects and service requests, and the list of features you will opt into later.

The free Oracle Fusion Quarterly Update Test Plan calculates your dates from your month group, triages What’s New features and rolls the regression up to a sign-off. For roles and integrations, use the Role & Security Test Matrix and the OIC Integration & P2T Refresh Tracker.

Manual or automated?

Four mandatory regressions a year, each squeezed into two weeks, make a strong case for automation. Oracle’s own Application Testing Suite is not the answer for Fusion. Its Premier Support ended in June 2022, Oracle said further investment would serve only E-Business Suite testing, and it advised customers testing other applications to look at alternatives^[11]. Whatever tool you choose, automate what runs every quarter and fails expensively first: postings, payments, integrations and period-close steps. Measure regression cycle time per update. If it is not falling, the suite is not keeping up.

A note for EBS and JD Edwards teams

If you are still on E-Business Suite 12.2 or JD Edwards EnterpriseOne 9.2, Oracle’s current policy gives Premier Support through at least December 2037. Oracle may extend that date in one-year steps, but it is not guaranteed^[12]. That is time to plan a move properly, not a reason to skip regression. JD Edwards Tools releases expire six months after a newer one becomes generally available^[12]. If you do move, the quarterly rhythm in this guide starts on day one, including during the implementation.