Tips for your Oracle R12 Upgrade - Client Scenarios

on Tuesday, 01 January 2013. Posted in Enterprise Software , Blog

Some real case customer scenarios looking to upgrade towards Oracle R12, Happy new year!


 

From: XXXXX
Sent: Friday, December 3, 2011 2:24 PM
To: Alex Antonatos
Cc:
Subject: Advice on R11 upgrade to R12

Hello Alex,

 I am a reader of your blog, enjoy the content. We have embarked in upgrading our R11 instance 

We face issues on patching, can we arrange a call to discuss, would like to hear your expert advice on our situation,

We operate in 27 countries mostly EMEA, Asia and few sites in North America.

Kind regards, 

______________________________________________________________________________________________________________________________________________________ 

As we all learned upgrades are always time-consuming and complex, so anything that makes the task easier and reduces the downtime needed is worth investigating.

 

Upgrading From EBS R11i to R12 Using a Staged System

 ugstagedsys 

 

The way this works a staged Applications system represents an exact physical copy of a production system, including all APPL_TOPs and the production database.

You can apply patches to a staged system while the production system remains in operation. After that, you connect the staged system to the production system,

update the database, and synchronise the APPL_TOPs. This means that the downtime for the production system only needs to begin after all patches have been successfully applied to the staged system.

After the patches have been applied to the staged system, and the production system updated, you must export applied patches information from the staged system and import it into the production system.

This ensures that the production patch history database is up-to-date.The principles of using the staged approach for upgrading are simple: after meeting the applicable AutoConfig and Rapid Clone patch prerequisites,

you create the R11i staged system.

You then upgrade the staged system to R12.1.3 by updating the production APPL_TOP and database. Finally, you synchronise the patch histories of the production and staged systems.

Feedback received for above mentioned client shaved up to 10 hours from cutover plan.

Metalink note for more information:Using a Staged Applications System to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Doc ID 734025.1) 

 

   


From: XXXXX
Sent: Thursday, November 10, 2011 5:21 PM
To: Alex Antonatos
Cc:
Subject: SAP, EBS R11 and R12 ERP instances

Hello Alex, 

 

We bought a company and we need to replace SAP with Oracle EBS:The following Oracle Modules will replace SAP.

Financials: GL,AP, AR, FA, PA

HRMS

Discrete manufacturing INV, BOM, MRP, WIP

Order Management and Procurement

Where do we begin with the migration of data?

We are a conservative global company, what plan/approach/timeline do you recommend for the upgrade?

Thank you,

__________________________________________________________________________________________________________________________________________________________________________________

Data

In my experiences with SAP this type of migration of data is better served using a third party tool, you should look into more4apps.com excel based suite of software, ideal in this situation to empower the users in deciding on what to take across from SAP into Oracle.

Plan/Timeline

Once support exists for the R12 Upgrade and the Business is on board, since this will take a lot of their time. 

Here is my rule of thumb that i would use as a baseline using this clients footprint , they have 22 EBS modules in production:

R11 instance will little or no interfaces, extensions and reports, project plan of 4 months

R11 instance with some interfaces, extensions and reports(12-24 objects), project plan of 6 months

R11 instance with many interfaces, extensions and reports (25+ objects) project plan of 9 months

Approach

In this case what was recommended was as follows:The areas of technical below were outsourced to a specialized partner:

1) Understand installed components, system sizing information, NLS considerations
2) Prepare for upgrade using Upgrade Manual Script.
3) Upgrading to R12. This includes upgrading the database and applying the required patches through AutoPatch.
4) Post-Upgrade process. Complete the upgrade process by applying the latest patches to keep the system most current.
All the functional upgrade tasks, testing including uat, setups were all done internally.

Architecture

In this client scenario, what was recommended was to upgrade the R11 instance into a new instance of R12, then merge the instances using a consolidation project methodology. (below are the high level steps)

Consolidation Methodology

·         Proof of concept phase

·         Consolidation of AOL, general ledger modules

·         Consolidation phases

·         Standardization of globalsetups

·         Analysis of custom data model

·         Two practice runs to perfect consolidation process

·         Unit/System testing usingcompanies test cases

·         Functional testing using client specific test cases 

·         Documentation and execute the Multiple instance consolidations at the same time during second cycle

 ·         Data integrity scripts

·         Generalized custom scripts tovalidate the data integrityafter consolidate

·         Go Live

·         Project ends after firstmonth-end process

 

Once both instances are in one R12 EBS instance bring the SAP data into R12.

 Other factors to consider as part of the upgrade to R12 

Factors to Consider 11.5.10 to 12.1.3
Technology Stack Significant impact on the technology stack.
Database Upgrade Necessary in every case.
Additional Applications / Enriched Functionality Provide significant enhancements in features, in R12, also provides additional applications [e.g., Oracle R12. E-Business Tax, Sub-Ledger Accounting].
Opportunities for Process Improvements, Legacy Retirements Significant impact (e.g., ‘MOAC’ model in R12 enables a shared services platform; E-Business Tax – eliminates most of the localization patches).

Retrofits/Custom Components

Don't under estimate the LOE

Usually longer, and in some cases, need to be designed from scratch due to significant data model changes.

 

 

 

Comments (3)

  • Marsue

    Marsue

    21 January 2013 at 23:07 |
    Felt so hopeless looinkg for answers to my questions...until now.
  • Justin Brault

    Justin Brault

    22 January 2013 at 01:50 |
    We are currently upgrading thank you for sharing your experiences , your website is filled with excellent points.
  • avinash kumar

    avinash kumar

    19 February 2013 at 08:46 |
    Oracle EBS R12 upgrades & reimplementations are always a challenge, often taking longer and costing more than expected, because of many uncertainties.

    About Evosys: Evosys is an Oracle Partner providing consulting services for implementation and maintenance of Oracle Applications. We are a market-focused, process-centric organization that develops and delivers innovative solutions to our customers, consistently outshining other market players. http://evosys.co.in/r12

    For any Oracle Service, Business Partnerships, Sales Referrals, Collaborations & Tieups, Please contact business@evosys.co.in & we shall contact you immediately.

    Contact Business@evosys.co.in

Copyright 2015 Appsconsultant.com. All rights reserved.