THE BIG PICTURE THE R12.1.

3 UPGRADE OVERVIEW MIKE SWING - TRUTEK

The Big Picture shows at a high level the tasks and challenges of the R12.1.3 upgrade. The Big Picture describes how to get started, how to motivate business users to upgrade, and whether to re-implement or upgrade. It covers the upgrade steps, both functional and technical, and understanding these steps helps all team members work toward a better upgrade. The Upgrade Steps are broken down into four major sections: 1. 2. 3. 4. Plan to Upgrade Prepare to Upgrade Perform the Upgrade Finish the Upgrade

The Upgrade is an Iterative Process

The following diagram illustrates the iterative process of upgrading Oracle Applications. The further you deviate from a vanilla install of Oracle Applications, the greater the chance that you will experience a problem that Oracle cant replicate and therefore will never be regression tested. Oracle does extensive regression testing based on vanilla installs and the related upgrades to ensure that most upgrade paths are free of errors. The upgrade can take a few iterations to resolve new issues. Each patch can introduce new code that can use customizations to fail and existing processes to become obsolete. Because of these changes, it is up to your organization to Evolve as new functionality is introduced, Manage the changes and align the business processes, and Optimize the upgrade.

Manage-Evolve-Optimize
Manage Managing the upgrade consists of setting expectations for the Steering Committee, including time, money, and perceived benefits, and communicating these expectations across the upgrade team. Providing training to the superusers, users and technical staff is also part of the upgrade management responsibilities. One of the primary responsibilities of the Upgrade Project Manager is to align the business processes with Oracle Applications R12.1 and to control the subsequent scope creep. The project manager should also encourage the Steering Committee to allow the developers to migrate the customizations to a Service Oriented Architecture (SOA) when possible. Another goal of the Upgrade Project should be to implement comprehensive business reporting. While this may not be part of the upgrade, comprehensive reporting will improve the effectiveness of any release of Oracle Applications. Evolve To evolve, we must change and adapt, so as to not become extinct. In order to evolve, we must incorporate R12.1 new functionality and seek to replace customizations with existing R12 new functionality. Business process gap analysis should be a continuous process if you hope to evolve. Optimize One of the most important goals of the optimize phase of the upgrade is to reduce the downtime of the upgrade. Optimization affects post-upgrade tasks and should improve uptime and improve the reporting capabilities, while improving the response time and reducing costs. Optimization improves the visibility and productivity of the overall system. Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process

The iterative process of improving the business processes is dependent on improving the technology foundation, aligning the technology with business processes, creating or modifying customizations and finally, we have set the stage to improve the business process and realize cost savings. When Are We Ready? Are We There Yet? We are ready when business processes align with Oracle Applications, customizations support the business processes, users are familiar with the new functionality and have been trained, and testing indicates all processes are functioning. The following diagram illustrates four test upgrade iterations executed before no new issues are identified. The first iteration is a test iteration, to copy the software from the DVDs to the hard drives of the test machine, install the new Release 12.1 software with Rapid Install (aka rapidwiz), and execute the upgrade. We recommend for this first iteration installing and then upgrading Oracles Vision instance, as it provides a seeded database that will allow technical team members to experience the different issues that occur with the installation and upgrade, and gives functional users an environment with all features implemented for experimenting with new functionality. Even with the best planning, this iteration usually has errors. See the little r12.1.2 Upgrade Guide for a complete walkthrough of this upgrade, with solutions to many of the issues that occur. The next iteration, labeled the 1st Pass, is the first iteration that includes customizations based on functional gap analysis. The 1st Pass also includes solutions, called fixes. These are the fixes for some or all of the issues identified in the Test iteration. This is the 1st iteration that is visible to the developers and functional analysts The second pass uses the customizations from the 1st Pass and any new customizations, plus fixes from the 1st Pass all added to the objects that are installed by rapidwiz. When there are no New Fixes, use the timings from the upgrade to predict the downtime foe upgrade weekend.

When there are No New Issues, use the timings from the performance upgrade to measure downtimes and more accurately plan for the production upgrade.

The R12.1 upgrade is a functional upgrade

Understand functional new features
Integrated Financials The new bank account and disbursement models facilitate the payment of invoices and other payables out of different operating units, from an appropriate bank account, and with the appropriate intercompany handling. Intercompany processing is dramatically revised by enhancements in both Financials intercompany management and Supply Chain Managements Enhanced Drop Shipments. Rather than a GL only system, Financials now links into Receivables and Payables to generate matching and tied documents (configurable though Bill Presentment) and a new reconciliation scheme. Related SCM products provide transfer pricing modeling and enforcement, inventory consignment (at subsidiaries or otherwise), and tracking of profit in inventory. Subledger Architecture A Set of Books (Release 11i) becomes a Ledger with its own Ledger Set, in Release 12. SLA will return the same accounting as the earlier accounting engine did. If the MO:Operating Unit was defined in Release 11i, after the upgrade MO:Operating Unit will be set the same.

Key R12 Modules Modules and new features that are key to the operation of R12 include: Approvals Management, (AME), User Management (UMX), Sub Ledger Accounting (SLA), Governance and Risk (GRC), Multiple Organization Access Control and Advanced Global Intercompany processing.

Benefits include the ne Subledger Accounting m ew model, XML publishing ap pplied to repo orts, additiona al DBI portlets and pages AR-AP nett s, ting, and gros margin ana ss alytics in AR. er V Subledge Currency Views Accountin for subledg transactio at the even in a standar manner wi a single ac ng ger ons nt rd ith ccounting eng gine allows us to provide multiple accounting represen m ntations for a single event. . se multaneously a accounted for an increment to inventory for your US GAAP or t y A purchas can be sim IAS/IFRS accounting, and as a debi to the P&L for your natio complian accountin S it onal nce ng. The accou unting entity involved can maintain mul i ltiple ledgers, each comply , ying with a di ifferent set of f accountin principles we call them accounting methods, an of course, the transacti ng m g nd, , ions and ledge ers can be val lued and deno ominated in d different curre encies. You can n generate currency view of a ledge at the subledger transacti now ws er ion, general ledger transac ction, general le edger balance, or consolida , ation workpla levels. ace Multi-Or Access Con rg ntrol Multi-Org Access Con g ntrol (MOAC) enables com ) mpanies with a Shared Serv vices operatin model to ng efficiently process busi y iness transact tions by allow wing them to a access, process and report on data for an n unlimited number of op perating units within a sing applicatio responsibi s gle ons ility. This inc creases the ters, as users and processes no longer ha to switch applications s ave productivity of Shared Service Cent p ansactions for multiple ope erating units a a time. at responsibilities when processing tra urity and access privileges are still main ntained using s security profi that now support a list of iles Data secu operating units.

The MOAC feature primarily uses two features namely 'Fine-Grained Access control' and 'Application Context'. Combined known as Virtual Private Database (VPD). Fine-grained access control allows you to build applications that enforce security policies at a low level of granularity (such rows/columns in table). Application Context provides a way to define, set, and access attributes that an application can use to enforce access control specifically, fine-grained access control . Please note Multi-Org Access Control replaces usage of CLIENT_INFO(Org Context) function in MultiOrg Architecture. Steps to Setup MOAC (from My Oracle Support Note 414003.1): Define Operating Units(Optional) (Using form function 'Define Organizations') Define Security Profile (Using form function 'Define Global Security Profile') Assign MO: Security Profile

If both 'MO: Security Profile' and 'MO: Operating Unit' are defined at a responsibility level then 'MO: Operating Unit' will be ignored and 'MO: Security Profile' will be effective. MO:Operating Unit is preserved through the upgrade, so if it was set in previous release, it will be set in 12. If you dont want to implement MOAC features in Release 12, no additional setups are required. Responsibility-level profile options will apply to all OUs of the security profile. Other new features include improvements in Multiple Reporting Currencies, E-Business Tax and the Payments modules.

Gap Analysis
Functional users of Oracle Applications may have a different view of success than the managers and technical staff. The functional staff may declare upgrade success even though from the management or technical point of view that upgrade may not have been a complete success. This is because the functional, technical and managerial success criteria may not be the same. Functional users should expect to gauge their success on their ability to accurately determine the gap analysis, and work with developers to make sure the customizations appropriately address the functional gap. The following diagram illustrates the functional view of success.

Gap Analysis
Gap analysis requires superusers/functional analysts that understand the new features of R12.1 and understand the existing customizations. Gap analysis is the process of aligning the business process with Oracle Applications. The gap can be resolved by changing the business process to use the Oracle Applications process or providing a customization to fill the gap between the existing business process and the functionality that Oracle Applications provides. Further investigate the functional gap by examining the following: Reasons for the change and areas that benefit from new functionality Functionality that is temporarily disabled or has been made obsolete Changes to user interfaces, terminology or concepts, and menu options

Customizations and Modifications can help align the business with Oracle Applications.

Pre-upgrade Functional Validation Scripts

Download the following patches, for the appropriate modules, as needed, and apply using the steps in the following section: Patch 5259121 GL R12.FIN.A.UI.XB.3: ASM PRE/POST DIAGNOSIS PROGRAM OUTPUT EDITS Patch 4685497 GL 11I UPGRADE TO R12: OPTIONAL PRE-UPGRADE PROGRAMS IN 11I Patch 5233248 SLA PRE-UPGRADE PROGRAM MODIFICATIONS FOR 11I Patch 4914492 ICX: R12 PRE-UPGRADE FILES ON TOP OF 11.5.10 Patch 5760729 Project Costing 11i:APL:UNPROCESSED SUPPLIER COST REPORT- R12 PREUPGRADE Patch 7303029 Oracle E-Business Suite Consolidated Upgrade Patch 1 (CUP1) for R12.1.1 Patch 8706842 Assets Consolidated Patch for 12.1.1 September 2009 Patch 9100984 Public Sector accounting - may not be needed

Functional PreUpgrade Steps

If you use General Ledger with a large number of posted journals and the glrsgup2.sql job in AD_TASK_TIMING table takes a long time to run, you can use the General Ledger Journal Entries PreUpgrade program to reduce downtime. It upgrades posted General Ledger journal entries before the planned downtime, leaving only unposted journals and newly posted journals to upgrade during downtime. The GL Journals Entries Pre-Upgrade consists of the Program - Prepare Posted Journals Before Upgrade concurrent program, which you run from the Standard Request Submission form. Since this program is resource-intensive, it should be scheduled to run during non-peak times, such as evenings or weekends. It can, however, be terminated at any point, and, when restarted, it resumes from the point where it left off. Even after the program is complete, you can run it again at a later time. It processes only journal entries posted after the last time it was run. In order to install the functionality necessary to run the Program Prepare Posted Journals Before Upgrade concurrent program, apply patch 4685497.
If you want to reconcile journal lines entered prior to the upgrade, or view and reverse reconciliations performed prior to the upgrade, then run the Upgrade Journal Lines for Reconciliation Concurrent Program. Run the Accounting Setup Manager Pre-Update Diagnosis Report Concurrent Program prior to the upgrade, and the Accounting Setup Manager Post-Update Diagnosis Report after the upgrade in the Standard Request Submission form in a General Ledger Responsibility.

2.09.01 Import expense reports into Accounts Payable

The Expense Report Import Concurrent Program is obsolete in Release 12.1. Submit this program before running the Release 12.1 upgrade steps. Running this step allows the iExpense interface records to be imported into Payables. Review and fix any rejections, and re-run the Expense Report Import Concurrent Program.

2.10.01

Import All Invoices from Payables Open Interface

In Release 12, Global Descriptive Flexfields (GDF) are obsolete Values stored in GDFs need to be moved into tax and payment tables. Run the Concurrent Program: Import All Invoices from Payables Open Interface
2.10.02 Confirm or cancel all un-confirmed Payment Batches

The Release 11i batch payment method is obsolete and the new payment batch method requires that old batches be cancelled or confirmed. Verify there are no payment batches that are in-process. Procurement Apply the pre-upgrade Patch 4914492 to insert the Release 12 Data Migration menu item into the eContent Manager menu. This will allow the exception report to be run or run the pre-upgrade. Use the eContent Manager menu to access the Release 12 Data Migration menu to run the pre-upgrade in advance of the Release 12.1 upgrade.

Projects
2.12.01 Complete distribution, transfer, and tieback of expense reports

If expense reports are created using Pre-approved Expenditure Entry or import unaccounted expense reports, run the following Concurrent Programs: PRC: Distribute Expense Report Costs PRC: Interface Expense Reports to Payables Expense Report Import ( run from Payables Responsibility) PRC: Tieback Expense Reports from Payables

Verify all transactions are successfully interfaced with no exceptions. From My Oracle Support Knowledge Document 409206.1, Required Pre-Upgrade Steps for Oracle Projects, Release 12: Run this SQL script that identifies expense reports created in Oracle Projects that have not been interfaced to Oracle Payables for all operating units. Apply Patch 5760729 to your Release 11i APPL_TOP. This patch copies the pa120u05.sql file to your Release 11i $PA_TOP/patch/115/sql directory. Run this script to verify that all transactions have been interfaced to Oracle Payables for all operating units.

 If you are unable to complete this processing prior to the upgrade, you can use the Invoice Workbench to manually enter the un-interfaced expense reports in Oracle Payables. 2.12.02 Complete transfer and tieback of cost, cross charge revenue Run the following Concurrent Programs for each operating unit in Projects and Grants Accounting: Journal Import: Complete Journal Import in General Ledger for all project journal sources PRC: Tieback Labor Costs from General Ledger PRC: Tieback Usage Cost from General Ledger PRC: Tieback Total Burdened Cost from GL PRC: Tieback Cross Charge Distributions from GL PRC: Tieback Revenue from General Ledger

From My Oracle Support Knowledge Document 409206.1, Required Pre-Upgrade Tasks for Oracle Projects, Release 12: Complete non-recoverable tax adjustment processing (conditional)

Applies to 11i release level: All TUMS Step Key: To be determined at a later date If you adjusted expenditure items that represent supplier invoices or expense reports in Oracle Projects that have related non-recoverable tax, complete the following tasks for each operating unit: In Oracle Projects, run the PRC: Interface Supplier Invoice Adjustment Costs to Payables Concurrent Program. In Oracle Payables, validate the adjusted invoices. In Oracle Payables, account the adjusted invoices. In Oracle Projects, run the PRC: Interface Supplier Costs Concurrent Program.

It is recommended that your Projects application specialist ensure that these transactions are successfully processed and that no exceptions remain prior to the upgrade. To assist you with this process, Oracle Projects has provided a script that identifies supplier invoice and expense report adjustments created in Oracle Projects that have not been interfaced to Oracle Payables for all operating units. You can apply Patch 5760729 to your Release 11i APPL_TOP. This patch copies the pa120u05.sql file to your Release 11i $PA_TOP/patch/115/sql directory. Verify that all transactions have been interfaced to Oracle Payables for all operating units. Use either of the EXC: Transaction Exception Details Concurrent Programs to identify transactions in Oracle Payables that have not been interfaced to Oracle Projects. If you are unable to complete this processing prior to the upgrade, you can use pre-approved batches in Oracle Projects to create negative miscellaneous transactions to balance the adjustments. Upgrade Historical Supplier Cost Transactions in Oracle Projects

If you need to upgrade additional supplier cost transactions in Oracle Projects, you can run the UPG: Upgrade Transaction Attributes Concurrent Program. This Concurrent Program updates all appropriate supplier cost attributes on transactions in Oracle Projects for the specified parameters."

Assessment - Technical and Functional

In order to better plan for the upgrade, assessments can help estimate the impact and scope of work. There are four major types of upgrade assessments: Functional align the business with Oracle Applications Technical review patches, tech stack versions, the upgrade path, and performance issues Customization review customizations to ensure that they are adequately documented, and to find customizations that can be eliminated as a result of new functionality introduced with an upgrade Architecture review hardware and capacity requiremetns

TruTek detailed assessments typically have three phases: Audit, Investigate, and Report: The Audit phase of the functional assessment identifies the current issues, documents the AS IS processes and documents the TO BE processes. The Investigate phase of a functional assessment is more detailed than the Audit phase and includes functional application tuning and a review of setups, since they can affect performance. The primary goal of the investigate phase is to improve functional processes and to review user defined functions and fast formulas, if present. The Report phase of the assessment defines the issues, recommends solutions and summarizes process improvements.

Functional Upgrade Assessment The Functional Upgrade Assessment documents the modules in use and modules that are to be implemented as part of the upgrade. This type of assessment identifies business issues and prioritizes business goals to clearly define and set measurable performance targets and prioritize goals. The Functional Upgrade Assessment should identify the gaps between the current release and the latest certified R12 release to determine the functional, platform, network and operating system gaps. Functional experts must map custom processes from Release 11i to R12. Because of new functionality in R12, existing custom processes may be replaced by new functionality in R12. This assessment should review application reporting and interface transition issues, and evaluate management controls required, including timing, resources and training issues. Finally, this assessment should recommend an overall upgrade approach (upgrade vs. re-implementation, the appropriate upgrade path, etc.) Technical Upgrade Assessment The technical assessment investigates future capacity requirements, tech stack version compatibility, and patch levels, including CPUs, current issues from log files, current unresolved service requests, and potential issues with the R12.1 upgrade. Customization Assessment Start by identifying all customizations. In some environments the customizations arent well documented and some customizations may have been lost due to previous patching. Check-in all customizations into configuration management. Customizations are easier to customize if you can find them and have some version control. Determine the customizations that are replaced by new R12 functionality. This requires an analyst that knows the new functionality of R12 and understands the customizations. Finally, determine the customizations that need to be fixed or added to the upgrade to preserve or extend the process alignment. Architecture Assessment The Architecture Assessment investigates the implementation of more advanced configurations, depending on the requirements, including the following: Shared Disk SAN, NAS, NFS Shared disk is required for RAC, for each node to access the same disks. This is also required for a Shared Apps Tier and distributed AD. Shared disks come in three primary flavors: SAN, NAS and NFS. RAC

Many companies require continuous database operations, and Real Application Clusters (RAC) is a possible solution. RAC can also be used for companies that need to scale quickly. With RAC, you can add another server to the cluster relatively quickly. The performance issue with RAC is pinging, not the classic disk block pings, but cache block pings across the inter-connect. While cache pings are roughly 100 times faster than disk pings, large volumes of pings can create database waits, queuing, and degraded performance. The best method to resolve this issue is to partition the application, so the data is mostly used in the cache of one server. RAC is not free and the maintenance of RAC is not free. The necessary hardware environment will have shared disks, probably a SAN; backups and clones must use RMAN. Shared Application Tier with Distributed Processing If there are four applications servers connected to shared disks and we run adpatch in distributed mode, each application server can be assigned a range of workers that run patch jobs in parallel, while each server accesses the same files on shared disk. For example, Start 5 workers on each machine, by running the following command on each application server: adpatch localworkers=5 workers=20 The following diagram illustrates four application servers, each running 5 adpatch workers. This allows the patch to be applied simultaneously on each application server, and to run the patch more quickly because the workers are run in parallel.

Without shared disk, each patch must be applied separately on each application server. The shared disk will have a path to the software that includes the <CONTEXT_NAME>, the combination of machine name and instance name. Parallel Concurrent Processing Parallel concurrent processing allows distribution of concurrent managers across multiple nodes. Benefits are better: performance, availability and scalability (load balancing).

With parallel concurrent processing implemented with GSM, the Internal Concurrent Manager (ICM) tries to assign valid nodes for concurrent managers and other service instances. When one node is not available, the managers that are defined with PCP fail over to another machine.

Most users dont know how to restart a failed job. Therefore, the failure of a concurrent manager that is not set up with PCP will terminate running jobs. Users will see that their jobs have failed and call to request assistance in restarting the job. With PCP, when a failure occurs, the system can use PCP to automatically restart the concurrent managers that are defined to fail over to another machine. This avoids calls to the help desk and the system administrator. Hardware Assessment If the upgrade plan includes buying new hardware, consider migrating from the current 32-bit platform to a 64-bit platform. Reasons to migrate to a 64-bit environment include: Release 11i doesnt support running the Application Tier on a 64-bit hardware platform; however, Release 12 does support 64-bit architectures for the Application Tier. Release R12 supports running the database on a 64-bit operating system, in a split or mixed architecture There are five hardware platforms supported for Release 12, and all of the platforms support a 64 bit version There are less memory restrictions on a 64-bit machine because of additional addressable memory Because of more addressable memory, more users can be supported on each Application Tier MRP and other programs run much more quickly in a 64-bit database

Reporting
One way of dealing with Discoverer, which puts considerable pressure on the database in terms of performance, is to move it off of the E-Business Suite environment entirely. One way to accomplish this would be to purchase Oracles Active Data Guard, which would provide a constantly updated disaster

recovery environment. Oracle is currently working to make Active Data Guard allow not only automatic failover, but also to allow read access for reporting. Oracle plans to provide E-Business Suite reporting access for a subset of concurrent programs that do not need to update data. Currently a standby database sits, unused, unless a failure occurs. Another option is to create a reporting instance that is updated by a nightly clone. Many companies use this option. Data Guard is an interesting option, worth evaluating, once it is stabilized and the reporting capability for the Applications is fleshed out. Many companies tried to use Data Guard with EBS, but they found it has too many bugs in RDBMS Version 11gR1.

1) Plan to Upgrade
Re-implement vs Upgrade
The decision to re-implement versus upgrade is simple do everything possible to upgrade. Dont reimplement unless you explore all alternatives and find none work. If you have a relatively uncomplicated environment, and there are no fundamental configuration changes you need to make, then upgrade. Most of this guide is about these straightforward upgrades. This section is for if you need to make significant changes and have considered reimplementation. If there are complications or you want to change fundamental implementation-time setups in Oracle, you will evaluate each change and see whether you can transform your instance prior to upgrading, so that you can use the standard upgrade from Oracle. But first, note that since Oracle offers no way to change these fundamental configurations, they often suggest reimplementation, without regard for the implications in the customers environment. The customer usually looks for alternatives from Oracle Partner independent software vendors, system integrators, and consultants. When Oracle first released R12, they guided customers to reimplement if the customer needed to change any obsolete fundamental setup configurations or to consolidate multiple production instances. Oracles R12 documentation conceded that reimplementation is more difficult, complex, and resource intensive compared to an upgrade. Reimplementation Consequences Here are some reimplementation consequences in the areas of implementation, data history, disposition of the Release 11i instance, reporting, and business intelligence: You have to implement a fresh installation of R12. Enter all setups from scratch or with the tools and utilities mentioned in the section below on reimplementation tools. You are on your own to get your open transactions and historical data from the legacy Release 11i instance into R12. Oracle Support cant help if the data is incompatible once it is in the R12 environment, or if it breaks the EBS database integrity constraints. You have to decide what history to load and what to do with the remainder. You will need a policy for each different type of data. The usual choices include most recent and current fiscal year, current year, and only open transactions. Even though data conversion tools these days are powerful, and programmers in the global data centers are inexpensive, dealing with data history will be a significant part of your reimplementation project. It will cost money and require several iterations to get it right. You will need to keep the Release 11i instance in legacy mode. Some call this a sunset instance. It must be frozen and restricted to read-only access. You will not have a single global instance. You have to keep it available for external regulatory data retention purposes as well as operational analyses. You will devise reporting mechanisms to span the legacy Release 11i and operational R12 instances. That includes translations, reconciliations, mappings, and external reporting environments. If you have a business intelligence environment or data warehouse, you will make need to make changes to incorporate the frozen legacy Release 11i and operational R12 environments.

Transform and Upgrade An Oracle Partner, eprentise, offers software to transform fundamental setups in Oracle EBS such as the Chart Of Accounts (Accounting Flexfield), calendar, organizations, all other key flexfields, and sets of books. eprentise software can be used to eliminate or fix corrupt data. You can consolidate multiple instances. You can remove all data related to sold or inactive business units. If you want to make these major changes, use the eprentise software to transform your Release 11i instance so it can be upgraded. Consolidate your Release 11i instances so you can have a single upgrade process and get to a single R12 instance. You can use eprentise software to: Transform the fundamental setups of your Release 11i instance(s) to reflect how you need your business to run now. Adjust or re-do any unsatisfactory or obsolete setups. Consolidate Release 11i instances as required so there is only one instance to upgrade. Close seemingly huge functional alignment gaps between Release 11i and R12. Minimize the downtime for the upgrade.

Then you run the Oracle upgrade. Heres a diagram that describes the process.
Upgrade = eprentise Transformation + Oracle Upgrade
Business process changes Business structure changes, incl. OUs COA changes Clean data, compliant with standards Shared service centers Instance consolidation 11i 11i 11i Obsolete Obsolete Obsolete Setups Setups Setups eprentise Transformation Instance you always wished for, AND its upgradable. Use it as long as you want, until you need the valued-added R12 features. Single Global Instance Lowest future cost structure Highest business value

11i Upgradable

Oracle 11i R12 Upgrade

R12

11i Data 11i Data 11i Data

No data loss

11i Data
Transformed

No data loss

R12 Data
Transformed & R12 formats

Path from one or more EBS 11i instances to a single global R12 instance

Upgrade enables R12 Features Centralized accounting architecture Global tax engine New ledger and ledger set architecture Multi-org access control features Centralized banking model Advanced global intercompany system

Oracles Re-implementation Tools Oracle provides a number of tools that can help with re-implementation: iSetup - can migrate functional setups from one E-Business Suite instance to another. During migration, setups can be extracted selectively using filters on setup attributes. Extracted data can be optionally transformed before loading into a target instance.

fndload see the paper, Customization Survival Guide: How to Use E-Business Utilities to Migrate Your Custom Code, by Brad Simmons and Donna Campbell. FNDLOAD can be used to: transfer Request Groups, move Concurrent Programs, and download and upload Forms Personalizations migrate Key FlexFields, Descriptive Flexfields, Responsibilities and almost every other FND entity transfer value set definitions exp/imp Oracles export and import utility. Datapump - For RDBMS Version 10g and 11g you can use DataPumps expdp and impdp utility DataLoad - DataLoad will load data into any application and contains extra functionality for loading data and setup into Oracle E-Business Suite. A number of loading technologies are provided so that the most appropriate approach can be chosen for the target application. DataLoad will load data via an application's forms, which may be browser-based Self Service forms or core/professional forms, or data can be loaded directly into a database. SQL Plus - SQL*Plus, the primary interface to the Oracle Database server, provides a powerful yet easy-to-use environment for querying, defining, and controlling data. SQL*Plus delivers a full implementation of Oracle SQL and PL/SQL, along with a rich set of extensions. Open Interfaces - Open Interfaces refers to a programming interface, usually a database table, that automates the execution of Oracle APIs. You can use the Oracle Integration Repository (iRep) to view all the interfaces in the E-Business Suite in one place. Oracle Application Management Pack (AMP) and Application Change Management Pack (ACP) are additional cost toolsets provided by Oracle that provide a framework around tools like iSetup, but also offer new functionality, including the ability to document your customizations.

Upgrade Benefits: Improved Tools Simplify the Process

Oracle provides a number of tools that simplify upgrading the Applications, including: Real Application Testing, Database Replay, and Maintenance Wizard. Real Application Testing Oracle Database 11g introduced Database Replay and SQL Performance Analyzer as part of the Real Application Testing option to enable businesses to identify issues with system changes before production deployment The Oracle Real Application Testing option includes two solutions to test the effect of system changes on real-world applications, Database Replay and SQL Performance Analyzer (SPA). Database Replay enables you to effectively test system changes in test environments by replaying a full production workload on the test system, to help determine the overall impact of the change. With the SPA, you can assess the impact of system changes on SQL performance by identifying any variation in SQL executions plans and performance statistics resulting from the change. Database Replay Database Replay makes it possible to capture a workload on a production system with negligible performance overhead, and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload The Database Replay process can be broken down into the four steps described below:

1. Workload Capture When workload capture is enabled, all external client requests directed to the Oracle server are stored into compact capture files on the database host file system, while incurring negligible overhead. These files contain all relevant information about the call needed for replay, such as SQL text, bind values, wall clock time, SCN, etc. The workload capture start and end time, as well as criteria for targeted capture (e.g., by user, service, action, etc.) can be specified by the user. The workload captured on Oracle Database Release 9.2.0.8 and higher can be replayed on an Oracle Database 11g release. Workload capture and replay in shared-server environment is also supported. 2. Workload Processing Once the workload has been captured, the information in the capture files has to be processed, preferably on the test system. This processing transforms the captured data and creates all necessary metadata needed for replaying the workload. 3. Workload Replay Before performing workload replay, the test system has the intended system change applied and database restored to the point in time before the capture started, using various mechanisms such as RMAN backups, Oracle Database 11g Snapshot Standby, Datapump export/import, etc. The replay can be configured appropriately to re-map connection strings, database links, and directory objects to that of the test system. Once replay is initiated, a special client program called the replay client replays the workload from the processed files. It submits calls to the database with the exact same timing and concurrency as in the capture system and puts the exact same load on the system as seen in the production environment. The replay driver automatically re-maps physical locators and preserves sequence numbers or GUIDS during replay. The replay driver is client-agnostic and uses a scalable multi-threaded architecture with support for client estimation and running on multiple hosts. There are various options that are available to control the behavior of the replay, such as to scale up or down the think and login times, and maintain commit synchronization. These are useful for throttling the user call rate to the database. 4. Analysis and Reporting Extensive reports that encompass both high-level summary and detailed drill-down information in terms of errors, performance and data divergence are provided to help understand how the replay fared in comparison to capture or other replays. Maintenance Wizard Maintenance Wizard guides you through the Applications upgrade and code line maintenance process. It helps you reduce upgrade tasks by dynamically filtering the necessary steps based on criteria it obtains from your Applications environment. The result is a set of step-by-step instructions of exactly what you need to do to complete your specific upgrade, including any critical patches that your system may require. It can also automatically execute many of the tasks for you, so as to reduce the possibility of errors or accidental omission of vital tasks. The Maintenance Wizard contains the following:

Upgrade Assistant: 11i to 12 [version 2.x] Applications Database Upgrade Assistant: 8i, 9i to 10g [version 2.x] Maintenance Pack Assistant: 11i to 11.5.10 [version 1.x] Upgrade Assistant: 10.7, 11.0.3 to 11.5.10 [version 1.x]

With the Maintenance Wizard, you can: Automate Patching and Provisioning Automate Diagnostics and Tuning with the Diagnostics and Tuning Packs for OEM Automate Change and Configuration Management with the Change Management Pack for OEM

Technical Upgrade Paths - Release 12.1 Upgrade Paths

Path A DB 9iR2, 10gR2 Apps 11.5.7 or 11.5.8 DB Upgrade & Apps Upgrade need to be completed during the same window. Path B If the DB already at 11gR2, Apps 11.5.9.2 or 11.5.10.2 Only upgrade the Apps Stack Path C Upgrade the DB & Apps in different phases downtime

Technical Upgrade Flow

No

Start

11.5.9.2 Or 11.5.10.2

Upgrade to 11.5.10.2

This guide assumes we start with 11.5.10.2

No
Recommended: Convert to OATM

OATM Enabled

Yes No
Recommended: Option to Upgrade DB To 11.2.0;1

Yes

Perform steps in Chapter 1 and Chapter 2 Except DB Migration

DB at 10.2.0.4 or 11.1.0.7 or 11.2.0.1

Perform Steps 1 and 2 In Chapter 3, stop at Step 3 Migrating the DB Downtime starts here DB at 10.2.0.4 or 11.1.0.7 or 11.2.0.1

Yes
Finish Chapter 3 Perform the Upgrade Apply 12.1.1 Patch Finish the Upgrade Finish Chapter 4 Post Upgrade Steps On-line Help Patch Then Apply 12.1.2 Patch Downtime ends here

Yes

All DB patches are applied

Yes

No
OATM Enabled?

No
Upgrade DB to 10.2.0.4, 11.1.0.7 or 11.2.0.1 (Recommended 11.2.0.1)

Yes
Required: Convert to OATM

No
Apply DB Patches

Upgrade Finished

This guide assumes we start with Release 11.5.10.2, but the upgrade paths below show how to upgrade from earlier versions of Release 11i. Implement OATM and upgrade the database to the highest compatible level.

Release 12.1 Upgrade Paths

Initial Release Interim Release Final Release R12 Patch 4440000 4440000 11.0, 11.5.1 - 11.5.6 Release 11.5.10 CU2 Release 12.0.0 11.5.7. 11.5.8, 11.5.9* or 11.5.10* 11.5.7, 11.5.8, 11.5.9.2, 11.5.10.2 11.5.9*, 11.5.10* 12.1.1 12.1.3 Release 12.1 Release 12.1.2 6678700 7303033 Release 12.0.4 6394500 Release 12.0.0

includes CU1 and CU2 (consolidated update) The highlighted section indicates that a direct upgrade path exists from Release 11.5.7 to Release 12.0.0. The database version must be compatible with the old and new versions of Oracle Applications as shown above. If upgrading from a release prior to 11.5.7, the upgrade path may require an interim upgrade to Release 11.5.10.2. Because of the significant downtime required to upgrade from Release 11.0 to Release 12.1, it may be more feasible to first upgrade to Release 11.5.10.2 and then some time later upgrade to Release 12.1. This requires the functional users to learn Release 11.5.10.2, and perform all the testing for another upgrade. The amount of work necessary to perform two rounds of system acceptance testing may justify another day or two of downtime, so that the upgrade from Release 11.0 to Release 12.1 can be completed in one longer period of downtime. The bubbles in the diagram below show the primary upgrade paths between versions of Oracle Applications. Most EBS customers are running Release 11.5.10.2. In order to upgrade to Release 12.1.3, first upgrade to 12.1.1 and then apply the 12.1.2 patch. Notice that Release 11.0 customers must first upgrade to Release 11.5.10.2 before upgrading to 12.1.1 and then 12.1.2.

The follow diagram from E-Busin wing ness Suite Tec chnology Stack Roadmap (April 2010) Now Available, e Steven Ch han, Oracle Corporation, sh hows Oracles roadmap to Fusion: s

Paths for Oracle Applicatio Versions on Upgrade P

Databas Upgrade Requirem se e ments

Release 12.1 12.0 11.5.10.2 2 11.5.9.2 11.5.7 Certi ified Database Versions on Solaris n 10gR 11gR2 and the 64 bit v R2, versions 10gR 11gR2 and the 64 bit v R2, versions 10gR or 11gR2 a the 64 bit versions R2 and t 10gR and the 64 bit versions R2 4 8.1.7 9.0.1 9.2, an 9.2-64 bit 7, nd

There is no database version that is certified with both Release 11.5.7 and Release 12.1. Therefore, we cant do the database upgrade separately from the application upgrade. The database installed by the 11.5.10.2 RapidWiz is Version 9.2.0.6. This database version does not support Daylight Savings Time (DST). Therefore, we have two choices: Upgrade the database to Version 9.2.0.8, which has support for DST, and then upgrade to Version 11.2.0.1, or Upgrade the database to Version 10.2.0.3, using the database Oracle Home provided with the 12.0.4 EBS install, and then upgrade to 11.2.0.1.

Since we require an interim step, and we already have the 12.0.4 DVDs staged, it is easier to use the 10.2.0.3 Oracle Home than to download the 9.2.0.8 patch and apply all the E-Business Suite-specific database patches.

Database Upgrade Steps

No Start
Apps Version At Least 11.5.10.2 DB Version >= 9.2.0.8 7 DSTP4 DB Version At least 9.2.0.6 This guide assumes we start with EBS Release 11.5.10.2 and 9.2.0.6 of the Database. We upgrade to 10.2.0.3 as an interim step to 11.2.0.1, because this Home comes with the 1204 Install The OH that comes with the RapidWiz install has all the necessary database patches already applied. Version 11.2.0.1 has since been certified, so we upgrade to that

Yes
Upgrade Database Directly to 11.1.0.7, Use the OH from the 12.1.1 RapidWiz Install, Then Upgrade to 11.2.0.1 Or Upgrade Database to 11.2.0.1

Yes
Upgrade Database to 10.2.0.3 Use the OH from the 12.0.4 RapidWiz

Upgrade Finished

Post DB Upgrade Steps For R12.1 Fix Korean lexers Fun adgrants.sql Grant to CTXSYS Validate Workflow Run AutoConfig Gather Stats for SYS Grants and Synonyms Fix Syn for Trade Mgmt

Fix Daylight Saving Time Patch 4

Upgrade Database Directly to 11.1.0.7, Use the OH from the 12.1.1 RapidWiz Install, Then Upgrade to 11.2.0.1 Or Upgrade Database to 11.2.0.1

Upgrade Timeframe
Typically, the upgrade to Release 12.1 from 11.5.10.2 will require a 3 to 4 day weekend for downtime, starting at the close of business on Wednesday or Thursday, for a 3 or 4 day downtime window. Four day weekends usually are the best time to upgrade because the extra day of downtime has less affect on the business. The first weekend of the month is usually not a good weekend, because month-end close just occurred and month-end close processing probably hasnt finished. Similarly, the last weekend of the month, functional analysts are getting ready to close the books. The middle two weeks of the month present the best opportunities. In 2010, Memorial Day is observed on a Monday, July 4th is on a Monday, Labor Day is on Monday, Columbus Day is on a Monday, Thanksgiving obviously in on Thursday with

business operations on-hold on Friday during the upgrade. Christmas and New Years are horrible times to do the upgrade, primarily because of mandatory year-end processing. The database upgrade generally takes 8 to 12 hours. If the database upgrade is complete prior to upgrade weekend, it is possible to do a 2 day applications upgrade from Release 11.5.10.2. The database upgrade can be completed independently of the Release 12.1 applications upgrade. If possible, the database upgrade should be completed weeks or months before the Release 12.1.1 Upgrade. The Applications portion of the upgrade will take 14 to 32 hours depending on the speed of the server and the amount of data to upgrade. Testing will take 8-12 hours, after the upgrade is complete. Backups can be time consuming and recovery should be tested before the upgrade weekend.

Upgrade Downtime with the Database Upgrade

If you need to upgrade your database in the downtime window, youll need to add an extra day to your schedule. This will require the downtime to begin Thursday night.

Upgrade Downtime Without the Database Upgrade

Upgrade Weekend
This is a typical plan for upgrade weekend and shows the approximate times for each phase. Start the Upgrade on Friday Afternoon Clone Upgrade instance from PROD 2 hours (In many environments that can take 16 hours or longer. Get a SAN!) Plan to Upgrade Perform Category 1 Steps 4 hours These steps can be completed in PROD in advance of upgrade weekend Prepare to Upgrade Perform Category 2 Steps 6 hours These steps can be completed in PROD in advance of upgrade weekend Perform the Upgrade Perform Category 3 Steps 18 hours Finish the Upgrade Perform Category 4 Steps 8 hours Customizations 4 hours Setups 4 hours iSupplier / SSL 4 hours

Perform Category 5 Steps 4 hours Developer Testing 2 hours Backup the Upgraded instance 2 hours User Acceptance Testing 8 hours Restore the Backup if Testing was destructive

The Patching Process

Upgrade patch types

The technical view of success depends on applying the correct patches in the right order, installing and configuring new hardware, and implementing customizations that satisfy the functional gap requirements. Patches Getting the right list of patches in the right order for compatible hardware is one of the more important tasks. the little r12.1.2 upgrade guide and the little r12.1.2 project plan have a list of all the patches, in the order they should be applied . The following section explains the new upgrade patch types that have been introduced since Release 11.5.10.2. Upgrade Patch Types - CPCs, UPCs, CPUs, PSUs See My Oracle Support Knowledge Document 557869.1, EBS: R12 Oracle Financials Critical Patches for links to the latest Critical Patch Collections (CPCs) and Upgrade Patch Collections (UPCs).

A new type of patch collection was introduced in July, 2009 called Patch Set Updates (PSUs). See My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs. Oracle also releases quarterly Critical Patch Upgrades (CPUs) that should be applied as they become available. Critical Patch Collections (CPCs) - Oracle Financials Release 12.0 Critical Patch Collections (CPC) are consolidated critical patches that all Release 12.0 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Oracle Payables and Receivables, and include dependent fixes for Subledger Accounting, Tax, and Payments. Advantages of applying CPCs over one-off fixes and RUPs are as follows: CPCs are fully quality assured against current RUP levels. Individual one-off patches are not. CPCs are consolidated and only contain critical patches that apply to broad customer usages. They are smaller in footprint and therefore much easier to apply and uptake than RUPs. CPC Readmes have detailed business and functional information about the fixes included. Customers can leverage the Readmes to determine impact and testing required for specific process flows and software components involved.

If a CPC becomes available after you complete your upgrade, you should research the CPC and consider implementing it at some point to your environment. Release 12.1 Financials Upgrade Patch Collection (UPC) - The latest Release 12.1 Financials Upgrade Patch Collection (UPC) contains Release 12.1 Upgrade patches for the following products: Payables Receivables Tax Subledger Accounting Intercompany Financials for India

The Release 12.1 Financials Upgrade Patch Collection is created specifically for customers who have yet to upgrade their product environment to Release 12.1. This UPC contains improvements to the upgrade process to Release 12.1. These fixes are not required to be applied to environments that have already been upgraded to Release 12.1. These patches are critical to the upgrade process and it is essential that they are applied to your Applications Code Tree (APPL_TOP) prior to running the R12.1 Upgrade Driver. You should look for the latest UPC on My Oracle Support and add it to your upgrade plan. Critical Patch Updates (CPUs) - A Critical Patch Update (CPU) is a collection of patches that address multiple security vulnerabilities. It also includes non-security fixes that are required (because of interdependencies) by those security patches. Critical Patch Updates are cumulative, except as noted, but each advisory describes only the security fixes added since the previous Critical Patch Update. Thus, prior

Critical Patch Update Advisories should be reviewed for information regarding earlier accumulated security fixes. Critical Patch Upgrades (CPUs) are released quarterly. When you upgrade to Release 12.1, you should plan to apply the latest available CPU. You should look for the latest CPU on My Oracle Support and add it to your upgrade plan. We recommend applying the CPU patches on another weekend following the upgrade. However, if time allows on the R12.1 upgrade weekend, it is possible to apply the latest CPU. Patch Set Updates (PSUs) - Patch Set Updates (PSUs) are database patches. The PSU strategy is to deliver low-risk, high value content that has a limited scope and is thoroughly tested. According to My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU): Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October. The Patch Set Updates include a Cluster Ready Services (CRS) patch. Like the Database server patch, the CRS patch is a well-tested, low-risk patch of recommended fixes. The Patching Process The patching process can be time consuming, because of the time it takes to perform backups, restores and clones. Applications patches are generally not reversible; a restore from a backup is usually the only viable mechanism to fix a problem with the system after a patch has been applied. Therefore, before patching, backup the environment. Cloning is another process that can be time consuming. The beginning of every upgrade should start with a clone from the production system to the new upgrade hardware. If cloning takes 16 hours, it will be a long weekend. Hopefully, your clone will only take two to four hours to complete.

There are a significant amount of patches to be applied especially if you have not maintained your patch levels. For HRMS customers, there are three additional My Oracle Support documents that youll want to closely review (R11.5.10.2 11499.1 , R12.0.x 386434.1 and R12.1.x 858794.1). You should track My Oracle Support Note: 883202.1 carefully because Oracle updates it frequently.

The Testing Process

The testing process extensively uses backups, restores and clones to recreate test environments from upgraded instances.

Testing is dependent on cloning. If cloning is a difficult or time consuming tasks, then testing will be difficult and potentially inaccurate. Customizations Customizations that exist in the current system need to be documented. Upgrade developers should define steps to re-apply the customizations in the new Release 12.1 system. Some customizations, such as reports, may more easily be created in XML Publisher rather than Oracle Reports. Developers may need additional training in new technologies. Technology components that may have customizations: Workflow Forms OA Framework - JDeveloper Reports XML Publisher

Tasks to be included in the development upgrade plan: Remove old obsolete code before the upgrade Check invalid objects for source of old code

Identify columns that become obsolete during the upgrade Create a script to remove obsolete columns

Developers may need to enhance their skills with OA Framework and XML Publisher to stay current with the technology changes in Release 12.

How to Upgrade Customizations

Customizations are sometimes referred to as CEMILIs, the software framework for Customizations, Extensions, Modifications, Internationalizations, Localizations, and Integration. There are 19 classes of extensions and Oracle has published guidelines for developing and implementing custom extensions to Oracle Applications. The CEMLI Upgrade includes determining the technical impact of Oracle E-Business Suite Release 12.1 on CEMLIs, upgrading CEMLIs to the new technology stack, and retrofitting CEMLIs for compatibility and usability with Oracle E-Business Suite Release 12.1. The steps to the CEMLI Upgrade are: Identify all customizations Check-in all customizations into configuration management Determine customizations that are replaced by new R12.1 functionality Re-Code customizations Prepare Customization Upgrade Implementation Plan Prepare Customization Configuration Management

Modifications are defined as customizations that survive upgrades.. Personalizations are an example of a modification. Extensions include reports and interfaces that are not replaced by new code from the upgrade, because these extensions are custom and not named the same as any seeded object. Extensions and Modifications usually survive an upgrade, but changes to underlying table and objects will certainly affect this custom code. Customizations are defined as custom code objects that will be replaced by new objects during the upgrade. Custom workflows are a good example of code that will usually be replaced during an upgrade. Personalizations are an example of modifications that should not be replaced or altered by the upgrade. The diagram below illustrates the relationship of customizations, modifications and extensions to the upgrade.

Obsolete components in R12

Another consideration as you plan your upgrade is that several technology components that were used by the Applications are now obsolete. Your developers will need to determine if any of the following components are currently being used, whether their functionality is needed in Release 12, and then determine how to work without them. This may require additional customizations.

mod_plsql
If you have custom development on mod_plsql, you should migrate your Web pages to Oracle Application Framework. Oracle Reports Server Reports Convert the reports to Oracle XML Publisher. Convert the reports to Oracle Application Framework. Run the reports through the Concurrent Manager.

Oracle Graphics Integrations with Oracle Forms Convert both the form and the chart to an Oracle Application Framework-based application. Convert the chart to an Oracle Application Framework-based page that can be launched from Oracle Forms. AK Mode If OA Framework-based pages have personalizations in the AK repository, then during the upgrade from Release 11i to Release 12, all custom personalizations will automatically be migrated from AK to MDS, if the AK and MDS repositories are in the same database instance. If AK/ICX Web Inquiries were used in Release 11i, use the Oracle Application Framework Search feature to recreate personalizable search regions The following chart shows the current plans for support. If you are still running on Release 11.0.3, the fact that even Sustaining Support has an end date January 2009 should be particularly important/alarming to you. If you are running releases prior to Release 11.5.10.2, you should be concerned that Oracle does not offer Extended Support. From our perspective, the biggest issue with staying on these earlier releases is that without Premium Support, you may not be able to stay current on the security patches provided by Critical Patch Updates (CPU/PSUs). But theres another issue well talk later in the guide about upgrade paths the further behind you are, the more complicated your upgrade path will be.

Oracle E-Business Suite Support

2) Prepare to Upgrade
Practice Testing
The test manager should review the test scripts with the superusers. Periodically, after clones or large patches, the superusers should run the test scripts to ensure they are efficient at executing them. Testing resources should be dedicated to the upgrade projects. Upgrade testers should be the most knowledgeable users and the most likely to find issues. Sometimes its not possible to get the best personnel to be dedicated to the upgrade project. In this case, it is OK to borrow them, but they should not be your primary testing resources.

Optimize the Upgrade Reduce Downtime

Use TUMS to eliminate the tasks that are not relevant for your system Use Shared file system and Distributed AD for Multi-node application tiers. Estimate tablespace sizes for test upgrade using Note: 399362.1

Maintenance Wizard
The Maintenance Wizard provides a step-by-step, graphical user interface for performing upgrade tasks, and consolidates instructions from multiple sources to present a comprehensive upgrade picture. It reduces upgrade tasks by filtering out those that do not apply to you (using TUMS) and indicates critical patches that your system requires. The maintenance wizard can automatically execute upgrade tasks for you If possible, complete the following prior to the R12.1 upgrade weekend: Upgrade the Database to 11.2.0.1 Migrate to OATM Install the R12.1 software Run pre-upgrade Downtime Reducing steps Run pre-upgrade verification steps

Upgrade by Request
You can, if you choose, upgrade the most important data - the last fiscal year or other periods - during the upgrade downtime, and migrate the rest of the historical data later for some of the E-Business Suite modules. The products that use Upgrade by Request are: Customer Relationship Management (CRM) Financials and Procurement Projects

Su upply Chain Management M

See My O Oracle Suppor Knowledge Document 604893.1, R12 FAQ for the SLA Upgrad SLA Prert 2: e de: Upgrade, Post-Upgrad and Hot P de, Patch. cal ade on t. roducts, only SLA data wi be upgrade y ill ed, A historic data upgra depends o the product For some pr and for ot thers, both tra ansactions and accounting data will be u d upgraded. Implemen ntation is a tw step proces wo ss: 1. Set the range of periods of t historical data to be up o the pgraded before the R12 Up e pgrade and run the n pr re-upgrade co oncurrent prog grams 2. R the SLA post upgrade ( Run p (upgrade by r request option after the R12 upgrade n) Review A Appendix G in Oracles R12 Upgrade M n Manual for mo details ore

Default Upgrade Periods - M P Minimum D Downtime U Upgrade

During th upgrade, ex he xisting accoun nting data from the subledg (AR, AP GL) is upgr m gers P, raded into the new Oracle Su ubledger Acco ounting (SLA data model. A) . By defaul the upgrade migrates da for the curr fiscal yea and the per lt, e ata rent ar riods of the pr revious fiscal year l that are ne ecessary to en nsure there ar at least six p re periods in the upgrade (if t upgrade is performed i the e the in first half o the fiscal year). of y

Install t SLA Pr the re-Upgrade Concurre Program e ent m

To change the default number of periods of histo data to be upgraded: e n oric e When you iustall th R12.1 upg n he grade filesyste the follow em, wing file is created from xl la931.zip on Disk8 8:

/apps/apps_st/appl/xla/ /12.0.0/patch/ /115/driver/xl la5584908.drv e la5584908.dr using adpa rv atch, and the h hotpatch optio on. Install the driver file xl Subm the SLA Pr mit re-Upgrade C Concurrent Pro ogram

Run the SLA Pree -Upgrade C Concurrent Program t

When sub bmitting this program, ente the followin parameters: p er ng Migrate all Set of Books: M ts

Yes (SLA Pre-Upgrade program updates the periods in all Sets of Books) or No (SLA Pre-Upgrade program updates the periods that belong to the selected Set of Books).

Set of Books: Set of Books to be upgraded where you have selected to upgrade one Set of Books. Start Date: Date used to determine the first period to be upgraded. The first period is the first period the Start Date falls in; it does not have to be the starting date of the first period. The start date can be changed to a date earlier than the 6 months minimum, but not shortened to less than the default.

You may need to run the SLA Pre-Upgrade program if you are using Oracle General Ledger and at least one of the following subledgers: Assets Cost Management Payables Receivables Purchasing Project Accounting

This optional program allows you to change the default number of periods of historic data to be upgraded. The Release 12 SLA Pre-Upgrade program considers the following modules: Payables Receivables Purchasing Project Accounting Inventory/Costing Fixed Assets (Fixed Assets uses GL periods)

The SLA Pre-Upgrade program uses the GL_PERIOD_STATUSES table. The MIGRATION_STATUS_CODE column indicates the status of the record in the GL_PERIOD_STATUSES table: P = Pending Upgrade - The system is preparing to upgrade the accounting periods in this table that have a status P. The accounting transactions in these corresponding accounting periods will be upgraded from Release 11i to Release 12 by the Subledger products (i.e, AR, AP etc). U = Upgraded - The accounting records have been upgraded from Release 11i to Release 12 N = New - Only used by GL <blank> = These records do not meet any of the criterion mentioned and will therefore not be considered in the upgrade. The parameters for the SLA Pre-Upgrade program are:

Upgrade all Sets of Books, or The specific Set of Books and the Start Date.Check the profile option for
Upgrade by Request, SLA: Initial Date for Historical Upgrade; if this is not set, this indicates that all periods were upgraded. You can confirm by checking that no new XLA tables were created to process the data. During the R12 upgrade, all periods to be upgraded are first marked as gl_period_statuses.migration_status_code=P, respective records are updated from the subledger (i.e., AP, AR, FA etc.) accounting tables to SLA's accounting tables, and finally the periods are marked as upgraded, for example, gl_period_statuses.migration_status_code=U. select * from gl_period_statuses where migration_status_code='P'; This SQL should NOT return any rows.

The Release 12 SLA Pre-Upgrade Program tags the accounting periods in the GL_PERIOD_STATUSES table with P for pending upgrade when the records are for AP, AR, Project Accounting, FA, Inventory/Costing and PO products only. No other products are considered by this pre-upgrade program

Adjustment Periods
The accounting period under consideration must be a NON-Adjustment period. Adjustment periods are not upgraded because the upgrade that was designed by the Subledger Product teams (AP, AR etc) caters to the transactions created by those products and posted to GL. Typically, the Subledger Product teams do not generate transactions that post into adjusting periods. Given that adjusting periods overlap dates with non-adjusting periods, the logic for mapping a transaction into an accounting period is to take the GL date and figure out which nonadjusting period it falls into.

The period has a status of closed, open, future, and never opened. Note: Never opened is only applicable to the Inventory/Costing product.

SLA Post Upgrade Processing

Upgrade by Request If you do not perform a complete upgrade of the accounting data, Oracle Subledger Accounting allows you to perform an additional upgrade of the data by running the SLA post-upgrade process Concurrent Program whenever the missing data is required.

3) Perform the Upgrade

Tune the Upgrade Optimal number of workers
Performing the Upgrade should not be iterative. The production upgrade should work predictably What happens if the upgrade fails? Do you fire the consultants? Whose fault was it? Usually, the fault lies with inadequate testing, not enough communication about changes to the system, or possibly one of the steps on the checklist was missed. If the Upgrade fails, you havent practiced enough. Look at failed upgrades as forced practice. There are many reasons the upgrade can fail, the trick is to be able to identify the issue and prepare for another upgrade weekend. If the failed upgrade was on the second weekend of the month, the third weekend may also be a good upgrade weekend, assuming everyone is confident that all the issues were resolved. Usually, it takes a month to regain confidence and proceed with the next upgrade weekend. Management should be aware that a secondary upgrade weekend should be part of the overall upgrade plan.

Tune the Upgrade

Gather statistics before upgrade Use Gather Auto option of 10g Record timing for each step during the test upgrade Drop MRC schema before R12 upgrade Add the PL/SQL no compile option in R12 upgrade driver to save time during upgrade Add extension plsql_no compile yes line in the upgrade driver file to enable PL/SQL no compile option

Optimal Number of Workers

Our upgrade machines use 4 CPUs. With timing data from more than 30 upgrades, the times were measured and the number of workers was varied from 2 to 16. The fastest upgrade times were for 3 workers. Set the number of workers to CPUs 1 For a machine with 16 CPUs, then, we would use 15 workers. My reasoning for this rule is as follows: Patches run jobs that have dependencies. When too many jobs are running in parallel, it is easier to get the jobs out of order, and more jobs will be deferred. Deferring jobs causes more management overhead. Therefore, by running one less worker than the number of CPUs, the operating system CPU requirements and other CPU usage attributed to overhead for deferrals are free to run on the available CPU and should not disturb the running workers. Oracle recommends the Optimal Number of Workers To determine optimal number of workers, test with the following goals:

Between 1*CPUs and 1.5*CPUs Average IO response times below 10-15 milliseconds Average CPU usage below 100%

Optimize adpatch
Choose the proper batchsize Batchsize=10000

Choose the proper number of workers # of workers = CPUs - 1

Time the Upgrade

You cant manage something unless you can measure it. The following is an example of the Unix command time with adpatch running in non-interactive mode using a defaultsfile. time adpatch defaultsfile=$APPL_TOP/admin/VIS/adalldefaults.txt logfile=adpatch.log patchtop=$AU_TOP/patch/115/driver workers=3 interactive=yes options=novalidate, nocopyportion, nogenerateportion The software installed by RapidWiz includes all the application tier file-system changes; therefore, the copy portion and the generate portion of the adpatch process are not required. These changes should be applied to the database by running the patch with the nocopyportion and nogenerateportion options. Other possible options to reduce downtime: nocompiledb, nocompilejsp, noautoconfig. Use the AD_TASK_TIMING table to gather timing information. The elapsed time is in fractions of a day. Multiply the elapsed time by 24 hours per day, to get the units in hours. The following diagram shows the most time consuming jobs in the upgrade. Compiling objects always takes the longest, followed by statistics and parallel compiles. Use this table to find jobs that have large elapsed times. Some long running jobs have scripts that can be run before upgrade weekend to reduce the processing required during upgrade weekend.

JOB_NAME adobjcmp.sql adobjcmp.sql adsstats.sql adstatrp.sql adpcpcmp.pls adpcpcmp.pls

PRODUCT ad ad ad ad ad ad

PROGRAM AutoPatch AutoPatch AutoPatch AutoPatch AutoUpgrade AutoUpgrade

PHASE 27 79 346 346 12 12

elapsed time hrs 5.652222222 2.133611111 1.908888889 1.908888889 1.842222222 1.768611111

adobjcmp.sql adpcpcmp.pls invmenu.ldt

ad ad inv

AutoPatch AutoUpgrade AutoPatch

346 12 41

1.758055556 1.656944444 1.288333333

After the Upgrade Driver finishes

Make sure you reset the following init.ora parameters after completion of the R12 upgrade driver: recyclebin parallel_max_servers job_queue_processes

Merge all the NLS patches and apply them as single merged patch Isolate post upgrade concurrent programs to a separate manager queue as mentioned in the best practices My Oracle Support Knowledge Document: 399362.1

4) Finish the Upgrade

Verification Tasks Testing Methodology
Testing is the basis of success for upgrades. Testing requires practice. Testing requires management. Testing requires the best and most knowledgeable users. There are three types of testing: Functional, Technical and Load Testing:

Functional Testing Functional testing is probably one of the most important skills to develop within your internal staff. After a clone or a large patch, technical tests are executed to confirm the availability of technical components. Functional testing should then be performed to confirm the availability of key functionality. Functional test scripts take time to develop and really should be a continuous effort to improve the test scripts. Test scripts should be run often enough that users are proficient with the execution of the test scripts, and know what test results to expect. Typical steps in testing: Develop Test Scripts Execute Test Scripts Perform Unit and Integration Tests Test Customizations Test Release 11i existing data in R12 - Functional testing usually is centered on entering new R12 transactions. Make sure transactions that were entered in Release 11i can still be used in R12.

Load Testing Identify the primary workload Characterize the workload Identify bottlenecks

Improve performance

Technical Testing Identify potential issues Understand the R12 Architecture Apply patches or customize to correct issues

Test Management
The lack of effective testing is the single most frequent cause of failure to Go Live. Testing is a dedicated job. Most companies only lend one resource to a test initiative. The Test Manager should be a dedicated resource. The Test Managers tasks include mentoring the testers, stressing the importance of testing to the organization, ensuring adequate testing, monitoring and improving the Test Development process, and coordinating testing with the technical and functional staff

Test Environments
The following R12 test instances may be required: A Development instance for the developers A Test instance for each new module being implemented A Patch instance for the DBA A Training instance for training

Too many instances can lead to cloning nightmares.

Functional Testing
Functional Testing includes updating existing E-Business Suite test scripts to reflect valid navigation paths for Release 12, developing new Oracle E-Business Suite Release 12 test scripts, incorporating any customizations, and performing regression testing. The users should review the patch readme, but usually dont. Often, they arent aware of new functionality that is introduced by the patch. DBAs should summarize the new functionality for the new patches that are being tested. DBAs should also give the users a list of Forms that changed due to the patch. These forms should be tested. Use the unified driver that comes with each patch to determine the new .fmbs being copied into the instance. These are the new forms that need to be tested. Convert the short form name to the long form name that users recognize.
SELECT fnd_form.form_name, fnd_form_tl.user_form_name, fnd_form.last_update_date, fnd_form_tl.last_update_date FROM applsys.fnd_form, applsys.fnd_form_tl WHERE ((fnd_form.form_id = fnd_form_tl.form_id))

Release 12 introduced functional verification tasks to help identify issues before making a Go Live decision. In addition to tests your users should run to verify day to day operations, they should also run the verifications tasks listed in Appendix F of the Oracle Applications Upgrade Guide, Release 11i to 12.1.1, Part No. E14010-01. The following verification tasks are to verify GL and Payables: Global Accounting Engine Verification Tasks Run Accounting Reports You should run the Global Accounting Engine accounting reports before the upgrade and the corresponding Subledger accounting reports after the upgrade to ensure that you have a proper audit trail of the upgraded accounting data. The reports are as follows: Global Accounting Engine Daily Journal Book Account Ledger by Account Supplier and Customer Subledger Subledger Accounting Daily Journal Report Account Analysis Report Third Party Balances Summary by Account Third Party Detail and Balances by Account Report

Supplier and Customer Balance E-Business Tax Verification Tasks

Tax Transaction Audit and Reconciliation Reports To ensure that transaction tax information has been correctly upgraded, run the Payables Tax Audit Trail report and the Receivables Tax Reconciliation report for the current tax period before the upgrade to set a benchmark of transaction information. Then immediately after the upgrade, run the same reports in the new environment for the same period and compare the results to ensure that the tax values are still the same.
E-Business Tax Run the Upgrade Historical Subledger Transactions Concurrent Program to update accounting and tax data. All subledger products now have a post downtime upgrade process using a concurrent program to allow users to update ledger details for the Subledger Accounting (SLA) upgrade for each product area. The new process is called XLAONDEUPG - Upgrade Historical Subledger Transaction Accounting. This can be used to upgrade the old data for a particular ledger and product.

Journal Reconciliation TUMS Step Key: GL_CREATE_RECON_LINES This new feature replaces the General Ledger Entry Reconciliation functionally from within Oracle Financials Common Country Features.

It enables you to reconcile journal lines that should net to zero. It is often used to reconcile suspense accounts, or to audit or reconcile payroll and tax-payable accounts in other countries or to verify open balances of specific accounts at the end of a period. If you want to reconcile journal lines entered prior to the upgrade or to view and reverse reconciliations performed prior to the upgrade, then run the Upgrade Journal Lines for Reconciliation concurrent program.

Payables and Receivables Transaction Query For a sample of Payables and Receivables transactions, record the details of the associated tax for these transactions before migration, and then query them again after the upgrade to ensure that the tax has been correctly upgraded. Duplicate the same transactions and re-trigger to ensure that the new E-Business Taxbased calculation is consistent with the previous calculation. Payments Verification Tasks Legal Entity Configurator Verification Tasks You should perform a review of all legal entities and establishments in your system after the upgrade is complete to ensure that the correct legal structure is in place. You can access this information by using the Search Page in the Legal Entity Configurator. Refer to the Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12. If you need to create or upgrade legal entities and establishments, then see the Oracle Financials Implementation Guide for instructions. Trial Balance Reconciliation In your Release 11i environment, run the Accounts Payable Trial Balance, Posted Invoice Register, and Posted Payment Register reports. After the upgrade, run the Open Account Balances Listing Report, Posted Invoice Register, and Posted Payment Register in your upgraded environment and compare the results. The reports run for a ledger or a ledger set, not within the context of a single operating unit. The Release 11i Trial Balance and Posted Invoice and Payment Registers run within a single operating unit. Depending on your system configuration, you may need to sum several of the Release 11i reports to tie to the new versions. Invoice and Payment Processing To verify the integration with Oracle Payments and the upgrade of existing invoices, submit a payment batch with limited selection criteria in order to pay a few invoices. Accounting Setup and Processing Query an invoice that was not validated prior to the upgrade, then submit accounting for that invoice. Query an invoice that was accounted before the upgrade, cancel it, pay it, and then account for the payment. Also see Global Accounting Engine. These tasks apply only to Oracle Payments. In general, your planning for upgrade verification should involve testing in the two payment process areas:

Funds Disbursement If you used Oracle Payables for issuing payments in Release 11i, you should plan to test the funds disbursement processes equivalent to the former payment batch flow to ensure that your upgraded data correctly reflects your business process.

Funds Capture If you used Oracle Receivables for electronic payment processing such as direct debits or bills receivable remittances, you should plan on testing these areas to ensure that your upgraded data correctly reflects your business process. If you used Oracle iPayment for capture of funds from credit cards or bank account debits, you should plan on testing these processes to ensure that the upgraded data results in the process you expect

System Security Options Oracle Payments provides this new page where system-level settings for encryption, masking, and credit card security can be controlled. When your upgrade is complete, you should plan on reviewing the seeded settings in this page to ensure they meet your business needs. For example, in Release 11i masking of credit card values is controlled in different ways throughout the applications. In this release, the central setting in this page controls all masking. You will want to review the setting in this page and modify it if needed. Oracle Payables Impact You may want to run reports for use in your upgrade verification testing. For example, you may want to use the Suppliers Report in Oracle Payables to verify the data upgrade for payment details and bank accounts on the payees created in Oracle Payments. You can use any reports that you ran before the upgrade to help verify upgraded data. In addition, there are some key setup entities that should be reviewed and used in testing payment processing. Payment Process Profiles - You should plan on reviewing the settings for the seeded profiles created by the upgrade. These settings come from a variety of sources, and since the profile drives the entire funds disbursement flow it is important to verify that the setup supports your business process. You should pay special attention to the usage rules set on the seeded profiles as these can be changed if the upgraded values do not align with your needs. It is recommended that you run a test payment process with each profile that you plan to use in production. Payment Methods - A new setup page is provided where payment methods can be created or updated. You should plan on reviewing the payment methods seeded by Oracle Payments to ensure that they meet your business needs. Payment Systems and Accounts - You should plan to verify these entities after the upgrade, and in particular the required settings, values, and their links to the payment process profiles. This setup controls important parts of the funds disbursement process such as payment file transmission, so you should test this area to be sure that the process is working as you expect.

Projects Verification Tasks. Property Manager - Verify Upgraded Data Perform these steps to verify that E-Business Tax, Subledger Accounting, and Legal Entity data were successfully upgraded:

E-Business Tax Navigate to Property Manager > Leases and Documents. Query for a lease that has been upgraded from 11i (one that had a term with Tax Code and Tax Group). Navigate to Payment > Open and verify that Tax Classification Code is populated in the Payment Term. Navigate to Term Templates and verify that Tax Classification Code is populated in the template.

Subledger Accounting Legal Entity Submit the Receivables Auto Invoice Import program for importing the invoices with the Batch Name of Property Manager Batch Source. Navigate to Export to Receivables/Payables > Transactions > Transaction Workbench. If Legal Entity is associated correctly with the transaction, it signifies that the Legal Entity Upgrade for the Exported Line has been complete correctly. Navigate to Property Manager > Leases and Documents > Subledger Accounting > Accounting Events. Specify the start and end date along with ledger for which the SLA upgrade was done. The system displays a list of Finally Accounted accounting events. Navigate to View Journal Entries and verify the entries. Drill down for more information.

Verify Subledger Accounting Integration In your Release 11i environment, run the AUD: Revenue Audit Concurrent Program for an accounting period in the current fiscal year that has been closed. After the upgrade, run the same report in your upgraded environment and compare the results. Verify E-Business Tax Upgrade Use the Event Types, Expenditure Types, and Invoice Review screens to check for invoices, event types, and expenditure types to make sure that they were upgraded successfully. Verify Resource List Migration You can view existing resource lists that were successfully migrated to resource planning lists on the Planning Resource Lists page. You can also verify that the planning resources are the same as the resource list members.

Also the Resource Breakdown Structures page displays a resource breakdown structure with the same name as the resource list. Verify that the nodes of the resource breakdown structure are the same as the resource list members, and have the same two-level hierarchy if the resource list was grouped.

Running Concurrent Manager jobs