Official guidance checked October 4, 2026

Oracle describes Release Preview as a way to test existing business workflows. Access, preparation and timing depend on the account. Consult the linked current guidance and your account’s upgrade information before scheduling the review.

Begin with consequences

List the processes that would cause the greatest disruption if they changed unexpectedly. These may include taking an order, receiving goods, billing a customer, reconciling a payment or completing a period-end task. Choose examples that cross team and system boundaries.

For each process, name a business owner who can judge the outcome. Technical testing can prove that a script runs; the process owner needs to establish that the right transaction, approval and reporting result was produced.

A practical readiness sequence

  1. 01

    Agree the account context

    Confirm the target release, available test environment, relevant features and dependencies. Oracle notes that some data or features require preparation and that Release Preview performance can differ from production.

  2. 02

    Define expected results

    Choose representative records and write the expected outcome before execution. Include relevant values, statuses, permissions and reports, rather than a simple “works” checkbox.

  3. 03

    Run ordinary and exceptional work

    Test a straightforward case, a correction, a rejected approval and a connection failure where applicable. Record what happened and what evidence supports the result.

  4. 04

    Triage issues with owners

    Describe the impact, reproduction steps and affected scope. Assign investigation and retesting to named people, with a decision on any accepted limitation.

  5. 05

    Prepare the operating team

    Explain the changes people will notice, update task instructions and establish where questions go. Review the first live outcomes with the business owner.

Three test records worth writing

  • Order through to reporting

    Follow one order through fulfillment, invoicing and the report used to assess the transaction. Check a split shipment or correction if it is common in your business.

  • An integration that fails safely

    Interrupt a representative exchange in a test environment. Confirm the alert, retry behavior and reconciliation, including how the team prevents a second transaction from being created.

  • An AI-assisted step with review

    If you are evaluating an AI capability, define the information it may use, the output a person must check and the conditions for declining the suggestion. Include a case with incomplete or ambiguous data.

Make the acceptance decision visible

Keep a short readiness record: critical workflows tested, unresolved issues, accepted limitations, user communications and accountable decision owners. The goal is a decision supported by evidence, not a larger test spreadsheet.

Separate the vendor’s account-upgrade arrangements from your own deployment and adoption decisions. Your team controls how it prepares custom changes, trains users and validates outcomes; do not assume that an internal go/no-go meeting changes Oracle’s upgrade schedule.

Testing scope and Release Preview

Should we copy production data into every test?

Use the approved environment and data-handling process. Select representative data that is appropriate for the test and protect access; do not move sensitive information casually.

What happens to Release Preview after the upgrade?

Oracle says access ends when the source account is upgraded, and inactivity can also lead to removal. Check current account guidance and retain your test evidence outside a temporary test account.