Oracle applies its monthly update to your test environments on the first Friday of the month and to production on the third Friday, during the first daily maintenance at or after 22:00 UTC. The email announcing it arrives the last Friday of the previous month, a week before test is updated, and the What's New sits on Oracle's Release Readiness site. That gives you about two weeks to read what is coming, test it on your own applications, and decide whether production takes it or skips it. Most teams spend those two weeks reading nothing and testing by feel. This is the other way.
The calendar you are working against
| When | What happens | What you do |
|---|---|---|
| Last Friday of the month | Oracle emails Service Administrators about the next update | Open the What's New on the Release Readiness site; mark what applies to you |
| First Friday | Test environments are updated at the first daily maintenance at or after 22:00 UTC; the Help Center documentation is updated | Run the baseline before the maintenance window, the compare after it |
| First to second week | Two weeks of test on the new version | Explain every difference, or certify it as expected; retest what the notes touch |
| Wednesday before the third Friday | Last sensible day to decide | IT Go or Skip, then business sign-off |
| Third Friday | Production is updated | Post-patch run on production; file the package |
Skipping is a real option, not a failure. With the EPM Automate skipUpdate command a Service Administrator can skip up to three consecutive monthly updates on an environment, with a comment that records why. Two things keep it honest: weekly and emergency patches still arrive during a skipped month, and if test and production drift three versions apart, snapshot migration between them is no longer supported. Skip production, and you have a deadline to catch up.
Read the What's New in three passes
The document is long because it covers every business process. Read it for your own, in this order.
First pass: changes in behavior and announcements. This is the short section nobody reads and the one that breaks things. Defaults that change, features retired, minimum versions for Smart View or browsers, REST API versions deprecated. Anything here that names something you use goes on the test list for this month, whether or not it looks important.
Second pass: new features, split into on-by-default and opt-in. A feature you have to enable cannot break you this month; note it for the roadmap. A feature that arrives switched on can change what a planner sees on Monday. Those go on the test list too, and into the note you send users.
Third pass: fixed defects. Read these looking for your own workarounds. If Oracle fixed the thing you scripted around in March, this is the month to remove the script, test without it, and retire it, not the month to discover both are now running.
What to test every month, whatever the notes say
A fixed regression set per application, run against the same data before and after the update, so that what you compare is the update and nothing else. For a Planning application: the forms planners open every day (open, enter, save, check the saved value), the rules that run at forecast and close (run on a known slice and compare the results, not the log), the integrations and data loads, the reports and report bursts, one Smart View ad hoc retrieval, one user per security role, and the run time of your slowest rule and slowest form. FCCS adds a consolidation on a closed period and a journal through its workflow. ARCS adds a period open, a reconciliation through preparer and reviewer, and a transaction-matching run if you use it.
The point of the baseline is that you are looking for differences, not for failures. A rule that completes with a different result on the same data is the finding; a rule that fails is just the easy case. Every difference gets one of two outcomes: explained by an item in the What's New, or certified as acceptable by someone whose name goes on the record.
What to test because of this month's notes
Map the first-pass items to artifacts. A change to the calculation engine means rerun the rules and compare results. A change to the reporting engine means rerun the reports and bursts and look at the output, not the completion status. A change to Data Integration means run the pipelines end to end. A REST API or EPM Automate change means run your administration scripts, including the ones that only run at month end. Security and single sign-on changes mean a login per role. If an item does not map to anything you run, write that down; it is the evidence that you considered it.
When to skip
Skip production when any of these is true: a close or forecast cycle spans the third Friday and the update touches something that cycle uses; a difference found on test cannot be explained or certified before the decision date; or an Oracle service request is open on something the update changes. Skip for a reason you can write in the comment field, because that comment is the record. Do not skip because nobody had time to test; that is the case for testing earlier, not for skipping, and three months later the catch-up update is bigger and harder to read.
The decision record
The monthly update is a change to a system in SOX scope that you did not initiate, so the auditor's question is how you controlled it. The record is four things: the What's New with each applicable item marked and the ones that do not apply marked as such; the baseline-versus-post-patch compare with every difference explained or certified; the Go or Skip decision with who made it and when, plus the business sign-off; and for a skip, the skipUpdate request with its comment. Keep them together, by month, where someone can find March in September.
What to do this month
- Put the three dates in the team calendar: the email, the test update, the production update, with a decision meeting the Wednesday before the third Friday.
- Write the fixed regression set for one application and run it once now, before any update, to create the baseline.
- Read the current What's New in the three passes and mark every item: applies, does not apply, needs enabling.
- Agree who says Go or Skip for IT and who signs off for the business, and where the record is kept.
EPM TestMate runs this cycle as a 15-step run book: the What's New review, the baseline, the post-patch compare with visual differences, the sign-offs and the audit package, on Oracle's calendar. About EPM TestMate.