Oracle ships four updates a year, and they arrive whether or not your team is ready. The difference between the shops that stay calm and the ones that scramble every quarter isn't luck or headcount — it's a repeatable routine. Build it once and each release becomes a checklist instead of a fire drill.
The rhythm Oracle sets
The cadence is predictable: quarterly updates on the familiar A/B/C/D pattern, with smaller maintenance packs in between. Each quarterly update brings a mix of new features — many of them opt-in — some mandatory changes, and the ongoing Redwood progression. Knowing that mix exists is the first step to handling it calmly.
Step 1 — Read the right documents
Start with Oracle's What's New and readiness material, filtered to your modules. As you read, sort every change into one of two buckets: opt-in features you choose to adopt, and mandatory changes (including UI and security deltas) you have to absorb. Mixing those two up is where most readiness work goes wrong.
Step 2 — Triage impact
Tag each relevant change: ignore, evaluate, must-test, or must-act. Give extra weight to security privilege changes and Redwood page changes — they're the quiet ones that cause loud problems in production.
Step 3 — Regression test what matters
Maintain a core regression pack covering your business-critical flows: hire, payroll run, absence, approvals, and your key reports and integrations. Run it in the upgraded non-production pod during the preview window, before the change reaches users.
You don't need to test everything — you need to test what hurts if it fails. A focused regression pack that gets finished every quarter beats an exhaustive one that never does.
Step 4 — Decide opt-ins deliberately
A feature being available doesn't mean enabling it this quarter. Schedule adoption around business events — don't switch on a new flow the week before payroll close or open enrolment.
Step 5 — Communicate
Tell affected users what's changing, especially anything visual, before it hits production. A two-line heads-up prevents a hundred support tickets.
The regression pack is real work the first quarter and almost free every quarter after. Add cases as your configuration grows, and readiness compounds into something the team barely has to think about.
Security privilege changes and Redwood page conversions cause more production surprises than anything else. Put both at the top of every readiness review and you'll avoid most quarter-end fire drills.
Key takeaways
- Oracle's four annual updates are predictable — make readiness a standing process.
- Separate opt-in features from mandatory and security or UI changes.
- Maintain a focused, reusable regression pack for business-critical flows.
- Watch security privilege and Redwood changes most closely, and communicate early.
Readiness isn't about testing harder — it's about testing the same right things every quarter. Once the routine exists, release season stops being something your team dreads and becomes just another well-run cycle.