# Oracle EBS Upgrade from 12.1.3 to 12.2: Downtime Window Estimator

> Source: https://netray.co/tools/oracle-ebs-12-1-to-12-2-upgrade-downtime-estimator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Turn the timings from your mock upgrade into a production cutover window for a 12.1.3 to 12.2.x upgrade, with contingency and a database-size sweep.

## Category

oracle

## Erp

Oracle E-Business Suite

## Audience

- Apps DBA
- EBS technical architect
- Upgrade project manager

## Tool

**Kind:** calculator

**Inputs:**

#### Database size

**Key:** db_gb

**Type:** number

**Default:** 800

**Min:** 50

**Step:** 50

**Unit:** GB

**Help:** Allocated size of the production database you will upgrade.

#### 12.2.0 upgrade driver hours per 500 GB (from your test run)

**Key:** rate

**Type:** number

**Default:** 10

**Min:** 0

**Step:** 0.5

**Unit:** h

**Help:** Measure this on a mock upgrade of a production-sized copy. The default is an assumption, not an Oracle figure.

#### Workers / CPU versus the test run

**Key:** ratio

**Type:** select

**Default:** 1

**Options:**

##### Same hardware as test (x1.0)

**Value:** 1

##### About 2x the CPU of the test (x0.65)

**Value:** 0.65

##### About half the CPU of the test (x1.6)

**Value:** 1.6

**Help:** Driver time does not scale linearly with CPU because some jobs run serially.

#### Online Patching Enablement hours

**Key:** enable_h

**Type:** number

**Default:** 4

**Min:** 0

**Step:** 0.5

**Unit:** h

#### 12.2.x RUP apply hours

**Key:** rup_h

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 0.5

**Unit:** h

**Help:** Applying the target Release Update Pack (for example 12.2.10 or later) with adop.

#### Latest AD/TXK delta and pre-upgrade patches

**Key:** delta_h

**Type:** number

**Default:** 3

**Min:** 0

**Step:** 0.5

**Unit:** h

#### Database upgrade in the same window

**Key:** dbup_h

**Type:** number

**Default:** 0

**Min:** 0

**Step:** 0.5

**Unit:** h

**Help:** Enter 0 if the database was upgraded to a 12.2-certified release in an earlier outage.

#### Post-steps (AutoConfig, custom code deploy, smoke test)

**Key:** post_h

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 0.5

**Unit:** h

#### Contingency

**Key:** contingency

**Type:** slider

**Default:** 25

**Min:** 0

**Max:** 100

**Step:** 5

**Unit:** %

**Outputs:**

#### 12.2.0 upgrade driver time

**Key:** driver_hours

**Expr:** db_gb / 500 * rate * ratio

**Format:** hours

**Description:** Scaled from your measured rate by data volume and the hardware ratio.

#### Technical hours (no contingency)

**Key:** technical_hours

**Expr:** driver_hours + enable_h + rup_h + delta_h + dbup_h + post_h

**Format:** hours

#### Planned cutover window

**Key:** total_window_hours

**Expr:** technical_hours * (1 + contingency / 100)

**Format:** hours

**Primary:** true

**Description:** Technical hours plus contingency. This is the outage to book with the business.

#### Window in days

**Key:** window_days

**Expr:** total_window_hours / 24

**Format:** decimal

#### Driver share of technical time

**Key:** driver_share

**Expr:** driver_hours / technical_hours * 100

**Format:** percent

**Chart:**

#### Cutover window vs database size

**Type:** line

**X:** db_gb

**From:** 200

**To:** 5000

**Steps:** 25

**Series:**

- total_window_hours
- technical_hours

**Disclaimer:** All hour defaults are planning assumptions, not Oracle numbers. Replace them with timings from at least two mock upgrades on a production-sized copy.

## Content

**Intro:** This estimator converts the timings from your own mock upgrade into a production cutover window for an Oracle E-Business Suite 12.1.3 to 12.2.x upgrade. It scales the 12.2.0 upgrade driver by database size and hardware, adds the fixed steps, and applies contingency.

**Sections:**

#### How to use it

**Body:** Run a full mock upgrade on a copy of production at full size, on hardware as close to production as you can get. Record the elapsed time of the 12.2.0 upgrade driver, then divide by your database size in units of 500 GB and enter the result as the rate. Enter the other step timings from the same run log. If production has more or fewer CPUs than the test server, pick the matching worker ratio. Set contingency based on how many clean rehearsals you have: 25 to 40 percent after one rehearsal, lower once two runs agree within a few percent. The primary output is the outage to agree with the business; the chart shows how sensitive it is to data volume.

**Bullets:**

- Driver hours = database GB / 500 x measured rate x hardware ratio
- Technical hours = driver + enablement + RUP + AD/TXK delta + database upgrade + post-steps
- Window = technical hours x (1 + contingency / 100)

#### Where the time goes in a 12.1.3 to 12.2 upgrade

**Body:** The Oracle E-Business Suite Upgrade Guide, Release 12.0 and 12.1 to 12.2 describes the path: prepare the 12.1.3 system and database, lay down the 12.2 file system with Rapid Install, apply the latest AD and TXK prerequisites, run the 12.2.0 upgrade driver, run Online Patching Enablement, then apply the latest 12.2 Release Update Pack and its AD/TXK delta through adop. The upgrade driver is the step that grows with transaction volume, because it runs data upgrade scripts across large product tables. Rapid Install and the new 12.2 file system can be prepared before the outage, so they are not in the window. Purging obsolete data (concurrent requests, workflow runtime, interface tables) before the upgrade shortens the driver run.

#### Worked example

**Body:** An 800 GB database with a measured rate of 10 hours per 500 GB on identical hardware gives 16 driver hours. Adding 4 hours of enablement, 6 for the RUP, 3 for AD/TXK and prerequisites, 0 for the database (upgraded earlier) and 6 for post-steps gives 35 technical hours. With 25 percent contingency the window is about 43.75 hours, or 1.8 days, so a long weekend outage is realistic. If production has roughly twice the CPU of the test server, the driver falls to about 10.4 hours and the window to about 36.75 hours. At 3 TB with the same rate the window grows to about 99 hours, which is when teams look at purging and database upgrade timing first.

#### Common mistakes

**Body:** The most common error is timing a mock upgrade on a subset or a smaller clone and scaling it by hand; driver timings must come from a full-size copy. Other mistakes: skipping the second rehearsal Oracle recommends, so contingency hides an untested step; forgetting custom code deployment and the Online Patching Readiness fixes that must be in place before enablement; leaving the database upgrade in the same window when it could have been done in an earlier outage; and not counting time to gather statistics and validate invalid objects after the driver.

**Cta:** If you want your team to ask questions of your EBS data and upgrade logs in plain English on your own servers, we can set up a private AI layer next to 12.2.

**Faq:**

#### What are the main steps to upgrade Oracle EBS from 12.1.3 to 12.2?

**Answer:** Per the Oracle upgrade guide: prepare the 12.1.3 system and a 12.2-certified database, install the 12.2 file system with Rapid Install, apply the latest AD and TXK prerequisites, run the 12.2.0 upgrade driver, run Online Patching Enablement, then apply the target 12.2.x RUP with adop and finish with post-upgrade tasks such as AutoConfig and custom code deployment.

#### Can I upgrade from 12.1.3 straight to 12.2.10 or later?

**Answer:** Yes, the path goes through the 12.2.0 upgrade driver and then you apply the latest RUP directly, such as 12.2.10 or a later update pack, rather than every intermediate release. Check the readme of the target RUP for its AD/TXK and database prerequisites, since those set extra steps inside the window.

#### Why does the upgrade driver take so long on large databases?

**Answer:** The 12.2.0 driver runs data upgrade scripts that touch large transactional tables in financials, order management, inventory and other products. Elapsed time follows data volume and parallel workers more than code size. Purging old data and gathering current statistics before the run are the usual ways to shorten it.

#### How many test upgrades should we run?

**Answer:** Oracle recommends multiple test upgrades. Plan at least two full rehearsals on a production-sized copy: the first to build the run book and fix errors, the second to confirm timings. Use the second run's timings in this calculator and lower contingency only when runs agree.

## Search terms

oracle ebs upgrade from 12.1.3 to 12.2, oracle ebs upgrade from 12.1.3 to 12.2 steps, oracle ebs 12.1 to 12.2 upgrade, oracle ebs upgrade from 12.1.3 to 12.2.10, oracle ebs 12.2 upgrade, ebs 12.2 upgrade downtime, ebs 12.2 upgrade driver runtime

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json