Tips for your Oracle R12 Upgrade - Client Scenarios
Some real case customer scenarios looking to upgrade towards Oracle R12, Happy new year!
Sent: Friday, December 3, 2011 2:24 PM
To: Alex Antonatos
Subject: Advice on R11 upgrade to R12
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.
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
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)
Sent: Thursday, November 10, 2011 5:21 PM
To: Alex Antonatos
Subject: SAP, EBS R11 and R12 ERP instances
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
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?
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.
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
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.
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)
· 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).|
Don't under estimate the LOE
|Usually longer, and in some cases, need to be designed from scratch due to significant data model changes.|