TruTek Little r1213 Upgrade Essentials 03-15-2013

the little r12.1.
3 upgrade essentials for managers and team members
an overview from the three primary perspectives: managerial, functional and technical by Mike Swing
the little r12.1.3 upgrade essentials
Copyright 2013 by TruTek All rights reserved. No part of this document may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording or otherwise without explicit permission from the authors. Published by TruTek. TruTek 1740 South Main Street Salt Lake City, UT 84115 Phone 801 486-6655 Last Updated: 3/15/13
http://www.trutek.com
Oracle is a registered trademark of Oracle Corporation. Other trade and service marks are the property of their respective owners. Order additional copies at http://www.trutek.com
Table of Contents
Table of Contents
THE LITTLE R12.1.3 ESSENTIALS FOR MANAGERS AND TEAM MEMBERS ...................................................................................................... 7 AUDIENCE ..................................................................................................... 7 THE BIG PICTURE .......................................................................................... 7 AVAILABLE REFERENCES .............................................................................. 8 TRUTEK TRAINING ........................................................................................ 8 Release 12.1 New Features Training ....................................................... 8 TruTek Release 12.1.3 First Pass Upgrade Onsite Training ................... 8 Other Training ......................................................................................... 9 TRUTEK CONSULTING ................................................................................... 9 TruTek Release 12.1.3 Technical Upgrade Readiness Assessment .......... 9 Release 11i Extended Support Mandatory Patching Consulting Engagement .............................................................................................. 9 TruTek Release 12.1.3 Ongoing Technical Support ............................... 10 TruTek Release 12.1.3 Functional Upgrade Readiness Assessment ...... 10 TruTek Functional Upgrade Support ..................................................... 10 TruTek Testing/Quality Assurance Support ........................................... 10 TRUTEKS RELEASE 12.1 BOOKS ................................................................ 11 OUR PARTNERS ........................................................................................... 13 CHAPTER 1 PLAN TO UPGRADE ........................................................ 19 FIRST STEPS ................................................................................................ 19 WHY MIGHT A BUSINESS DECIDE OR HESITATE - TO UPGRADE? ............. 20 DECISION: REIMPLEMENT VS. UPGRADE ..................................................... 21 Upgrade vs. Reimplementation .............................................................. 21 Transform and Upgrade with eprentise ................................................. 22 Oracles Reimplementation Tools .......................................................... 30 Other Third Party Tools That Help Reimplementation .......................... 32 CAPABILITY MATURITY MODEL ................................................................. 35 UPGRADE BENEFITS: AN OPPORTUNITY TO OPTIMIZE YOUR HARDWARE CONFIGURATION ......................................................................................... 36 UPGRADE BENEFITS: IMPROVED ORACLE TOOLS SIMPLIFY THE PROCESS .. 38 Real Application Testing ........................................................................ 38 Database Replay .................................................................................... 38 Maintenance Wizard .............................................................................. 39 UPGRADE BENEFITS: USE SHARED SERVICE CENTERS TO DRIVE COST SAVINGS AND INCREASE INFORMATION QUALITY ....................................... 40 UPGRADE PROCESS: THE R12 FUNCTIONAL UPGRADE REQUIRES GAP ANALYSIS.................................................................................................... 41 UPGRADE PROCESS: ASSESSMENTS CAN HELP THE PLANNING PROCESS .... 44 Functional Upgrade Assessment ............................................................ 45 Technical Upgrade Assessment .............................................................. 45 Customization Assessment...................................................................... 46 3

Architecture Assessment .........................................................................46 Hardware Assessment .............................................................................48 UPGRADE PROCESS: UNDERSTAND THE FUNCTIONAL FINANCIAL R12 NEW FEATURES ....................................................................................................49 Integrated Financials ..............................................................................49 Subledger Architecture ...........................................................................49 Key R12 Modules ....................................................................................49 Subledger Currency Views ......................................................................50 Multi-Org Access Control .......................................................................51 UPGRADE PROCESS: BUILD A STRONG UPGRADE TEAM ..............................52 Dedicated Team Members.......................................................................52 Upgrade Roles and Responsibilities .......................................................53 Technical Upgrade Responsibilities........................................................53 Functional Upgrade Responsibilities ......................................................54 Upgrade Project Manager Responsibilities ............................................54 Steering Committee .................................................................................55 UPGRADE TACTICS .......................................................................................55 SUCCESS FACTORS FOR UPGRADE PROJECT MANAGERS ..............................56 Time and Money ......................................................................................57
Customization Costs....................................................................................... 58
Skills ........................................................................................................58
Identify Skill Gaps in Your Upgrade Team .................................................... 58
Teamwork ................................................................................................59
Team Obstacles .............................................................................................. 59 Minimize Risk ................................................................................................ 60 The Team Must Recognize Competing Priorities........................................... 60
SUCCESS FACTORS FOR FUNCTIONAL USERS ...............................................61 Gap Analysis ...........................................................................................61 Known Gaps ............................................................................................62
Financial Reporting Gaps ............................................................................... 62 Drill Down Restrictions ................................................................................. 63 Limited Chart of Accounts Access ................................................................. 63 MS Word Becomes the Report Layout Editor ................................................ 63
Recommended Add-on Products .............................................................63

Excel-based Reporting Alternatives ............................................................... 63
Customizations ........................................................................................65 Cumulative Business Value of Small Business Productivity Improvements ..........................................................................................66 Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations ......................................................................................67 SUCCESS FACTORS FOR TECHNICAL UPGRADE MANAGERS .........................68 Patches ....................................................................................................69 Upgrade Patch Types Release 12.0 Critical Patch Collections (CPCs), Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic Data Fixes (GDFs), CPUs, PSUs ...........................................................69
Release 12.0 Critical Patch Collections (CPCs) ............................................. 69 Oracle E-Business Suite Pre-install Patches ................................................... 70 Recommended Patch Collections (RPCs) ...................................................... 70
Table of Contents
Generic Data Fixes (GDFs) ............................................................................ 71 Critical Patch Updates (CPUs) ....................................................................... 71 Use Patch Wizard from Oracle Application Manager (OAM) ....................... 72
The Patching Process ............................................................................. 74 The Testing Process ............................................................................... 75 Create Custom Development Upgrade Plan .......................................... 75 How to Upgrade Customizations ........................................................... 76 Obsolete Technology Components with Release 12 ............................... 77
mod_plsql....................................................................................................... 77 Oracle Reports Server Reports ....................................................................... 77 Oracle Graphics Integrations with Oracle Forms ........................................... 78 AK Mode ....................................................................................................... 78
JOINING FUNCTIONAL AND TECHNICAL VIEWS ........................................... 79 Upgrade Success Without Customizations ............................................. 80 Tools of Choice for Rooting Out Customizations ................................... 80 CHAPTER 2 PREPARE TO UPGRADE ................................................ 83 PRACTICE TESTING...................................................................................... 83 OPTIMIZE THE UPGRADE ............................................................................. 83 MAINTENANCE WIZARD .............................................................................. 83 UPGRADE BY REQUEST ............................................................................... 84 DEFAULT UPGRADE PERIODS - MINIMUM DOWNTIME UPGRADE ................ 84 INSTALL THE SLA PRE-UPGRADE CONCURRENT PROGRAM ....................... 85 RUN THE SLA PRE-UPGRADE CONCURRENT PROGRAM .............................. 85 ADJUSTMENT PERIODS ................................................................................ 87 SLA POST UPGRADE PROCESSING .............................................................. 87 Upgrade by Request ............................................................................... 87 THE UPGRADE IS AN ITERATIVE PROCESS ................................................... 87 MANAGE-EVOLVE-OPTIMIZE ...................................................................... 88 Manage................................................................................................... 88 Evolve ..................................................................................................... 88 Optimize ................................................................................................. 89 Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process ............................................................. 89 When Are We Ready? Are We There Yet? .............................................. 89 Technical Upgrade Paths - Release 12.1 Upgrade Paths ...................... 91 RELEASE 12.1 UPGRADE PATHS .................................................................. 92 DATABASE UPGRADE REQUIREMENTS ........................................................ 93 DATABASE UPGRADE STEPS........................................................................ 94 UPGRADE TIMEFRAME ................................................................................ 94 UPGRADE DOWNTIME WITHOUT THE DATABASE UPGRADE ....................... 96 UPGRADE WEEKEND ................................................................................... 96 CHAPTER 3 PERFORM THE UPGRADE ............................................ 99 TUNE THE UPGRADE.................................................................................... 99 OPTIMAL NUMBER OF WORKERS .............................................................. 100 OPTIMIZE ADPATCH ................................................................................... 100 5

TIME THE UPGRADE ...................................................................................100 AD_TASK_TIMING ................................................................................101 REDUCING DOWNTIME ...............................................................................102 AUTOCONFIG IN PARALLEL MODE ACROSS MULTIPLE NODES ..................102 AFTER THE UPGRADE DRIVER FINISHES ....................................................103 CHAPTER 4 FINISH THE UPGRADE .................................................105 THE IMPORTANCE OF TESTING ...................................................................105 TESTING METHODOLOGY ...........................................................................105 Functional Testing ................................................................................106 Load Testing..........................................................................................106 Technical Testing ..................................................................................107 TEST MANAGEMENT ..................................................................................107 TEST ENVIRONMENTS ................................................................................107 FUNCTIONAL TESTING ...............................................................................107 Global Accounting Engine Verification Tasks ......................................108
Run Accounting Reports .............................................................................. 108
E-Business Tax Verification Tasks ........................................................108

Tax Transaction Audit and Reconciliation Reports ...................................... 108 Payables and Receivables Transaction Query .............................................. 108
Payments Verification Tasks .................................................................109

Legal Entity Configurator Verification Tasks .............................................. 109 Trial Balance Reconciliation ........................................................................ 109 Invoice and Payment Processing .................................................................. 109 Accounting Setup and Processing ................................................................ 109 System Security Options .............................................................................. 110 Oracle Payables Impact ................................................................................ 110
CONCLUSION ............................................................................................113
the little r12.1.3 essentials for managers and team members

That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved. Ralph Waldo Emerson (1803 - 1882)
Audience
The intended audience for this handbook is upgrade managers and all team members participating in the upgrade to Release 12. This team may include the following team members: Super Users, DBAs, Developers, Quality Assurance Testers and Hardware Architects. Team members should be able to understand the basics of all phases of the upgrade. This handbook provides an overview of the upgrade, the transition from an Oracle E-Business Suite Release 11i environment to Release 12.1, from three primary perspectives: technical, functional and managerial. Understanding these perspectives will allow for better communication between the primary groups of upgrade participants. Each point of view has slightly different criteria for success. Team members should understand that success can be claimed only when all the success criteria have been met. As teams grow larger, the skills required to manage large groups grow as more ideas are expressed. The intimacy of a small group is lost, and the opportunity for misinformation and disruptive rumors grows. Managers may encounter difficulties based on Daglow's Law of Team Dynamics: "Small teams are informed. Big teams infer." Communication is essential.
The Big Picture

There are four upgrade categories, according to Oracle, and we will follow this convention to be consistent. As you read this book, we devote a chapter to each of these four topics:
the little r12.1.3 upgrade essentials 1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade
Available References
Check out our training, our consulting, and our books, and youll see weve developed a comprehensive approach to upgrading to Release 12.1.3.
TruTek Training
Release 12.1 New Features Training
One could argue that the changes to the E-Business Suite of Applications for Release 12.1 are the most significant part of a Release 12.1 upgrade. Our expert trainers cover new features provided by Release 12.1, including changes to General Ledger, Purchasing, Payables, Fixed Assets, Receivables and Cash Management. Our class also discusses changes to Inventory, Order Management, Projects, iExpense, iSuppler, iProcurement, iReceivables, and TCA. We can also tailor the class to cover just the modules that you plan to use, and if were assisting with your upgrade, our trainers also do the consulting work, so they can tailor classes to your unique environment.
TruTek Release 12.1.3 First Pass Upgrade Onsite Training

If youre ready to upgrade and want to run against your own data, rather than a Vision instance, we now offer a special consulting engagement called the Release 12.1.3 First Pass Upgrade. We come to you for this upgrade, and we lead your technical staff through the upgrade in a two to three week engagement. We provide step by step guidance and our detailed problem solving skills, while your technical staff performs the upgrade. During the engagement, we work with your staff to monitor activities overnight and on the weekends, and we inevitably hit issues that we havent seen at other clients. We document the workarounds and provide each client with an updated version of the little r12.1.3 upgrade guide that includes a list of patches that are specific to their environment. We would expect a normal first pass upgrade to take 1 3 months, but because weve been through the upgrade process so many times in our
8
the little r12.1.3 upgrade essentials classes and consulting engagements, we can streamline the first pass to two to three weeks. So if youre ready, give us a call.
Other Training
Our Oracle E-Business Suite R11i to R12 Technical Upgrade class takes students through a full upgrade of the Vision instance for Oracle customers who arent ready to establish a test environment for our onsite upgrade class. We also offer DBA classes that include Oracle R12 Applications DBA Concepts and Admin, 11g DBA Boot Camp I and 11g DBA Boot Camp II.
TruTek Consulting
TruTek Release 12.1.3 Technical Upgrade Readiness Assessment
Before you start your upgrade to Release 12.1.3, we strongly recommend a Release 12.1.3 Upgrade Readiness Assessment. We send you a questionnaire and list of scripts to run, and then we come onsite and evaluate your environment to help you decide if youre ready to upgrade. Our detailed report covers your environment and describes issues that you need to address before you start your upgrade. Do you have the right hardware to support Release 12.1.3? Do you have the right skillsets to support Release 12.1.3? Do you have the right patches in place to support your Release 11i environment while you are preparing to upgrade to Release 12.1.3? We look at those questions and more to help you prepare.
Release 11i Extended Support Mandatory Patching Consulting Engagement

This onerous task requires comparing which modules youve licensed and the current status of patching of those licensed modules with Oracles MOS Doc. ID: 883202.1, which includes a list of dozens of patches that may need to be applied to your environment in order to receive support from Oracle now that Release 11i is in Extended Support. If you plan to upgrade to Release 12.1.3, we believe you should get your E-Business Suite Release 11i environment in order so that your staff can focus on the Release 12.1.3 upgrade rather than potential support issues with your current environment. Doing so requires a thorough review of your environment, as well as a meticulous review of Oracles Release 11i Extended Support Mandatory Patches, including reading all the Readmes, searching for pre-requisite patches and post patches, building a
9
the little r12.1.3 upgrade essentials spreadsheet of all the required patches, and then applying and testing them. TruTek has been down this road a few times and would be happy to assist.
TruTek Release 12.1.3 Ongoing Technical Support

Most of our clients require assistance on their Second Pass Upgrade. The flurry of issues that arise during the First Pass Upgrade often take attention away from establishing total comfort with the upgrade process. We can provide support either onsite or remotely for the Second Pass, and were happy to continue to provide support for additional passes until everyone is comfortable with the process. We can also provide ongoing support by keeping your DBA informed as we head to new clients and discover new issues and patches. We can also provide onsite support during your final upgrade weekend. We highly recommend production upgrade support during the full court press, it helps to have an experienced partner helping to check and double check that the final upgrade goes smoothly.
TruTek Release 12.1.3 Functional Upgrade Readiness Assessment

TruTeks Functional Upgrade Readiness Assessment is best performed shortly after the TruTek Release 12.1.3 First Pass Upgrade. Your users will need guidance to perform the gap analysis between the existing Release 11i environment and the Release 12.1.3 environment. This Assessment begins the process of determining new features, as well as determining what customizations have been done, and whether they should be maintained or eliminated.
TruTek Functional Upgrade Support

TruTeks functional consultants understand the nuances of Release 12.1.3 and can work with you to build a test plan, resolve issues with functionality, and help drive the customization review process.
TruTek Testing/Quality Assurance Support

TruTek partnered with Original Software to provide a unique solution for Application Quality Management to unite all aspects of the software quality lifecycle from requirements to test planning, test case design, test execution and defect tracking, all with full traceability. TruTek consultants will guide you in implementing the Original Software Qualify products, including TestBench, TestDriver, and TestSmart, to
10
the little r12.1.3 upgrade essentials build on your quality processes and ease into full quality automation. We will work with your functional subject matter experts to create manual tests in TestDrive for Oracle Application web pages and forms, or customers can take advantage of TruTeks repository of Oracle Application test scripts. TestDriver test scripts can then be used with TestDrive Assist to facilitate full-blown test automation. TestSmart can be used to populate your test scripts with different data on each test run, allowing you to create many business scenarios with one script. TestBench can be used to manage your test environment, provide intelligent data extraction with obfuscation techniques, compare test runs, and implement database undo to return data to a prior state, thus allowing multiple test runs to quickly fix defects for successful test results. TruTek consultants will help you configure Qualify to fit your organizational quality methodology whether you use Agile, waterfall, or a hybrid approach. We will show you how to take advantage of Qualifys many features, such as drill down dashboards for access to instant information by all users including functional, technical or management, cross project resource management, integrated workflows, email integration, role-based access control, and built-in and customized reporting.
TruTeks Release 12.1 Books

TruTek now offers two sets of books, those published externally about the E-Business Suite for anyone interested in upgrading to Release 12.1, and tailored books (we call them the blue books) written for each of our customers or classes as part of an upgrade project or training class. Weve made this change because each customers patches will be different depending on their operating system, database, Applications patches and E-Business Suite modules. For some of the books, reflecting those differences is critical to upgrade success. You can buy our books and DVDs online at: http://www.shop.trutek.com/category.sc?categoryId=30 If youd like to take a training class with us or bring us in to consult, give us a call at: 801 486-6655.
11
TruTek is a national leader in technical and functional Oracle training and consulting. We specialize in Oracle database and Oracle E-Business Suite technical and functional consulting. TruTek offers a full range of Oracle training classes.
You can sign up for TruTeks monthly TruTalk Newsletter at: www.trutek.com
12
Our Partners
Weve come to the conclusion that a successful upgrade requires the best tools and the best partners. As weve worked through the Release 12 Upgrade process, weve concluded that there are five areas that require special attention:
Testing What everyone hates and what no one can avoid! Inadequate
testing of your Oracle Application implementation or upgrade can result in an over budget project with an unpredictable extended timeline, negatively impacting your organizations business processes and putting your upgrade at risk.
Original Softwares Qualify product, including TestBench, TestDrive, TestSmart, and TestDrive-Assist, can bring organization, improved project control and visibility and quality testing to your upgrade, while enhancing collaboration between management, functional and technical project members. Original softwares easy to use test solutions include a project management platform with manual testing that can be transformed into full test automation without requiring programming skills. Subject matter experts are empowered to define and execute sophisticated testing scripts to use on updated Oracle Applications development and test environments. Defects can be detected and changes automatically incorporated into updated test scripts. Original Software ensures test data privacy with obfuscation techniques for audit compliance, database checkpoint and rollback functionality for errors to be identified, corrected and tests quickly repeated. Not only is Original Software technology easy to use, but it accelerates the quality process, allowing for faster delivery of business critical Oracle Projects.
13
the little r12.1.3 upgrade essentials Eleven Reasons to Use Original Software for EBS Testing Original Software products provide these features: Qualify 1 2 3 4 Full project management, planning, estimating, assigning, and tracking capability Project workflow, design custom workflows for your company Effective project collaboration for management, functional, and technical users Issue tracking system for managing your upgrade tasks, testing, and SRs Training made easy with Fast-Track test scripts; teach as you test! Manual system and user acceptance testing with screen capture and test steps Code free and self-healing test script technology Performance, server, and browser statistics Manual to full automation
TestDrive 5 6 7 8 9
TestBench TestSmart 10 Smart data creation Fast-Start Test Packs for EBS 11 R12.1 test scripts for Financials, Procurement, and Inventory
14
Reimplementation not! There are several reasons why you might

consider reimplementing, which means, essentially, starting over with the E-Business Suite, but with the advantage of having used the applications for a number of years. Reimplementing is considered more costly than upgrading because you really do have to go through all the setups and make decisions about what their values should be for your environment. Sometimes reimplementation is the only way to go. Our TruTek consultants can help you decide if reimplementing is unavoidable, or we can talk about a tool from eprentise that solves many of the common issues including changes to the Chart of Accounts. With software available since 2007 from eprentise, an Oracle Partner, now it is possible to upgrade from Release 11i even if you need to change the Chart of Accounts, reorganize operating units, adopt a different calendar, leave behind corrupt data, or consolidate multiple instances into a single global production instance.
Customizations tracking down those extra reports that youve

placed under $CUSTOM_TOP is one thing, but what about all those changes that youve made over the years to menus, value sets, and profile options? We think that Rookery Software has the best solution available, called ConfigSnapshot. We use ConfigSnapshot to take a snapshot of the current environment. Then we perform the upgrade and take a second snapshot and use the ConfigSnapshot tools to root out the differences changes made by users, as well as those made by Oracle with the new release. ConfigSnapshot also includes customization code impact analysis, enabling you to automatically search through any custom code you have, to identify where you have referenced objects that have changed between
15
the little r12.1.3 upgrade essentials versions. This frees up technical resources to focus on deciding how the code should be modified to work correctly in the upgraded environment, rather than spending significant time trying to manually locate which of the thousands of modified objects may be included somewhere in each item of custom code.
Reporting - Excel4apps GL Wand is an award-winning, Excel-based

financial reporting solution for finance professionals using Oracle eBusiness Suite 11i or 12. As an Oracle Validated Integration solution, GL Wand enables highly efficient and secure financial reporting, shorter month ends, and faster refreshes with ad-hoc inquiry and drill downs. Like all Excel4apps solutions, GL Wand leverages your existing Oracle security settings and provides reports with drill-down capabilities that are refreshable on demand, yet preserve formatting and Excel formula. Without middleware or data warehouse requirements, you can install and utilize Excel4apps solutions in minutes so theres less reliance on IT support and greater power given to the individual user. GL Wand Benefits Live Oracle data in Excel Effective replacement for Client ADI reporting Accelerate month end processing No need for data warehousing Automate sharing and distribution of reports Leverage existing Oracle security Ease your upgrade to Oracle R12 Quick to install, fast performance and easy to use Mass reporting and distribution HTTP connection FSG converter
16
Performance Tuning - Confios Ignite 8 is a comprehensive

performance solution that you can use with your E-Business Suite environment. Ignite focuses on measuring response time, and adds server resources, expert advice, and trends ranging from one second to one year. Confios Alarm Trail leads you right to the root cause, simply by clicking on the alarm icons to navigate. Only Ignite leads you on a path directly to the problem. Ignite includes correlation of all metrics including response time, server health, real time sessions, and query statistics. Only Ignite correlates all the server health indicators with response time data from wait events.
If youd like to learn more about our partners, contact us at www.trutek.com, or call us at 1 801 486-6655.
17
Chapter 1 Plan to Upgrade

1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade A man that does not plan ahead, will find trouble at his door. Confucius
First Steps
There are three main perspectives for the upgrade: functional, technical and managerial. We will show how these points of view work together, especially when customizations are present. With each point of view comes a definition of upgrade success. Each point of view must succeed in order for the whole upgrade to succeed. The following steps are the starting point for the upgrade plan: First, organize executive sponsors and superusers into a Steering Committee. Have the Steering Committee identify and prioritize the reasons to upgrade. Special consideration should be paid to implementing new R12 functional features and achieving more efficient processing. De-support dates by Oracle should also be considered. Before making the decision to upgrade using Oracles upgrade process or reimplement from scratch, identify the current issues. Some issues may be resolved by new functionality, others may require new customizations. Broken processes are very likely to exist after the upgrade. Purge unnecessary data and clean up interface tables. Data cleanup should be an on-going process, but becomes a priority during upgrades because of the additional processing required during the upgrade downtime. Deciding whether to reimplement or upgrade depends on a number of factors. Doing a fresh implementation will likely take much more time and be more disruptive to your business. Most Oracle professionals prefer to upgrade if at all possible.
19
the little r12.1.3 upgrade essentials Understand the Hardware Requirements and the Upgrade Path. Significant cost savings can be achieved by simplifying and standardizing hardware. Procure Upgrade Hardware. The upgrade hardware in most cases should be newer and faster than the current production environment. This will allow a seamless cutover from the old production environment to the new upgraded environment on upgrade weekend. Because the upgrade occurs on the new upgrade machine, if the upgrade fails, production doesnt need to be recovered. Establish the Upgrade Team. The Steering Committee should select an upgrade project manager, who in turn selects the upgrade team. Train the Functional Users on the New Features of Release 12. The new features should be integrated into the upgrade plan to replace customizations, when possible, and improve efficiencies. Create an Upgraded Instance for Gap Analysis. Once trained, functional users will want to understand how the upgrade affects their data and their processes. This should include the most important customizations.
Why Might a Business Decide or Hesitate - to Upgrade?

The best reasons to upgrade are to take advantage of new functionality, to decrease costs, and to provide your business with a competitive advantage. De-support of your current version of software is not one of the best reasons, but it is compelling. Not staying current also has significant security implications. Why is waiting until Oracle is ready to pull the plug compelling? Because: it costs so much to upgrade, although it is much less expensive than reimplementing higher levels of management need a compelling reason nobody wants to run the latest release, especially .0 releases the upgrade impact is unpredictable if you have lost track of customizations, it is a lot of work to review them if you cant upgrade your customizations, delaying the inevitable is tempting if the business processes seem too complex to map to R12, you may want to wait for as long as possible before making the change
20
Decision: Reimplement vs. Upgrade

The decision to reimplement versus upgrade is simple: Do everything possible to upgrade. Dont reimplement unless you explore all alternatives and find that 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. As frustration and costs mount, many companies faced with continuing business changes and a need to upgrade to Oracle EBusiness Suite (EBS) Release R12 - have to make a decision with their outdated EBS configurations: 1) live with it, 2) reimplement or 3) upgrade. There are many reasons to do a technical upgrade, including lower costs, less risk, better results, and a shorter time-period. Why, then, do many customers feel that a reimplementation is the only option? The answer is easy: they dont know that commerciallyavailable software options are available to change their existing EBusiness Suite configurations and structures, or to consolidate multiple instances. When Oracle first released R12, they guided customers to reimplement if the customer needed to change any obsolete core configurations or to consolidate multiple production instances. Oracles R12 documentation acknowledged that reimplementation is more difficult, complex and resource intensive compared to an upgrade. It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting.
Upgrade vs. Reimplementation

Lets first examine the differences between an upgrade and a reimplementation. An Upgrade utilizes Oracle-provided scripts to convert the data from the current R11.5.10 Oracle E-Business Suite to R12. The scripts are well-documented and supported by Oracle
21
the little r12.1.3 upgrade essentials Support. With an upgrade, all of the data (configuration, master data, and transactions) is available for use after the upgrade, and has been converted into the format required by R12 (i.e., sets of books become ledgers, a Legal Entity is associated with a balancing segment value, etc.). There are minor setups such as secondary ledgers or subledger accounting that need to be configured to take advantage of new R12 functionality. For a Reimplementation, a new R12 environment is installed and the customer (usually with the assistance of a consulting firm or system integrator) configures all of the setups for every module. Then, decisions must be made on how much history to convert and what to do with open items. The consulting organization writes custom scripts (which are not supported by Oracle) to migrate the master data (customers, suppliers, employees, etc.) to the newly configured R12 environment. Then structures (such as charts of accounts, other key flexfields, calendars, and organization structures) need to be converted to the new environment. This usually involves custom scripts (again not supported by Oracle) to extract the structure, transform it into the new structure, and load it into the R12 instance. Finally, all the open transactions, and usually about a years worth of history, must be migrated along with beginning balances. Did we mention that these are all done by custom scripts that are not supported by Oracle, or that if there is a chart of accounts change, every transaction must be converted to the new chart of accounts? Did we discuss the reconciliation process between the R11 environment and the new, reimplemented R12 instance?
Transform and Upgrade with eprentise

Now there is an alternative to a reimplementation that addresses the need for change and allows the business to be agile and maintain data integrity while retaining all history. An Oracle Partner, eprentise, offers software that allows Oracle EBusiness Suite users to Remodel their existing Oracle E-Business Suite instance without a reimplementation:
22
Consolidate multiple production instances. Change existing configurations like charts of accounts, other key flexfields, calendars, and currency. Merge, split or move all structures including business groups, sets of books, legal entities, operating units, and inventories. Retain all history
Chapter 1 Plan to Upgrade The following tables show the pros and cons of a reimplementation effort versus a technical upgrade with eprentise remodeling:
Traditional Migration Approach (Reimplementation) Pros

Common approach, often recommended by consulting organizations and system integrators (Author Comment who may get compensated based on billable hours and utilization).
Remodeling Approach (eprentise software + Technical Upgrade) Pros

Shorter project duration with fewer resources translates to lower costs. Project can easily be completed in 3-8 months That means that the savings of a single instance are available sooner.
Cons
No standard extract/transf orm scripts. Very similar to a custom development project requiring a more formal development and testing methodology including documentatio n, error handling, and development standards. Requires reconciliation from old structures, configuration to new structures, configuration.
Cons
Not widely understood among Oracle professionals or system integrators. Customer needs strong sponsor.
23
Traditional Migration Approach (Reimplementation)

No need to upgrade Current 11i to New R12 due to straight data migration into an R12 instance. More risk in creating extract, transform, and load (ETL) that will not be supported by Oracle.
Remodeling Approach (eprentise software + Technical Upgrade)

Only testing that is required is functional testing. For consolidation , instances need to be at the same version/patc h level since eprentise software only works at the database tier.
Traditional Migration Approach (Reimplementation) Cons

Requires technical knowledge of all tables and usage in the EBusiness Suite.
Remodeling Approach (eprentise software + Technical Upgrade) Pros

Repeatable results, reusable as requirements change. As requirements change, only need to add/change rules, a step that is usually done by a functional user on a specially designed user interface in the software In a very short time. All data integrity is maintained because the code is automatically generated. Oracle will support customer after eprentise software is used.
APIs do not exist for all tables. There is a risk of compromising the data integrity by extracting and loading data incorrectly. Oracle Support not available.
24
Traditional Migration Approach (Reimplementation)

History is generally not converted. Generally a sunset instance is required for reporting, reconciliation, business intelligence, and audits. Every time the sunset instance is accessed, data must be transformed to align with the R12 instance. This access and transformation process is very, very expensive. Need to configure R12 instance Scripts are written for the current state of the data. Any changes require re-writing of the scripts. 12-24 months duration
Remodeling Approach (eprentise software + Technical Upgrade)

All history is converted so there is no need to maintain a sunset instance for reporting, reconciliation, etc. No need to derive landing balances or reconcile between old and new environments. All the data is complete and consistent.
No need to configure R12 instance Full documentation of existing instance and changes made including comparison of instances 6-9 months duration
25
the little r12.1.3 upgrade essentials Ten Reasons to Upgrade 1. Reduced schedule and technical risk. Upgrade relies on commercial EBS conversion software from Oracle and independent software vendors, rather than reimplementations technical analysts and data conversion programmers. 2. You can change your chart of accounts. Upgrade uses remodeling software to change one or more COAs segments and values so you can adopt a single global COA. 3. You test new EBS setups in familiar 11i. Upgrade uses remodeling software to change any fundamental EBS setup you have postponed until reimplementation. The common setups Oracle says are not easily changed include: Legal Entities, Sets of Books (Ledgers), Operating Units, Key Flexfields, Calendars, Costing Methods, Inventory Organizations, and Asset Categories. 4. Transaction data will be changed, too. Upgrade uses remodeling Software to convert all 11i data to reflect all COA and fundamental setup changes. 5. Your history matters. Upgrade uses Oracle upgrade to convert all 11i data to R12. Business users are happier with all EBS history and current data in a single R12 instance, rather than distributed between legacy and active instances. 6. Avoid custom data conversion. With reimplementation, you are on your own to create extract and load scripts to convert and migrate your 11i data into R12. Unless you load everything, compromises lead to complexity, delays, and continuing expense. 7. True single instance for past and future data. With upgrade the result is a single R12 instance, whereas with reimplementation you will have R12 plus the legacy 11i instance in read-only mode as a reference to history and the prior business structures. 8. Avoid multiple custom conversions and legacy instances. For multi-national organizations with multiple EBS 11i instances, reimplementation requires data migrations from each legacy 11i instance into the single R12 instance. You will also retain all legacy 11i read-only instances. 9. Upgrade offers the most direct path and shortest time to single instance R12 business value. The most powerful upgrade advantage for multi-nationals is consolidation to a single global instance with standard business processes and all history data prior to the Oracle upgrade to R12. 10. Upgrades cost less. EBS customers pay for Oracle upgrade software even if they select reimplementation. Why leave money on the table and pay extra to do it yourself?
26
Chapter 1 Plan to Upgrade A technical upgrade and a remodeling effort can circumvent all of the justifications previously given for a reimplementation.
You need a new Chart of Accounts, have multiple COAs and would like to consolidate to one global COA or have a single COA that needs to split into multiple COAs. An organization structure that was planned for growth but is now outdated and is some cases obsolete because of unanticipated changes. Or an organization structure that has experienced a merger/acquisition or a divestiture. Currently have multiple instances and need or want to consolidate into a single instance. Want to upgrade to R12 to take advantage of new functionality but existing structure doesnt seem to support an upgrade. Up to now, reimplementation and a potentially costly multi-year project with a staff of consultants manually making the necessary changes seemed the only option. Years of history are often left behind in order to speed up the project and reduce cost.
Consolidation software from eprentise enabled a leading automotive distributor to consolidate two regional production instances into a single global instance within 7 months and at a cost of under $1,000,000, including their technical upgrade to R12. The automotive distributor used only 5 full-time- equivalent (FTE) resources during the entire project and brought over all their history. This compares to similar projects costing between $12,000,000 and $15,000,000 and utilizing over 250 consultants over an18 month project duration.
Reimplementation Consequences Here are some reimplementation consequences in the areas of implementation, data history, handling 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 Oracles Reimplementation tools and utilities.
27
the little r12.1.3 upgrade essentials You are on you own to get your open transactions and historical data from the legacy Release 11i into R12. Oracle Support cant help if the data is incompatible once it is in the R12 environment or if it breaks the E-Business Suite 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. 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 may 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 will have to keep it available for external regulatory data retention purposes as well as operational analyses. You will need to devise reporting mechanisms to span the legacy Release 11i and operational R12 instances. This includes translations, reconciliations, mappings and external reporting environments. If you have a business intelligence environment or data warehouse, you will need to make changes to incorporate the frozen legacy Release 11i and R12 environments.
The following diagram shows the reimplementation approach. Customers following this path usually end up with the two instances (one Release 11i and R12) and keep workaround mechanisms in place to handle the instances or to make adjustments in a downstream business intelligence environment.
28

Reimplementation = Customer Implementation + Data Migration
Two instances, one active Historical data spans both, but different formats 11i
History Restricted Access
11i Not Upgradable
ly restr read-on tance set ins n u s Create

Customer Extract & Transform Selected 11i Data 11i Data History [partial?]
icted a
ccess
11i Data
Read-Only History
11i Data
Customer Load 11i Data History
R12
Via Public API & Interface Tables
Implement New E-Business Suite
R12 Fresh
Implementation
mp R12 e Clone
h efore nce b ty insta
lo istory
ad
R12 Data
Seeded Configured History [partial] Custom SQL & DB Utilities
R12 Data Seeded Configured
Path from one 11i instance to a single global R12 instance plus legacy instance
The reimplementation environment gets even more complicated if there are multiple Release 11i instances, multiple custom extract, transform and load operations, ending up with multiple Release 11i sunset instances. This diagram describes the upgrade 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 Obsolete 11i Obsolete Setups Obsolete 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
29
the little r12.1.3 upgrade essentials Transformation Benefits Shorter project duration with fewer resources translates to lower costs. Repeatable results, reusable as requirements change. Requires less than half the time and resources of consulting efforts. Accurate, consistent results (no need to worry about different coding styles, standards, skill levels, corrupting database, differences in different versions). Eliminates need to qualify consultants on technical skills. Maintains database integrity. Retains all history. Avoids reimplementation. Reduces risk. No Oracle Application software is changed or customized. No need for external mapping, data warehouse or reporting to reconcile different businesses. Make the most of existing resources. An eprentise Reimplementation Success Story A global leader in the mining industry needed to consolidate over 25 different charts of accounts into a single global chart of accounts. They used eprentise FlexField software to percolate changed accounting flexfield code combinations to each subledger of E-Business Suite for setup data and all transactions. All code combinations were changed and there was no on-going reconciliation between old and new charts of accounts. The results were a standard global chart of accounts, consistent reporting and a simplified financial consolidation process. All historical transactions were changed to reflect the new chart of accounts resulting in operations and reporting that looked as if the company had always been doing business using its new global chart of accounts.
Oracles Reimplementation Tools

Oracle provides a number of tools that can help with reimplementation:
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.
30
Chapter 1 Plan to Upgrade fndload see the paper, Customization Survival Guide: How to Use EBusiness 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 original export and import utility. Datapump - For RDBMS Versions 10g and 11g, you can use DataPumps expdp and impdp utility. This tool is much faster than Oracles older exp/imp 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. The E-Business Suite Plug-in - this is an added cost set of tools that supports security, cloning, customization, patching and setup for the EBusiness Suite. These tools provide a framework around tools like iSetup, but also offer new functionality, including the ability to document your customizations.
31
Other Third Party Tools That Help Reimplementation

ConfigSnapshot provides several capabilities to assist organizations when reimplementing, including: Quickly document your existing implementations setups to enable functional teams to determine which configurations should be retained and which are no longer applicable.
ConfigSnapshots planning capability enables organizations to design their configurations prior to deploying them to a new environment. Far more flexible than relying on manual documentation methods, it allows you to report flexibly on your plan and also to ensure that the planned setups are correctly configured in the environment itself.
32
ConfigSnapshots migration capabilities allow customers to migrate setups across environments/entities.
ConfigSnapshots comparison capabilities enable you to ensure that all setups are correctly deployed across environments as the project progresses.
33
Baselines enable you to capture setup at key stages of the project; allowing you to control the changes made during each phase.
Comprehensive security reporting, including segregation of duties, allows you to ensure that users have only the required access to perform their duties
34
Capability Maturity Model

Use the Capability Maturity Model as a framework to simplify and standardize your business processes and hardware. The Capability Maturity Model (CMM) is trademarked by Carnegie Mellon University and refers to a development model derived from data collected by the U.S. Department of Defense. The model is based on observation rather than on theory. The CMM provides an effective method to improve the software development process. Eventually, the CMM was applied more generally to business processes. For this book, our goals can be summarized with the Capability Maturity Model to simplify and standardize business processes using a framework to achieve efficiencies and cost savings. Actually achieving costs savings through Business Process Improvement (BPI) requires hard work to understand the new functionality and the existing business process model. Following this model, technology and process convergence lead to simplification, standardization and shared services.
35
Upgrade Benefits: An Opportunity to Optimize Your Hardware Configuration

Probably the least invasive time to implement a new hardware upgrade is during a software upgrade. Youll need to test how the operating system works with the new E-Business Suite software anyway, so why not take advantage of some of these benefits: Migrate to more cost-effective 64-bit Linux servers Migrate Application Servers to 64-bit hardware to support more users with more addressable memory Utilize Virtualization to help standardize hardware and software Implement a SAN with block virtualization capabilities, aka snapshots to dramatically improve cloning and backup performance Take advantage of the Space-Time Continuum: If we make copies of completed Apps Tiers before and after the upgrade, and if we have plenty of space to make a backup of the database that we can quickly restore, we can shortcut the iterative process of identifying the patches and patch order, thereby saving significant amounts of time. So, if we have more space, we can save time. Implement a simplified the Architecture where possible. With a 64 bit database server with 64 bit addressable memory and faster CPUs, there are fewer reasons to require more than one web, forms, and Concurrent Manager server; they can all reside on one box instead of two or three applications servers.
36
37
Upgrade Benefits: Improved Oracle 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.
38
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.
39
the little r12.1.3 upgrade essentials 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
Upgrade Benefits: Use Shared Service Centers to Drive Cost Savings and Increase Information Quality
Where possible, you should consolidate non-revenue generating, administrative tasks into Shared Service Centers. With Shared Service Centers, you can: Eliminate redundant processes Utilize self-service Automate processes Standardize common business practices to reduce costs Help create a consolidated view of essential global decision-making information Enhance the timeliness and accuracy of data. With consistent business processes throughout the enterprise, information can be gathered uniformly, with consistent quality
Services can be shared at many different levels, and shared service centers can exist for different reasons: General Ledger Centers Receiving Centers Inventory Management Centers Procurement Centers
Many of these centers may be combined into one center.
40
Upgrade Process: The R12 Functional Upgrade Requires Gap Analysis

The R12 Upgrade is not just a technical upgrade, it is a functional upgrade. The functional upgrade consists of mapping new business requirements with new functionality in R12 and determining the differences. This is called gap analysis. Gap analysis requires superusers/functional analysts to understand the new features of R12 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. Filling the gap is another term for aligning the business processes with Oracle Applications.
You should align the Business with the Process, and align the Process with Oracle Applications by considering the following: Application How has R12 changed? Is there new functionality that could improve the process model? Should we change our process to align with Oracle Applications processes? Do we understand Oracles long term strategy?
41
the little r12.1.3 upgrade essentials Process Integrate business changes with Oracle Applications new functionality Develop new process models. Retire/modify customizations that are replaced by new functionality Has my business changed? What are the new business requirements? What is the long term strategy for the business? Does the long term business model align with Oracle Applications long term strategy?
Business
Identify business areas that should adopt best practices that may differ from current business practices Align the Business Model with the Process Model and Oracle Applications
Aligning the business with Oracle Applications can be accomplished by modifying the business to match the process and customizing Oracle Applications to match the process. Most businesses are reluctant to change, and instead prefer to bring the process and applications into alignment with the business, as shown in the following diagram. Align the process and Oracle Applications to match the business
42
One of the best options is to convince the business to adopt vanilla processing and change the business and process to match the functionality provided by Oracle Applications. This works best for small and medium sized businesses, as large business may significantly benefit from customizations.
43
Upgrade Process: Assessments Can Help the Planning Process

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 requirements
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.
44
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. Reimplementation, 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.
45
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
46
Chapter 1 Plan to Upgrade 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.
47
Most users dont know how to restart a failed job. Therefore, if a concurrent manager is not set up with PCP, it will terminate running jobs upon failure. 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
48
Chapter 1 Plan to Upgrade MRP and other programs run much more quickly in a 64-bit database
Upgrade Process: Understand the Functional Financial R12 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.
49
Benefits include the new Subledger Accounting model, XML publishing applied to reports, additional DBI portlets and pages, AR-AP netting, and gross margin analytics in AR.
Subledger Currency Views

Accounting for subledger transactions at the event in a standard manner with a single accounting engine allows us to provide multiple accounting representations for a single event. A purchase can be simultaneously accounted for an increment to inventory for your US GAAP or IAS/IFRS accounting, and as a debit to the P&L for your national compliance accounting. The accounting entity involved can maintain multiple ledgers, each complying with a different set of accounting principles we call them accounting methods, and, of course, the transactions and ledgers can be valued and denominated in different currencies. You can now generate currency views of a ledger at the subledger transaction, general ledger transaction, general ledger balance, or consolidation workplace levels.
50
Multi-Org Access Control

Multi-Org Access Control (MOAC) enables companies with a Shared Services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of Shared Service Centers, as users and processes no longer have to switch applications responsibilities when processing transactions for multiple operating units at a time. Data security and access privileges are still maintained using security profiles that now support a list of 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 Multi-Org 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 the previous release, it will be set in Release 12. If you dont want to implement MOAC features in Release 12, no additional setups are required.
51
the little r12.1.3 upgrade essentials 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.
Upgrade Process: Build a Strong Upgrade Team

The Upgrade Team is not a democracy. The upgrade project management should not be shared. The upgrade team is composed of functional and technical representatives from the business and report to the upgrade project manager.
Dedicated Team Members

The Upgrade Team should be independent from daily operations. Team Members should be selected from the business by the upgrade project manager.
52
Upgrade Roles and Responsibilities
Technical Upgrade Responsibilities

The DBAs and Developers are in charge of technical testing and should try to improve the technical foundation of the hardware and software. The DBAs perform the technical upgrade and the developers modify and implement the new customizations and extensions. Developers should work with the functional analysts to understand the existing customizations. The functional users should work with the developers to help them understand how new requirements affect the existing customizations. Much of the developers work, coding and testing, is done in advance of the upgrade weekend. During the upgrade weekend the developers have 4-6 hours to implement and test customizations. Developers may need to practice rapidly implementing the customizations. DBAs, Developers, Functional Analysts and Testers should all try to reduce downtime. Consider having two upgrade DBAs for the project; 1 to handle cloning, and 1 to handle customizations. While you don't need all these DBAs during the whole upgrade project, they need to be proficient at their section of the work. Cloning can be complex and may have cloning tasks that are specific to your environment. If you are working with consultants on the upgrade, it is best if one of your internal employees handles this part of the work.
53
the little r12.1.3 upgrade essentials If you have customizations, usually the developers can't (and probably shouldnt, for separation of duty reasons) implement customizations; they need a DBA to handle this. On upgrade weekend, dealing with customizations is a significant task. When the DBAs are at the end of their rope, you need someone awake and responsive to handle the customization tasks. Otherwise, an overworked, overtired DBA may make mistakes. Finally, you need two DBAs that can tag team effectively during the upgrade and keep the upgrade running. Often, one DBA will be tasked with email and communications while the other DBA works through the upgrade tasks. Sometimes, they may even get some sleep.
Functional Upgrade Responsibilities

Functional responsibilities include testing the business use of Oracle Applications. In order to be an effective functional analyst, you must understand the AS IS business process model and the TO BE process model. Functional analysts should document the gap between the business process and the Oracle Applications processes, and: align the business and Oracle Applications understand existing customizations understand how new requirements affect the customizations investigate, improve and implement setups train the users for example, iProcurement reduce downtime verify the upgrade
Upgrade Project Manager Responsibilities

Manage the following managers: Development Manager Customizations DBA Manager Technical Upgrade Systems Manager Hardware Upgrade Functional Superusers Develop Process Alignment Functional Business Process Experts
54
Chapter 1 Plan to Upgrade Testing Manager Report progress of priorities as established by the Steering Committee
Steering Committee
The Steering Committee is quite often established as a democracy with the CIO and CFO having veto power. The Steering Committee has some very important responsibilities: maintain executive support, supervise the gathering of user requirements, document upgrade success factors, and prioritize goals/issues. The Steering Committee should also measure progress against user success factors and report to the executive team. The Test Manager can work with the Steering Committee to organize users to execute test scripts, and document users issues.
Upgrade Tactics
Release 12.1 upgrades are complex, long running exercises filled with thousands of tasks that must be done consistently each time. Because of the massive opportunities to make mistakes, a strategy that minimizes backup/restore time is absolutely necessary. You need to minimize the amount of time and risk required to restore the old database and application tiers. You also need to simplify the tasks and minimize the time required to implement customizations. As you plan your upgrade, you should assume 5-10 iterations of the upgrade will be necessary to fix the issues encountered. As you approach the upgrade, consider these tactics:
55
the little r12.1.3 upgrade essentials 1. Minimize the time for each upgrade for everyone involved. 2. Simplify the R12.1 upgrade tools, data, project management, and architecture. 3. Consider the R12.1 upgrade to be an iterative process: measure, evolve, and optimize as you iterate, tracking changes carefully as they are made. 4. Build a strong foundation for the technical team: o Maximize IO bandwidth and minimize IO latency. o Use a machine that is faster than the current production system. Use another machine for testing and training. o Avoid doing an in place upgrade. o Give the Applications Tier and the Database Tier a large amount of disk space. 5. Build a strong foundation for the functional team: o Ensure adequate testing develop and execute test plans. o Consider your testing methodology for the R12.1 upgrade. Do you need Technical, Functional, and Load Testing? o Include training both before and after the upgrade, and provide exposure to an R12 system and tools early in the upgrade process.
Success Factors for Upgrade Project Managers
56
Chapter 1 Plan to Upgrade Project managers can feel some satisfaction, when they allocate the money and time required for the upgrade. However, without the right skills the upgrade will probably fail. Even with all the right skills, issues with teamwork can cripple the upgrade.
Time and Money

Companies whose staff is experienced with upgrades and has an efficient testing process may be able to complete the upgrade in as few as three months. Typically, upgrades take six to nine months and very large upgrades (number of users and number of customizations) may take longer than one year. An upgrade might cost: $1000 per user + $500 per iUser with $150K minimum (an iUser is a user of iExpense, iProc, OTL, etc) 20 full users + 400 iUsers = $220,000 Upgrade costs vary drastically depending on the number and type of customizations. This estimate typically includes customizations. This estimate does not include implementing new modules, hardware migration, etc. Categories and Range of the Percentage of the Total Budget
Budget Training Functional Analysis Technical Upgrade Customizations Testing Average Budget 10% - 20% 20% - 40% 10% - 30% 0% - 50% 15% - 30% Typical 10% 25% 25% 20% 20% $400,000 Upgrade Budget $40,000 $100,000 $100,000 $80,000 $80,000
The range of values is to allow for different levels of proficiency that may exist in an organization before the upgrade begins. For example, if the testing process in your company is well established and accurate, the minimum percentage of 15% of the budget should be acceptable.
57
the little r12.1.3 upgrade essentials Customization Costs Customization costs can inflate the lifecycle effort cost by at least 70%, when compared to non-customized systems. The actual complexity and required effort cost may be much higher
Skills
Organizations and their employees understand their business processes better than most external consultants. However, companies usually upgrade and/or consider business process changes relatively infrequently, for example, every five years. Consultants that focus on upgrades and implementations may not understand the detail of your business processes as well as your functional superusers, but they understand the new features of Release 12 and the resulting consequences for your business. They can work with your experts to efficiently identify existing and future functional gaps between your business process and the process Oracle Applications uses. Good consultants have exposure to many clients and can use this knowledge to suggest best practices based on similar clients. Identify Skill Gaps in Your Upgrade Team Your upgrade team should be capable and experienced with upgrades and should understand the new functionality of R12.1. The following four primary skills are critical to the success of your team: 1. Testing 2. Functional Analysis 3. Customizations 4. Technical Upgrade If your team lacks expertise in these skills, often the best way to get through an upgrade is to supplement your staff with upgrade experts; consultants who have been through several upgrades who can fill gaps in expertise and mentor and guide your teams to use established best practices. Upgrade experts understand the R12.1 new functionality and they can efficiently integrate your companys business processes and customizations with R12 and can help improve your testing processes and increase the probability of success for your upgrade. An additional way to fill gaps in expertise is to have functional consultants conduct formal training on-site, using client specific environments. This can reduces redundant learning curves that result
58
Chapter 1 Plan to Upgrade from multiple consultants providing new features training separately from the consultants that are providing the R12.1 gap analysis.
Teamwork
The upgrade will not succeed without TEAMWORK. Communication is essential. The upgrade team is not intended to be a democracy, but unwilling team members can slow down and cripple otherwise viable upgrades. The upgrade manager is responsible for picking the team members. He is also responsible for firing disruptive team members and replacing them with the best available team member. If the Steering Committee cant find a mutually agreeable internal candidate, sometimes a neutral external consultant can be the best choice. Teamwork is the concept of people working together cooperatively, as in a sports team. Many large, ambitious projects require that people work together, so teamwork has become an important concept in organizations. Industry has seen increasing efforts through training and cross-training to help people to work together more effectively and to accomplish shared goals, whether colleagues are present or absent. Team Obstacles There are a number of issues that can decrease a teams effectiveness: Infighting - Effective teams don't have to be made up of people who like each other, but there must be mutual respect. Without respect, misdirected energy can turn to bickering and undermining colleagues. Team members must be willing to set aside petty differences Shirking Responsibilities - When members avoid taking responsibility for both running of a group and for specific assignments, a team becomes a "pseudo team"; i.e., a team in name that consistently underperforms. Lack of Trust - If trust is lacking, members are unable to depend on each other. Critical Skill Gaps - When skills are lacking, teams flounder, members have trouble communicating with each other, destructive conflicts result, decisions aren't made, and technical problems overcome the group.
59
Minimize Risk There are a number of steps that a team can take to minimize risk: Improve Testing Proficiency - Test scripts should be run after each patch or clone in order to ensure accurate patching or cloning steps. If testing is not efficient, practice testing more often until critical tests can usually be completed in 4-6 hours. Enable Fast Backup and Restore - with block virtualization or snapshots. The key to fast, efficient upgrades is to do several upgrade iterations to identify and resolve critical issues. Cloning can become a major bottleneck during test upgrades, and especially during the production upgrade. The ability to restore in a few minutes saves time and money when compared to 4-8 hour restore times. Independent DBA and Developer Instances - Let the DBAs and Developers practice their piece of the upgrade in independent environments, separate from DEV or TEST. Reduce Scope - Decouple other projects from the upgrade: new modules, fix customizations, hardware migration, and new business processes. Load Test - to avoid career limiting, Go Live capacity issues, perform load testing if there is any question about system capacity. For example, if the upgrade includes implementing Oracle Time and Labor for a large number of employees - more than 1000 - then load testing is highly recommended. The Team Must Recognize Competing Priorities An upgrade is rarely just an upgrade it is tempting to pile on additional changes in order to accomplish as much as possible. Your team may have to decide about whether to include hardware migrations, data cleanup and data archival, new modules, and customizations in the upgrade plan. Hardware Migrations are generally outside the scope of normal upgrades, however, if well planned, hardware migrations can be accomplished with a little extra time and without too many extra testing cycles. Hardware migrations, depending on the size and whether disk snapshots are in use, can be completed with one extra day. Data cleanup and data archival are two tasks that should be on-going. It is especially important, in order to reduce the downtime, to perform data cleanup and data archival before the upgrade begins. Data errors
60
Chapter 1 Plan to Upgrade discovered during the upgrade should be investigated for possible bad processes and resolved. Implement new modules either before or after the upgrade as separate projects. In some cases, it makes sense to implement new modules during the upgrade. Customizations that have changed because of an upgrade must be migrated. When possible, use a separate project before the upgrade to investigate the feasibility of migrating customizations to a Service Oriented Architecture.
Success Factors for Functional Users

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
61
the little r12.1.3 upgrade essentials 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
Known Gaps
In our experience, the following gaps are encountered in typical R12 upgrades. By raising awareness of these gaps, planning for them, and proposing cost effective add-ons, a painful upgrade experience can be avoided entirely. Financial Reporting Gaps With an R12 upgrade, Client ADI is replaced by Report Manager for the publishing of FSGs into Excel. Client ADI used to allow users to produce ad-hoc FSG reports, but the new Report Manager was designed for storing point-in-time reports. Report Manager was not designed as an ad-hoc enquiry tool and does not allow users to easily define or modify reports. Users submit ad-hoc FSG or standard reports from the Report Manager, but they must re-create each template in a special editor before its first use. Also, while FSG reports are still published to Excel, HTML, PDF and text formats, submitting an FSG report from R12 becomes a five-step process, which increases report submission time compared with Client ADI. For complex reports, users relate that R12 submission takes up to five times longer per report than with Client ADI. Reports must be saved in a repository, where chronological instead of alphabetical storage makes access to recent reports difficult and counterintuitive. Clearing out reports is also time consuming and requires running a batch job to delete old reports.
62
Chapter 1 Plan to Upgrade Drill Down Restrictions Client ADI used to allow drill down to transactions for amounts in an FSG report published to Excel. The drill down feature displays journal entries associated with the amount queried and supports further drilling to related sub-ledger transaction details. R12 only supports account analysis and drill down for reports published through the Account Analysis and Drilldown function in Report Manager. Many users have found this function cumbersome and report an increase in time required for viewing data. Sorting and searching data are also time consuming and limited in scope. Limited Chart of Accounts Access With Client ADI, users had a graphical view of the chart of accounts (COA) hierarchy. This feature allowed users to understand and traverse the structure of each segment in the COA, which was especially useful for new employees. The graphical COA was replaced by a Java-based form in the R12 GL module that is now only accessible by system administrators and designated business analysts. For the feature to be accessible to all users, the form must be moved to an unrestricted area within the GL menu. MS Word Becomes the Report Layout Editor To produce ad-hoc reports without Report Manager, Oracle users can submit a Publish FSG Report request via the standard request submission form. While this method does allow users to produce any FSG report, the report layout templates used are built with Microsoft Word and do not offer the same flexibility as an Excel editor. Another complication is that all templates built using an Excel editor must be rebuilt in Word to use this report creation method.
Recommended Add-on Products

Excel-based Reporting Alternatives To fill the Reporting Gap from losing Client ADI with R12, organizations have turned to Excel-based reporting tools like GL Wand from Excel4apps. An Oracle Validated Integration solution, GL Wand delivers real-time GL data via direct link between Oracle and an Excel front end, which cuts many steps from the report creation process even beyond Client ADI. Companies using Client ADI have found that
63
the little r12.1.3 upgrade essentials Excel-based GL Wand makes an attractive option, both from a price and user acceptance standpoint. Because finance users have strong Excel skills, they easily create and modify ad-hoc reports in just minutes through the familiar Excel interface in GL Wand, without programming support. Reports are similar to those they are accustomed to from Client ADI, yet the process is much faster that with either Client ADI or the new Report Manager. GL Wands real-time results are obtained more quickly than with FSGs or boxed Oracle reports, allowing users to work more efficiently. With this Excel-based reporting tool, users can access up-to-the-minute GL data. Finance users can also drill into subledger transaction details in just a mouse click with GL Wand, which utilizes Oracles security settings to maintain appropriate data accessibility. They can quickly view set-up information relating to the GL, including the COA and its hierarchies. Users report that submitting ad-hoc reports that took 15 minutes with Client ADI and 45 minutes with Report Manager take less than five minutes with GL Wand, leaving more time for valuable analysis and less time for frustration. The IT staff also benefits from GL Wand on many levels. The software installs quickly with minimal IT intervention, and users typically perform upgrades. IT is also less burdened with programming required for reports, because finance users are self-sufficient in running their own queries and creating their own reports. For organizations already invested in customized FSG reports, a GL Wand conversion tool easily converts existing reports into Excel. Overall, it is important for users to take into account the effects of an Oracle EBS R12 upgrade, or even reimplementation, on the GL reporting process. Understanding these effects and identifying available solutions like GL Wand can not only satisfy the GL reporting requirements of finance users without impacting IT, but also improve financial reporting processes altogether. An intuitive product like GL Wand can easily be trialed with minimal effort during an upgrade project, validating the expected benefits prior to purchase.
64
Customizations
Customizations and Modifications can help align the business with Oracle Applications.
Customizations can save the business money by filling critical gaps in functionality and allowing the business to function more efficiently. However, the design, implementation, maintenance and upgrade of customizations are neither cheap nor painless. In many cases, new functionality that is standard in a newer release of Oracle Applications may replace some customizations. It is primarily the responsibility of the functional analyst to identify, document and eliminate customizations that are replaced by seeded functionality. All customizations should be identified and documented. Some customizations may be able to be migrated to Service Oriented Architecture (SOA) and provided as a web service. There are two basic flavors of Oracle Applications: 1. Out Of The Box, OOTB or non-customized, also known as Vanilla. Vanilla assumes that OOTB processes will work at least 80% of the time. Vanilla can be effective because the focus is on the true gaps that require customization. Gap analysis is more effective because the scope is narrower and scope creep will be less.
65
the little r12.1.3 upgrade essentials 2. Customized Oracle Applications. There are 19 different types of customizations, modifications, and extensions. Vanilla Applications may have modifications and extensions but will have very few customizations (objects that may be replaced during upgrades or patching).
Customized Oracle Applications assumes that more than 20% of the code will be custom. This requires analysts that understand the current and future business processes. This can require significant time spent understanding current process flows. Abstract thinking required for detailed gap analysis can be difficult for inexperienced upgrade analysts and lead to excessive scope creep. Simplification and alignment are more difficult without Customizations.
Cumulative Business Value of Small Business Productivity Improvements

Even small improvements in business process performance can yield large business savings over a 5-year period. This example illustrates how 1,000 employees over a 5-year period with a 2% improvement per worker results in $8 million in savings over 5 years. This equates to $400 million in labor costs.
Assumptions Number of employees Avg. Annual Fully Burdened Cost/Employee Employee Hours Worked per Year Time Frame (Years) 1,000 $80,000 2,000 5
Small improvements can yield large dividends over time. However, as the size of the operation decreases, the percentage improvement must increase in order to make the customization worth creating and maintaining.
66
Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations
In the following example of a small implementation, the initial implementation cost is $300,000. With annual operating costs of $1 million, the business was able to implement business process improvements that lowered operating costs by 10%. Over five years the business saved $500,000. The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations. In the fifth year the business completed an upgrade. The five year total costs are $250,000 for the customizations.
However, in this scenario the business was able to implement business process improvements that lowered operating costs by 20%. Over five years the business saved 1,000,000. The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations. In the fifth year the business completed an upgrade. The five year total cost savings are $250,000. Annual Operation Costs 1,000,000:
67
While cost savings is relative, this example illustrates the value of customizations in organizations that can effectively design and implement business process improvement and integrate those improvements with Oracle Application by using customizations.
Success Factors for Technical Upgrade Managers
The technical view of success depends on applying the correct patches in the right order, installing and configuring new hardware, and
68
Chapter 1 Plan to Upgrade 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.3 upgrade guide and the little r12.1.3 project plan have a list of all the patches that weve encountered in our upgrade classes and consulting engagements, 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 Release 12.0 Critical Patch Collections (CPCs), Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic Data Fixes (GDFs), CPUs, PSUs
Release 12.0 Critical Patch Collections (CPCs) Oracle Financials Release 12.0 Critical Patch Collections (CPCs) 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. See MOS Doc. ID: 557869.1, EBS: R12 Oracle Financials Critical Patches for links to the latest Critical Patch Collections (CPCs). 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.
For the Release 12.1.3 upgrade, the CPCs are applied after you install Release 12.1.1 with RapidWiz.
69
the little r12.1.3 upgrade essentials Oracle E-Business Suite Pre-install Patches According to MOS Doc. ID: 1448102.1, Oracle E-Business Suite Preinstall Patches Report [Video], The Oracle E-Business Suite Pre-install Patches Report provides a list of essential patches that you must apply in pre-install mode before upgrading from Release 11i to Release 12.1. This report serves as a single point of reference for upgrade-related patches that can ONLY be applied prior to running the main upgrade driver for Release 12.1. These pre-install patches help you avoid certain upgrade script failures, upgrade performance issues, and data corruption and upgrade integrity issues. These patches are merged with the R12.1 EBS Consolidated Upgrade Patch 1 (CUP1), Patch 7303029. The patchlist may be updated monthly by Oracle, so you should re-check the list periodically during an upgrade. Recommended Patch Collections (RPCs) See MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) for links to the latest recommended patches by Oracle Development after the EBS 12.1 was released. Oracle E-Business Financials Recommended Patch Collections (RPC) for R12.1.3 are consolidated critical patches that all Release 12.1 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Cash Management, Collections, E-Business Tax, Financials for India, Fixed Assets, General Ledger, Internet Expenses, iReceivables, Loans, Payables, Payments, Receivables, and Subledger Accounting. According to MOS Doc. ID: 954704.1, the RPCs are created with the following goals:
Stability: Address issues that occur often and interfere with the normal completion of crucial business processes, such as period close--as observed by Oracle Development and Global Customer Support. Root Cause Fixes: Deliver a root cause fix for data corruption issues that delay period close, normal transaction flow actions, performance, and other issues. Compact: While bundling a large number of important corrections, we have kept the file footprint as small as possible to facilitate uptake and minimize testing.
70
Reliable: Reliable code with multiple customer downloads and comprehensive testing by QA, Support and Proactive Support.
If a RPC becomes available after you complete your upgrade, you should research the RPC and consider implementing it at some point to your environment. Generic Data Fixes (GDFs) Generic Data Fixes (GDFs) are patches created by Oracle Development to fix data issues caused by Bugs/Issues in the Application Code. See MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic to Validate Data Related to Invoices, Payments, Accounting and Suppliers [Video]. Also see MOS Doc. ID: 874903.1, What is a Generic Datafix Patch (GDF) and what GDFs are available for Payables? [Video]. Note that Oracle includes an important point in MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic (MGD) to Validate Data Related to Invoices, Payments, Accounting, Suppliers and EBTax [VIDEO]:
IMPORTANT: In conjunction with the diagnostic described in this note, R12.1 customers should review the notes indicated below which describe the Recommended Patch Collections (RPC) for related products. The vast majority of the data integrity issues detected by this diagnostic could be proactively avoided by applying the RPC's for these products: Doc ID 1397581.1: R12.1: Payables Recommended Patch Collection (AP RPC) Doc ID 1481235.1: R12.1: E-Business Tax Recommended Patch Collection (ZX RPC) Doc ID 1481221.1: R12.1: Payments Recommended Patch Collection (IBY RPC) Doc ID 1481222.1: R12.1: Sub Ledger Accounting (SLA) Recommended Patch Collection (XLA RPC)
Note that the list of MOS documents may change as RPCs evolve, so check MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) to track the RPCs. 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
71
the little r12.1.3 upgrade essentials 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. This new type of patch collection was introduced in July, 2009. See My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs. 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. Use Patch Wizard from Oracle Application Manager (OAM) The E-Business Suite includes a tool called Patch Wizard that is part of Oracle Application Manager (OAM). You can use Patch Wizard to help you determine if there are available recommended E-Business Suite patches. Patch Wizard will even automatically download them, which is easier than locating the patches through My Oracle Support and downloading them from there. While Patch Wizard does have its flaws it does not currently, for example, locate prerequisite patches it does make the research effort less painful and does find a good percentage of patches. We use Patch Wizard in two critical areas of the upgrade, for the Release 11i Mandatory Extended Support Patching Exercise, and after upgrading to Release 12.1.3, to find additional patches that have yet to be uncovered.
72
Chapter 1 Plan to Upgrade Use Patch Wizard for the Release 11i Mandatory Extended Support Patching Exercise As part of the preparation for upgrading to Release 12, we recommend that E-Business Suite clients bring their Release 11i environments up to the standards documented in My Oracle Support Doc. ID: 883202.1. This document describes a substantial collection of patches needed to ensure that Oracle Support will provide Extended Support for your Release 11i environment while you are working to upgrade it to Release 12. Meeting the Extended Support requirements is no small feat most customers have to apply dozens of patches, many of them with daunting pre-requisites and post application steps. If youve lagged behind on maintaining your Release 11.5.10.2 environment, the Mandatory Extended Support patching effort will take several weeks, and will require considerable testing. There are two ways to figure out what patches to apply you can build a spreadsheet and use MOS Doc. ID 883202.1, which tells you all the patches that need to be applied across all modules, or you can use Patch Wizard to tell you what it thinks you should apply. Weve covered the details in our other book, the little r12.1.3 upgrade guide, about how to set up Patch Wizard so it limits its recommendations to just those modules that you have licensed, rather than all 200+ modules. Weve applied the Release 11i Mandatory Extended Support Patches both ways, using the MOS document and using Patch Wizard, and weve concluded that we prefer using Patch Wizard. The tool is not as streamlined for Release 11i as it is for Release 12, but it still gets the job done. Use Patch Wizard After Youve Upgraded to Release 12 and Think Youre Done, But, Sadly, Find That You are Not We recommend that when you finish your upgrade to what you believe is the latest version of 12.1.3, with all the patches and Family Packs identified from patchsets.sh, our other book, the little r12.1.3 upgrade guide, and your own research, you should run Patch Wizard again to see if additional patches are found. When we ran a Vision upgrade in February, 2011, Patch Wizard identified 78 more patches above and beyond everything we found for 12.1.3. Note that Patch Wizard may require patches for both Release 11i and Release 12.
73
the little r12.1.3 upgrade essentials Other Patching Reports As well as the patching reports provided with Patch Wizard you can use enhanced reports provided by other vendors. For example, ConfigSnapshot includes reports that show the functional name for affected components, such as forms and reports, making it easier for the team to determine which areas should be the focus of testing.
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.
74
The Testing Process

The testing process extensively uses backups, restores and clones to recreate test environments from upgraded instances.
Create Custom Development Upgrade Plan

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 Remove old obsolete code before the upgrade Check invalid objects for source of old code
75
Tasks to be included in the development upgrade plan:
the little r12.1.3 upgrade essentials 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 CEMLIs, 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 tables 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.
76
Chapter 1 Plan to Upgrade Personalizations are an example of modifications that should not be replaced or altered by the upgrade, but again, if a table upon which they rely is changed, the personalizations will likely have to be revisited. The diagram below illustrates the relationship of customizations, modifications and extensions to the upgrade.
Obsolete Technology Components with Release 12

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.
77
the little r12.1.3 upgrade essentials 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.
78
Joining Functional and Technical Views

If we join the functional and technical views of the upgrade below on customizations, we get the following unified view of the upgrade:
Since the customizations the functional users have defined is the code implemented by developers, we should be able to superimpose the customization object to illustrate the relationships between the three primary perspectives.
79
Upgrade Success Without Customizations

Its obvious that upgrades without customizations are easier. The area of the intersections is greater in the following example without customizations, than in the earlier example that has customizations. This illustrates that the upgrade has a higher probability of success without customizations.
Tools of Choice for Rooting Out Customizations

One of the hot topics at every E-Business Suite conference that we attend has to do with customizations. The process of determining what customizations have been made and then deciding what to do about them is a challenging one. We looked at the E-Business Suite to see if there were tools that might help with customizations, and found a few, and we also looked at third party vendors to see if they had any options. One tool that we like is Oracles EBS Data Model Comparison Report, which is described in Steven Chans Identifying Data Model Changes Between EBS 12.1.3 and Prior EBS Releases and in MOS Doc. ID: 1290886.1, EBS Data Model Comparison Report Overview. For those of you who are upgrading from Release 11.5.10.2 to Release 12.1.3, this tool will list the database object definition changes between the two versions. Of course, if youve been consistent in keeping your customized reports and forms in a $CUSTOM_TOP area, then that will help. But there are other types of customizations that are not so easy to discover. Can you
80
Chapter 1 Plan to Upgrade determine if your menus have been customized? How about your responsibilities, your profile options, or your value sets? To help in that area, were now using 2e2s ConfigSnapshot. ConfigSnapshot identifies and documents configurations and configuration differences in the E-Business Suite over time, across instances, entities and even versions. Key features include: Ability to automatically generate BR100 style configuration documents (modules and technical development work) Configuration baselines and built in planning capability allow you to manage the introduction of enhancements and the setup of mandatory new features Clearly identify your configuration settings separately from the Oracle seeded values Directly compare configuration settings of the Oracle modules and technical components across environments, operating units, sets of books, inventory orgs, etc. View patch impact, which makes it easy to focus testing on actual changes introduced Identify upgrade impact reduce risk and uncertainty (shows any effect to your existing setups, new/obsolete data fields, new seeded data, table changes, etc.) Review and track key Oracle licence compliance metrics Identify and track customizations Audit & Compliance support user access control/ visibility, configuration change tracking, etc. Easy to install (5 minutes) and intuitive to use Cost effective
ConfigSnapshot provides the capability to automatically detect the majority of customization types. In addition, it provides a Customization Impact Analysis process that will check every identified customization for references to objects that Oracle has indicated have changed between versions; this is based on Oracles EBS Data Model Comparison Report. Rather than having to manually review all of your code searching for changed objects, this can now be done automatically. As well as listing the affected objects it has found, the impact analysis will even show you where in the code you have included the objects.
81
the little r12.1.3 upgrade essentials This allows technical resources to focus straight away on how the code should be updated to function correctly in the upgraded environment. Last of all, we recommend research on My Oracle Support, and training. TruTek offers classes that describe the new features of Release 12. Our instructors particularly enjoy working through students real life examples, and have commented that oftentimes E-Business Suite Release 11i customers are using workarounds and customizations for functionality that is already available as part of Release 11i. We can also bring our instructors onsite for consulting engagements, where they can help your functional users determine if a customization really is needed in the Release 12 world.
82
Chapter 2 Prepare to Upgrade

1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade
Failure is natures plan to prepare you for great responsibilities Napolean Hilll
Practice Testing
To prepare for 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

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:
83
the little r12.1.3 upgrade essentials Upgrade the Database to 11.2.0.3 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 upgrade 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 Supply Chain Management
See My Oracle Support Knowledge Document 604893.1, R12: FAQ for the SLA Upgrade: SLA Pre-Upgrade, Post-Upgrade, and Hot Patch. A historical data upgrade depends on the product. For some products, only SLA data will be upgraded, and for others, both transactions and accounting data will be upgraded. Implementation is a two step process: 1. Set the range of periods of the historical data to be upgraded before the R12 Upgrade and run the pre-upgrade concurrent programs 2. Run the SLA post upgrade (upgrade by request option) after the R12 upgrade Review Appendix G in Oracles R12 Upgrade Manual for more details
Default Upgrade Periods - Minimum Downtime Upgrade

During the upgrade, existing accounting data from the subledgers (AR, AP, GL) is upgraded into the new Oracle Subledger Accounting (SLA) data model. By default, the upgrade migrates data for the current fiscal year and the periods of the previous fiscal year that are necessary to ensure there are at
84
Chapter 2 Prepare to Upgrade least six periods in the upgrade (if the upgrade is performed in the first half of the fiscal year).
Install the SLA Pre-Upgrade Concurrent Program

To change the default number of periods of historic data to be upgraded: Apply Patch 5233248 to your Release 11i APPL_TOP Submit the SLA Pre-Upgrade Concurrent Program
Run the SLA Pre-Upgrade Concurrent Program

When submitting this program, enter the following parameters: Migrate all Sets of Books: 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
85
the little r12.1.3 upgrade essentials 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.
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
86
Adjustment Periods
The accounting period under consideration must be a NONAdjustment 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 non-adjusting 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.
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 cause 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.
87
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.
88
Optimize
One of the most important goals of the optimize phase of the upgrade is to reduce the downtime of the upgrade. Optimization affects postupgrade 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, the stage is set 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
89
the little r12.1.3 upgrade essentials 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.3 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.
90
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 downtime window. Path B Path C If the DB already at 11gR2, Apps 11.5.9.2 or 11.5.10.2 Only upgrade the Apps Stack Upgrade the DB & Apps in different phases
Technical Upgrade Flow
This guide assumes we start with Release 11.5.10.2, but the following upgrade paths show how to upgrade from earlier versions of Release 11i. Implement OATM and upgrade the database to the highest compatible level.
91
Release 12.1 Upgrade Paths

Initial Release Interim Release Final Release R12 Patch 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.0** 12.1.1 12.1.1
Release 12.0.0
4440000
Release 12.0.4
6394500
Release 12.1 Release 12.1.2 Release 12.1.3
6678700 7303033 9239095
* includes CU1 and CU2 (consolidated update) ** use Release 12.1 CUP 1 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 following diagram show the primary upgrade paths between versions of Oracle Applications. Most EBS customers are
92
Chapter 2 Prepare to Upgrade 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.3 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.3.
Upgrade Paths for Oracle Application Versions
Database Upgrade Requirements

Release 12.1 12.0 11.5.10.2 11.5.9.2 11.5.7 Certified Database Versions on Solaris 10gR2, 11gR2 and the 64 bit versions 10gR2, 11gR2 and the 64 bit versions 10gR2 or 11gR2 and the 64 bit versions 10gR2 and the 64 bit versions 8.1.7, 9.0.1 9.2, and 9.2-64 bit
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.
93
the little r12.1.3 upgrade essentials 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.3, 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.3.
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
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 effect 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, during the last weekend of the month, functional analysts are getting ready to close the books. The middle two weeks of the month
94
Chapter 2 Prepare to Upgrade 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 is on a 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.
95
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
96
Chapter 2 Prepare to Upgrade Developer Testing 2 hours Backup the Upgraded instance 2 hours User Acceptance Testing 8 hours Restore the Backup if Testing was destructive
97
98
Chapter 3 Perform the Upgrade

"Resolve to perform what you ought; perform without fail what you resolve." Stonewall Jackson 1824 - 1863 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 the upgrade Use Gather Auto option Record timing for each step during the test upgrade Drop MRC schema before the R12 upgrade Add the PL/SQL no compile option in R12 upgrade driver to save time during upgrade
99
the little r12.1.3 upgrade essentials Add extension plsql_no compile yes line in the upgrade driver file to enable the PL/SQL no compile option
Optimal Number of Workers

At TruTek, 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. We recommend setting 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 following considerations in choosing the optimal number of workers: 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 noninteractive 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
100
Chapter 3 Perform the Upgrade The software installed by RapidWiz includes all the application tier filesystem 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 include nocompiledb, nocompilejsp, and 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.
AD_TASK_TIMING
The following is an example of the rows in the ad_task_timing table that have the largest elapsed time. The time to run each job is recorded in this table. The most time consuming jobs are jobs that compile invalid objects. By keeping track of the times, its possible to identify jobs that have encountered some new problem. Large amounts of data will cause some jobs to run for a long time. Some of these jobs can be run in advance, as mentioned in the next section, Reducing Downtime.
JOB_NAME adobjcmp.sql adobjcmp.sql adsstats.sql adstatrp.sql adpcpcmp.pls adpcpcmp.pls adobjcmp.sql adpcpcmp.pls invmenu.ldt PRODUCT PROGRAM ad ad ad ad ad ad ad ad inv AutoPatch AutoPatch AutoPatch AutoPatch PHASE elapsed time hrs 27 79 346 346 5.652222222 2.133611111 1.908888889 1.908888889 1.842222222 1.768611111 1.758055556 1.656944444 1.288333333
AutoUpgrade 12 AutoUpgrade 12 AutoPatch 346
AutoUpgrade 12 AutoPatch 41
101

JOB_NAME ontmenu.ldt afoamadmmenu.ldt ozfmenu.ldt akdatsb1.drv oksmenu.ldt fndwfusermenu.ldt iexmenus.ldt PRODUCT PROGRAM ont fnd ozf ak oks fnd iex AutoPatch AutoPatch AutoPatch PHASE elapsed time hrs 41 41 41 0.978888889 0.870555556 0.806111111 0.802222222 0.783055556 0.598333333 0.523055556 0.4675 0.419166667 0.419166667 0.412222222
AutoUpgrade 20 AutoPatch AutoPatch AutoPatch AutoPatch AutoPatch AutoPatch AutoPatch 41 41 41 41 25 41 2
systemadministratormenu.ldt fnd fem_xdmi.odf oamdiagbasemenu.ldt bermind.sql fem fnd ben
Reducing Downtime
JOB_NAME facpupg.sql glrsgup2.sql PRODUCT PROGRAM FA GL AutoPatch AutoPatch PHASE elapsed time hrs 245 244 0.005277778 0.010833333
Fixed Assets has a potentially long running sql script, facpupg.sql. The script is run by AutoPatch (adpatch) and takes about 19 seconds to run in our upgrade. The script takes so little time to run that it should be run during the downtime window and would not save a significant amount of downtime if run in advance. You, on the other hand, may have a very large Fixed Assets environment, so as part of the testing you should look at how long programs take to run to decide if any downtime reducing steps are worth trying. AutoConfig has large elapsed times during the upgrade and can be run after the upgrade in parallel mode in order to further reduce downtime.
AutoConfig in Parallel Mode Across Multiple Nodes

The ability to run AutoConfig in parallel across multiple nodes was introduced in the TXK 12.1.1 Consolidated Patch. This feature reduces maintenance downtime. AutoConfig can be run in parallel mode by issuing the following command: On the Applications tier:
102
Chapter 3 Perform the Upgrade perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> [product=<product_top>] parallel On the Database tier: perl <ORACLE_HOME>/appsutil/bin/adconfig.pl contextfile=<CONTEXT_FILE> parallel When running AutoConfig simultaneously on multiple nodes, the parallel option must be specified while starting AutoConfig on every node. Otherwise, the execution of AutoConfig processes on individual nodes will not be synchronized, and may result in an inconsistent file system or database.
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 MOS Doc. ID: 399362.1.
103
104
Chapter 4 Finish the Upgrade

We rate ability in men by what they finish, not by what they attempt Anonymous
The Importance of Testing

Without adequate testing of both Oracles Application code and especially your custom code, including your use of Oracles built-ins, you run a high risk of your Oracle Application processes not working in your newly upgraded environment. You MUST test; there is really no way around it. Even if you have little or no customizations, there is no guarantee that the newly delivered Oracle Application code will work with your organizational processes. Unit and system testing can take a significant portion of time, and therefore are often skipped, only to end up extending the overall project timeline because of the need to redo and retest. Consider using an automated testing approach to radically improve testing productivity and provide a quality driven process. 100% automation may not be achievable but testing automation can significantly reduce the normal testing bottleneck most companies run into, and in the long run save a significant amount of time and money.
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:
105
Functional Testing
Functional testing is 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 include: Develop test scripts Execute test scripts Perform unit and integration tests Test customizations
Be sure to 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
106
Identify the primary workload
Chapter 4 Finish the Upgrade 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 EBusiness Suite Release 12 test scripts, incorporating any customizations, and performing regression testing. 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 E-Business Suite
107
the little r12.1.3 upgrade essentials Upgrade Guide, Release 11i to 12.1.3, Part No. E16342-03. 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 Supplier and Customer Balance Subledger Accounting Daily Journal Report Account Analysis Report Third Party Balances Summary by Account Third Party Detail and Balances by Account Report
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. 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 Tax-based calculation is consistent with the previous calculation.
108
Chapter 4 Finish the Upgrade
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:
109
the little r12.1.3 upgrade essentials 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
110
Chapter 4 Finish the Upgrade 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.
111
Conclusion
Don't cry because it's over. Smile because it happened. Dr. Seuss Thats right, when all is said and done, you should have an upgraded system, an exhausted staff ready to celebrate, and, perhaps, some followon work. Follow-on work? you say. Yes, the work of the E-Business Suite Upgrade Team is never really done. Oracle will continue to publish fixes for problems you didnt even know you had. There will continue to be evil ner do wells out there, trying to break into databases, so you will continue to have to apply and test the quarterly Critical Update Patches (CPUs). New functionality will surely come about, as will performance patches and patches that your company simply cant live without. Take it in stride, and remember that we at TruTek are a hardworking band of consultants and trainers who understand what youre going through and would be happy to help you work through the details.
www.trutek.com 801-486-6655
113

TruTek Little r1213 Upgrade Essentials 03-15-2013

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TruTek Little r1213 Upgrade Essentials 03-15-2013

Caricato da

Copyright:

Formati disponibili

the little r12.1.

3 upgrade essentials for managers and team members

the little r12.1.3 upgrade essentials

the little r12.1.3 upgrade essentials

Recommended Add-on Products .............................................................63

the little r12.1.3 upgrade essentials

E-Business Tax Verification Tasks ........................................................108

Payments Verification Tasks .................................................................109

the little r12.1.3 essentials for managers and team members

The Big Picture

TruTek Release 12.1.3 First Pass Upgrade Onsite Training

Release 11i Extended Support Mandatory Patching Consulting Engagement

TruTek Release 12.1.3 Ongoing Technical Support

TruTek Release 12.1.3 Functional Upgrade Readiness Assessment

TruTek Functional Upgrade Support

TruTek Testing/Quality Assurance Support

TruTeks Release 12.1 Books

the little r12.1.3 upgrade essentials

the little r12.1.3 upgrade essentials

the little r12.1.3 upgrade essentials

Reimplementation not! There are several reasons why you might

Customizations tracking down those extra reports that youve

Reporting - Excel4apps GL Wand is an award-winning, Excel-based

the little r12.1.3 upgrade essentials

Performance Tuning - Confios Ignite 8 is a comprehensive

Chapter 1 Plan to Upgrade

Why Might a Business Decide or Hesitate - to Upgrade?

Chapter 1 Plan to Upgrade

Decision: Reimplement vs. Upgrade

Upgrade vs. Reimplementation

Transform and Upgrade with eprentise

Traditional Migration Approach (Reimplementation) Pros

Remodeling Approach (eprentise software + Technical Upgrade) Pros

the little r12.1.3 upgrade essentials

Traditional Migration Approach (Reimplementation)

Remodeling Approach (eprentise software + Technical Upgrade)

Traditional Migration Approach (Reimplementation) Cons

Remodeling Approach (eprentise software + Technical Upgrade) Pros

Chapter 1 Plan to Upgrade

Traditional Migration Approach (Reimplementation)

Remodeling Approach (eprentise software + Technical Upgrade)

Chapter 1 Plan to Upgrade

11i Not Upgradable

ly restr read-on tance set ins n u s Create

Customer Load 11i Data History

Implement New E-Business Suite

h efore nce b ty insta

R12 Data Seeded Configured

Oracle 11i R12 Upgrade

11i Data 11i Data 11i Data

Oracles Reimplementation Tools

iSetup - can migrate functional setups from one E-Business Suite

the little r12.1.3 upgrade essentials

Other Third Party Tools That Help Reimplementation

Chapter 1 Plan to Upgrade

ConfigSnapshots migration capabilities allow customers to migrate setups across environments/entities.

the little r12.1.3 upgrade essentials

Chapter 1 Plan to Upgrade

Capability Maturity Model

the little r12.1.3 upgrade essentials

Upgrade Benefits: An Opportunity to Optimize Your Hardware Configuration

Chapter 1 Plan to Upgrade

the little r12.1.3 upgrade essentials

Upgrade Benefits: Improved Oracle Tools Simplify the Process