Oracle Fusion Cloud Applications are updated every quarter. The update is mandatory. Your non-production environment (test pod) is normally updated first and production follows a couple of weeks later. That gap is your testing window.
Most customers do not have a problem with any single update. They have a problem with the cycle: four updates a year, each needing business users, consultants and integration owners at short notice. This guide sets out a repeatable approach that Egisedge uses, based on our quarterly update regression playbook and Oracle's own guidance on what to test after a quarterly update.
How the quarterly update cycle works
Oracle publishes the update schedule for your environments in advance. For each release, Oracle also publishes Readiness material ("What's New") for each product family. For ERP, see Oracle Cloud Readiness: ERP. HCM and SCM have their own Readiness pages.
The Readiness material tells you:
- New features, and whether each is enabled automatically or needs opt-in.
- Changed behaviour in existing features.
- Features being removed or replaced, such as older pages moving to Redwood pages.
Features that are delivered "enabled" are the ones most likely to affect users without anyone asking for them. Read these first.
The testing process, step by step
1. Review the Readiness notes (four to six weeks before)
Start early. Assign each product area to an owner: Financials, Procurement, HCM, Payroll, SCM. Each owner reads the relevant Readiness notes and lists:
- Features enabled automatically that touch your processes.
- Opt-in features the business may want.
- Changes that could affect integrations, reports or extensions.
Put these in a single impact log with a test decision against each line.
2. Confirm environment and data readiness
Check the date your test pod will be updated. If its data is stale, request a production-to-test (P2T) refresh well before the update so you test on realistic data. Oracle's guide to environment refreshes and updates explains how refreshes and updates interact. Remember that a refresh overwrites test configuration, so capture anything you need first.
3. Prepare the regression pack
Your regression pack should be fixed, versioned and owned. It is not rewritten every quarter. It covers:
- Critical end-to-end flows: record-to-report, procure-to-pay, order-to-cash, hire-to-retire and payroll.
- Inbound and outbound integrations, including OIC flows, FBDI loads and file transfers.
- Reports: BI Publisher, OTBI analyses and financial reports used at month end.
- Personalisations, page extensions and any Visual Builder or APEX extensions.
- Security: a sample of roles checked for access they should and should not have.
- Approval workflows and notifications.
4. Run the tests on the updated test pod
Run the pack as soon as the test pod is updated. Run the high-risk items on day one. Record evidence (screenshots or logs) for each test.
5. Test opt-in features the business wants
Test opt-in features separately from regression. A new feature should not be enabled in production until the business owner has seen it working on their data.
6. Log defects and raise SRs
Triage each failure quickly. Is it a product bug, a configuration issue on your side, or a changed behaviour documented in Readiness? Raise a Service Request with Oracle for product bugs immediately, with steps to reproduce and evidence. Waiting until the end of the window leaves no time for a fix.
7. Sign off before the production update
Hold a short go/no-go meeting with the owners. Record which tests passed, which defects are open, and what workarounds are in place. Share the list of changed behaviour with support staff and key users.
8. Smoke test production after the update
After the production update, run a short smoke test: log in with key roles, post a journal, create and validate an invoice, run a key integration, open the main reports. Keep this to an hour or two.
Prioritising what to test
You cannot test everything each quarter. Use a simple risk rating.
| Priority | What falls in it | Test approach |
|---|---|---|
| P1 – every update | Payroll, payments, period close, tax calculation, critical integrations | Full end-to-end, every quarter |
| P2 – when touched | Modules named in Readiness notes; reports and extensions on changed objects | Targeted tests on affected areas |
| P3 – rotate | Low-volume processes, rarely used reports | Rotate through across the year |
| New features | Opt-in features requested by the business | Separate test and business demo |
Quarterly update checklist
- Update dates for test and production pods noted in the project calendar
- Readiness notes reviewed by each product owner
- Impact log created with a test decision for each item
- Test pod refreshed from production if data is stale
- Regression pack version confirmed and test users ready
- P1 tests run on day one of the updated test pod
- Integrations and scheduled processes checked
- Reports and extensions checked
- Defects triaged; SRs raised for product bugs
- Go/no-go held and minuted before the production update
- Production smoke test completed
- Changed behaviour communicated to users and support
Automate the stable parts
The same P1 tests run four times a year. That makes them good candidates for automation. Automated tests for stable, high-volume flows turn a regression cycle from weeks into days. Keep manual testing for new features, judgement calls and anything visual. Whatever tool you use, the pack must be maintained. An automated test that nobody updates after a process change will either fail every quarter or, worse, pass while testing the wrong thing.
Where AI and extensions fit
If you run AI features or agents on Fusion data, add them to the regression pack. A quarterly update can change data structures or APIs that your prompts, integrations or agents rely on. Our AI risk register lists "quarterly Oracle update breaks integration" as a standing risk with a regression-suite mitigation for exactly this reason.
Common mistakes
- Starting when the test pod is updated. By then, half the window is gone.
- No owner per product area. Readiness notes go unread.
- Testing on stale data. Real data finds real problems.
- Late SRs. Oracle needs time to respond; raise them on the day you find the issue.
- Forgetting integrations. Interfaces, reports and extensions depend on data structures and APIs, so they are more exposed to change than standard screens.
How Egisedge helps
Egisedge Technologies is an Oracle Partner working across Oracle Fusion Cloud ERP, HCM and SCM, Oracle Integration Cloud and Oracle APEX. We follow a documented quarterly update regression playbook and a SIT and UAT approach for Fusion. With teams covering GCC, UK/Europe, US and Australia/NZ working hours from our offices in India, we can run testing inside your update window.
Want help setting up a repeatable quarterly update process? Email info@egisedge.com or book a demo with our team.
Frequently asked questions
How often does Oracle update Fusion Cloud Applications?
Oracle Fusion Cloud Applications receive a quarterly update. Non-production environments are normally updated first, with production following a couple of weeks later, which gives customers a window to test.
What should be tested after an Oracle Fusion quarterly update?
Test critical end-to-end business flows, integrations, reports, personalisations and extensions, security, and any new features you plan to enable. Prioritise by business risk and by what the Readiness notes say has changed.
Can a customer skip an Oracle Fusion quarterly update?
Quarterly updates are mandatory in Oracle's SaaS model. Customers can plan around the schedule, but not opt out, so a repeatable regression process is essential.
How long should quarterly update testing take?
With a manual regression pack it often takes one to two weeks of effort. With an automated pack for the stable, high-volume flows, most of the cycle can be run in days, leaving people to focus on new features and defects.
Talk to Egisedge about ERP Financials
Tell us where you are and we'll reply within one working day with next steps.