Oracle EBS 12.2 Upgrade Readiness Checklist

0%

0 of 31 items complete

11 critical items still open - these are the highest-risk gaps.

Download checklist:

Scope and support

Confirm your current release and patch level and the supported upgrade path to 12.2 in Oracle documentationCRITICALCheck the Oracle support dates for your current release and set a latest-start dateCRITICALDecide upgrade only, or upgrade plus functional change, and write the scope downConfirm licenses and any extended support cost in the budgetName a business owner for each module in scopeAgree testing resources from the business, not only from ITCRITICAL

Technology stack

Check certified combinations of database, operating system, browser and Java for your target 12.2 patch levelCRITICALPlan the database upgrade or move needed for your target releaseCheck disk space for the dual file system that online patching usesCRITICALPlan the Oracle WebLogic Server based application tier and its sizingReview load balancer, SSL and single sign-on integrations for compatibilityReview backup and restore capacity for repeated test upgrades

Customizations and integrations

Inventory custom objects, forms, reports, workflows and personalizationsCRITICALRun the Online Patching Readiness reports and list objects that need remediationCRITICALCheck custom tables, views, synonyms and PL/SQL packages for online patching rulesList all integrations, file interfaces, database links and third-party toolsRetire custom code that no longer has usersDecide who owns each remediation item and when it is dueCheck that Forms and OAF customizations are compatible with the target stack

Testing and data

Plan at least one full-size test upgrade on a production copyCRITICALRecord upgrade run time for each test so cutover planning has real numbersCRITICALBuild a regression test set for each module, including period close and interfacesPrepare test data and test users that match production rolesPlan performance testing for key concurrent programs and reportsAgree defect triage and sign-off rules

Cutover and operations

Pick a cutover window outside period close and agree the freeze periodCRITICALWrite a rollback plan and test restoring the pre-upgrade backupCRITICALTrain DBAs on adop phases and on running a patching cycleUpdate monitoring, backup jobs and runbooks for the 12.2 file system layoutPlan user communication and training for new screens or behaviorPlan a hypercare period with named support people

Unchecked critical items are blockers for a project start date. Convert each into an owner and a due date in the project plan.

Discuss custom code review for your upgrade

An optional conversation on analyzing custom EBS code on your own hardware before the upgrade.

Optional. The tool and every export work without this. No spam.

How to use this checklist

Work through the groups with your DBA, functional leads and the owner of customizations. Mark an item only when you have evidence, such as a certified combination from Oracle documentation or a readiness report output. The unchecked critical items become the first month of the project plan. Export the result to PDF and attach it to your business case, so the budget conversation uses facts.

What changes with 12.2

Release 12.2 uses online patching, so most patches are applied to a copy of the application file system and database objects while users stay on the running system. The tool that drives this is adop, and it uses edition-based redefinition in the database. For you, this means more disk, new DBA routines, and a requirement that custom database objects follow online patching rules. The upgrade effort is often driven more by custom code remediation than by the standard upgrade scripts.

Dual run and patch file systems
Edition-based redefinition in the database
adop replaces the older patching routine
Custom objects need readiness review

Common planning mistakes

The usual mistakes are starting too late against a support date, counting only technical time and forgetting business testing, and running one test upgrade on a small copy that hides real run times. Another is leaving custom code review to the last month. Start with the inventory and the readiness reports, because they tell you how large the remediation work is. Then size the project from your own test upgrade timings, not from generic estimates.

Frequently Asked Questions

How long does an EBS 12.2 upgrade take?

It depends on module count, data size and the amount of custom code. Projects commonly run several months from planning to go-live. Your own test upgrade timings and remediation inventory are better predictors than any generic figure, so measure them early.

What is online patching in 12.2?

It is a patching method where patches are applied to a second copy of the file system and to a new database edition while users keep working. A short cutover switches to the patched copy, which reduces downtime for normal patching cycles.

Do I need to change my custom code?

Often yes. Custom objects in the database must follow online patching rules, for example around editioned objects. Oracle provides readiness reports that list issues. Run them early so you can size remediation before you set the go-live date.

Where do I check support dates?

Use Oracle's Lifetime Support Policy documents and your support contract, since dates and terms can change. This checklist does not state dates for that reason. Confirm the current dates, then use the planning calculator on this site to test your timeline.

If custom code analysis is your bottleneck, we can discuss using on-premises AI tooling to read and summarize your custom PL/SQL and report definitions, with your engineers reviewing every output.

Talk to an Expert Explore More Free Tools

Related Tools

Oracle

More Oracle tools

See all