12 Steps to R12

Date: 16th August 2010

During the Oracle OpenWorld 2009 in San Francisco, the average conference session started with “How many of you are on R12?” The show of hands was no more than 5% in any given session. Recent research suggests only 5% of companies are on R12 as of mid 2010.

Many organizations will be starting the journey to R12 in 2010, given the end of Premier Support for in November 2010. Our organization successfully completed an Oracle E-Business Suite Release 12 Upgrade (R12) in August 2009. This article shares our experiences so that readers can benefit from what we did right and avoid what we did wrong.

Following are the twelve steps our organization followed during its R12 upgrade, along with suggestions and insights that others might use in their own upgrade projects.

Step 1 – R12 Study

It is recommended that before doing an R12 Upgrade, you do an assessment/study to determine the impact an R12 would have.

Get a little funding, do test upgrades, an impact analysis, try the new functionality and then go for full funding of the project. This leads to a highly informed and carefully scoped project.

Many companies got burned very badly by early adoption of R12. If a study had been done first, I doubt they would have upgraded so early – saving a lot of time, money and heartache.

Step 2 – Business Case

The key foundation to any project is a good Business Case that everyone agrees on. It gets the funding, visibility and users onboard. Emphasize the benefits of improved Oracle Support and significant new functionality.

I would recommend that you keep the R12 Upgrade as much as possible a Technical Upgrade (utilizing new functionality where appropriate), but it is a daunting task and the fewer new things thrown in the better.


Step 3 – Planning and Preparation

There are a few things you should check prior to recruiting an upgrade team.

Make sure you have the hardware to do the upgrade. Your typical upgrade will require an extra 6-12 Instances and you still need 11.5.x instances for ongoing production support. Prior to bringing any expensive external resources in ensure you have R12 Instances to work on.

Write a detailed project plan. Figure 1 shows a very high level approach. Doing an upgrade is not rocket science…..the devil is very much in the detail. Remember you will need to schedule time with many different groups – Legacy, Data Warehouse, Business Users, DBA, Server Team and the ERP Team. During an Upgrade all major initiatives will need to stop to allow you to focus on R12, so be sure to set user expectations in advance.

Recruiting – Each company varies on how they staff an upgrade. Unless you have a very good in-house team, you will need help. Consultants will save you time and money. R12 has a lot of new modules and functionality, so we brought in expertise. It really helped and knowledge was transitioned to our internal resources.

The DBA Team will take between 2-4 weeks to get an R12 instance, depending on their skills. Put this into your plan.

Doing a PM.010 – Project Management Plan helps you to focus, together with a solid Work Breakdown Structure. Together with a good Risk Register (brainstorm with your team) you’ll protect yourself from some of the pitfalls.

R12 is a lot bigger than any previous upgrade in Oracle ERP. Your plan should reflect this. Planning is everything for a successful R12 Upgrade.

 Figure 1 – 12 Steps to R12

Step 4 – Review and Design

A short amount of time reviewing what you have and what is new will vastly improve your upgrade. The Functional Team should use the R12 Upgrade Guides to identify the relevant changes in Functionality.

The Functional Team should also try to identify with the Business and Development Teams, customizations that can be removed with new functionality provided as standard. A little time doing this could bring significant savings.

There is significant new functionality in R12 and the Functional Team should review with the Business to show the possibilities. Keep a balance – the focus should remain on the R12 Upgrade, not new functionality.

The Functional Team should also be writing new MD.050 Functional Designs – there will be customization needed in R12 and other Functional Designs may need updated.

Working closely with Functional Team, identify the core customizations. Once you prioritize the customizations you have a solid basis for moving into the Build and Test Phase.

Step 5 – Build and Test

Functional Stream

The Team should prepare high level Test Plans, working closely with Business. The Test Plans should be comprehensive and signed off. This should cover all Test Scenarios across all Business Areas, including external systems.

Once the Test Plans are signed off, ensure that comprehensive Test Scripts are written. As these are being written, the application should be tested initially to throw up the bugs. The earlier you find bugs the earlier you get them to Oracle Support to get fixes.


Technical Stream

The Technical Team MUST have a customization register. This can be used as a very good monitoring tool. If you don’t have this, how do you know what to upgrade? Customizations should be upgraded methodically according to your plan from the Design phase.

Technical Summary – Our Customization Upgrade Impact

General Ledger    80%   Minor issues – Set of Books ->Ledger_ID

Self Service            30%    MOD*PLSQL Dessupported

Accounts Payable  30%   Change of Database Structure

Payments                  60%    Upgrade Check Formats

OA Framework         <5%  Minimal Issues

HRMS                            <5%  Minimal Issues

Payroll                          <5%  Minimal Issues

Procurement              <5%  Minimal Issues

Receivables/Fixed Assets <5%  Minimal Issues

Source Control

This is essential so if you are not using any tools, you are doing something very wrong and risking your Production System. Open Source tools such as Subversion are ideal.

Patch Management

One key consideration is your approach to patches – aggressive or conservative. We went on an early version of R12 (released one year previously) and we choose conservative thinking it would be relatively stable. Towards the end of the project, we saw stability still had not been reached. We moved to a highly aggressive patching strategy that really did get us to stability, although it was extremely painful with multiple regression tests and carrying considerable risk.

Reviewing Metalink is important – when new RUP’s (Roll-Up Patch Sets) and CPC’s (Critical Patch Sets) are released, you have a very important decision to make on whether to apply. If your well into your project, the advice I would give is not to apply unless required….patches cause a lot of issues. If the patch is newly released you’ll be the poor guys finding all the new bugs. Leave that to someone else.

Obviously if you have critical errors, pile the pressure on to Oracle Support to provide single patches. At some point you are going to have to freeze patches, otherwise you will never finish. Learn to work with Oracle Support and Oracle Management regionally to resolve issues.

Patch Management is critical and Oracle has some great tools for Patch Assessment under System Administration – these will allow you to make informed judgments on whether to apply patches or not. This will show all the objects changed by a patch – with that list your technical people can give you well informed advice.

Strong Patch Management is critical to any R12 Upgrade. Lose control on this and you lose control of your entire project.

Step 6 – Internal User Acceptance Test

An Internal UAT is basically a UAT but it is carried out by the R12 Upgrade Team, not the users.

Focus strongly on key functionality – if one thing has to work on Day 1 of Go-Live it has to be the key stuff – entering invoices, running a payroll, etc. Too many companies focus too much on the peripheral and not enough on the core functions. That will end in tears.

Given that some modules are going to be delivered before others into UAT, you may want to do this staged. It’s not ideal but it does compress the overall project time. You will have problems on Payables, and should that hold up your whole HRMS track? I would argue no. And I am sure some will disagree. But be pragmatic on the area of UAT and use your judgment.

Test the entire ERP and external systems such as Legacy, your planning systems, your banks or other external systems that interface to customers/suppliers/etc. All bugs should be recorded.

A few other tips:

      Simulate a close on your R11.5.10

      Reconcile 11.5.x and R12.x

      Simulate transactions half way through workflow

      Check your banks migrate correctly

Step 7 – User Acceptance Testing

Another clone of Production should be taken and all customizations/setup applied. If you have not been keeping deployment registers, setup documents, etc I would strongly suggest you start doing so. Give the users plenty of notice of when the UAT is coming and make sure you clearly set the expectations.

UAT kickoff meetings should be held and contact lists given to users. Your team will need to work hand in hand with the Business Users to co-ordinate the UAT. It’s going to be a lot of work with new, unfamiliar screens and quite a few complaints, no matter how well you’ve done till now. The Test Plans and Test Scripts should have been agreed months ago, with full review and signoff which should lessen the surprises (and complaints) users may have. Work closely with your users throughout the project from project initiation to way after go-live. That will lead to better relations and when you do encounter problems; users will go a lot easier on you, because you kept them informed right?

One trick here is to put the Test Plan on a shared drive and ask the user to mark Pass/Fail/To Test as they progress. As a Project Manager you can then review and summarize progress easily. Delivering some modules into UAT before others may be an option if you want to progress quicker. Others prefer to deliver the entire UAT. What I have found is that by progressing some modules quicker, it gives the project momentum and when you put out weekly progress tables to users, they don’t want to be last to finish. A little bit of Psychology certainly helps when doing an R12 upgrade.

Make sure all Test Scripts are tested. Make sure Month End and Year End are simulated, with proper reconciliations. Make sure all the systems to and from Oracle ERP are tested and continue to work with R12. Make sure integration between modules is smooth and working – organizing this across departments is tricky. A UAT room for this can be handy. Providing simple refreshments can create a good ambience and encourage your testers to work for you.

Record all issues and bugs as you go. Monitor closely and ensure that when your users are doing UAT, your R12 Team is there to assist. Some areas may need twice weekly meetings on certain modules with the Business Users. This will help to manage difficult UAT areas, stop user frustration and make the UAT a little less painful for all. We did this on Payables in particular. It worked extremely well.

One point – be pragmatic on UAT. Remember users have full-time jobs so doing a UAT is a big favor and usually a lot of extra work. Avoid being too pushy especially during stress points such as month-end closing and Payroll – that will simply be counter-productive.

The UAT can also double as a training ground, but do also be prepared to give additional training, especially in the areas of AP, Banks, Payments and Subledger Accounting/Reconciliation as there are significant differences here.

Step 8 – User Sign Off

On completion, ask the head of each area and other users to sign off a standard Acceptance certificate. As you achieve sign-off let everyone know – again it helps to push the other Business Areas that have not signed off. I found weekly newsletters (just a single page) kept everyone onboard. Openness and transparency is the key.

Step 9 – Transition Planning

As UAT goes on, you should be planning what will be a very complex and difficult cutover. The team should also be doing rehearsals by taking copies of production, upgrading, deploying, setting up and testing. All bugs should be recorded.

You should have deployment registers for each module, including tasks for DBA, System Admin, etc. These should be very detailed and concise.

Review the deployment registers and figure out what can be done in advance of R12. This saves time and will ease the stress of the upgrade weekend.

Call meetings with the users and make sure that the cutover is clear.  The users will lose Production for a few business days, unless you do it on a holiday.

We did the closing in R11.5.10 just before cutover, closing down all transactions, etc. Why? There were a couple of reasons. If data is left open in R11 (say unaccounted) it will give real problems in R12 Secondly it allows you a whole month before your first closing in R12 to resolve issues.

Get a register of who needs does what during cutover and ensure work is balanced. Ensure every person knows their role in the cutover.

Deployment of code is a significant task. If you have used Subversion (or another Source control system) then you can grab all changes and give to the DBA’s. A lot can be automated and this will save a lot of time on the cutover.

Talk to Oracle Corporation and make them aware of your key dates, cutover, month end, payroll, etc. They can get you critical support management over that time.

Try and do as many rehearsals as you can whilst users are doing UAT. The closer the rehearsal is to an exact recent copy of Production the better. We repeatedly cloned production for three weeks prior to Production and checked our deployment.

Make sure you do patch reconciliations between your UAT and Rehearsal databases on a consistent basis. Otherwise you may be testing on completely different Patch Sets and your entire UAT would be null and void.

As Project Manager, you should be writing a PM.030 Transition and Contingency Plan that covers all the angles.

Make sure you go to the Change Control Board, publicize on your website and make sure you tell every single person that needs to know that Oracle Applications will not be available. The Cardinal Sin – missing someone out.

If the cutover fails all the hard work of your team will have gone to waste. Do you really want to be telling everyone publicly (including Senior Management) that the nice, shiny R12 that was promised isn’t live and that you had to pull out the whole upgrade at the last minute due to your bad planning? 

 Rehearse, Rehearse, Rehearse……

Step 10 – Cutover

A cutover generally takes place over a four day window, depending on your database size/speef of servers/etc. Holidays are ideal but make sure you tell Business well in advance if their key system is going to be down during business hours. Total Upgrade time took 96 hours, working around the clock.

Users should run key reports on R11.x and then run the same reports immediately after on R12.x. Your functional team should also do a mirror reconciliation exercise quickly during the cutover. Also keep a reference environment copy of your R11.x production.

Wednesday evening and Thursday were days for the actual Upgrade, Friday the Upgrade Team rolled in to do setup, customizations, etc. Saturday and Sunday were for testing with a go-live decision on Sunday evening. As we were moving servers, our contingency was simple; if the cutover was a no-go we simply turned our old server back on……Don’t repeat the errors you made in rehearsals, keep a log of everything that failed and make sure it doesn’t happen on your go-live, as you simply won’t have time to troubleshoot.

Be very careful that all transactions are accounted, workflows complete (as much as possible), payments complete. Review the Best Practices from Oracle for more detailed advice. If you don’t do this you will hit serious problems.

Cutover is a stressful time no matter how well planned. The Project Manager should ensure everyone stays calm, ensure work is balanced and avoid burn-out for those working shifts. Organize some food during the cutover, step in to calm any friction quickly and monitor every last aspect of progress.

Step 11 – Critical Support Cover

There are going to be problems on anything of this scale. That’s a given. Have all teams on standby so that when issues arise, they can be addressed. As soon as possible clone production to a test system and simulate the payroll, closing and other key events in advance.

Before the Go-Live, set the expectations of users. If you do this the user community and management will cut you a little more slack and be more understanding of issues encountered. A little bit of psychology and transparency will go a long way to making your transition a lot less stressful.

One tip that is useful before go-live: Brief the Helpdesk on how to take the calls as you go live. Brief the users on how to log issues. Make sure there is strong reporting available to you in real-time showing all issues. Monitor this religiously. Make sure the escalation and support teams are in place, so calls are not lost or delayed. This will ensure you have a very strong support structure to deal with the significant number of issues you will have, irrespective of how well you did the upgrade.

No-one will remember all the hard work you have done to get here if major issues are not addressed quickly. If you manage problems well and quickly the Upgrade will be remembered as a huge success. If you don’t, you’ve just thrown away thousands of hours of your team’s reputation and hard work.

Strong and very well managed Critical Post-Production support is everything in an R12 Upgrade.

Step 12 – Post-Production Support Cover

After the first month end close you should be able to move to a more standard support footing.

Don’t celebrate the day you go-live. It could get extremely embarrassing to celebrate Mission Accomplished and then hit major problems, right? We left the celebrations for 6 weeks.  If you do an R12 Upgrade, you deserve a big party. R12 is the most challenging upgrade you will ever have done in Oracle ERP.

Those who fail to plan, plan to fail. Good Luck!!!

About the Author

Iain Robertson has been using Oracle Applications since 1990. Over 20 years in Oracle ERP starting in MPL7 through MPL8, 9.x, 10.x, 11.x and 12.0.4. He is currently working as a Program Manager running a team of 90+  in Asia Pacific, migrating complex Legacy Systems to Oracle Applications – Procurement, CRM, Financials, HRMS and Projects Suite. He also runs the Oracle Support Team. He has experience across Asia, Europe and the US, specializing in R12 and building world-class teams in Asia-Pacific providing Global Support.

You may contact Iain at irroberts@hotmail.com

Blog:               https://oracleprophet.wordpress.com

LinkedIn:        http://www.linkedin.com/in/iainrrobertson

#1 IT Service in the Company – 2008

Oracle Innovation Award Winner 2009 – ERP

Oracle Session Presentation Winner – Oracle Open World 2010

R12 Successes


Reference Material

To those authors who published articles I would like to give credit, for making an almost impossible R12 Upgrade possible by kindly sharing their knowledge, their successes and their failures for the benefit of the entire Oracle Applications community.

R12 Resources

       OAUG Website

      Chris Warticki’s Blog – EBS R12 Support Resources – Consolidated

       Oracle Applications Upgrade Guide: Release 11i to Release 12 (B31566-01)

       Upgrade Manual Script (TUMS) – Patch 5120936

       Metalink Note: 580299.1 – Best Practices for Adopting Oracle E-Business Suite, Release 12

       Metalink Note: 394692.1 Oracle E-Business Suite Upgrade Resources

       Metalink Note: 562887.1 R12: Helpful Tips for a Successful R12 Oracle Payables Implementation

       Metalink Note: 437422.1 R12 Troubleshooting Period Close in Payables

       Metalink Note: 73128.1 R12 Troubleshooting Accounting Issues

       There are many articles from Oracle Open World in 2008/2009 for R12 available at Oracle Open World Tools -> On Demand:


       Oracle Financials Applications Blog – R12 Lessons Learned

       Analyzing, Planning and Executing an R12 EBS Upgrade

       Rochester Institute of Technology – One Year after Upgrading our Oracle E-Business Suite from 11.5.9 to R12 – An Update 

      Talk to other companies that have done R12. Use the communities and forums.


6 Responses to “12 Steps to R12”

  1. Alberto K Says:

    Thank you for sharing this interesting article, our company is plan to move to R12 as well from R11i (, i’ve several questions regarding the upgrade:
    1. What are the considerations before we choose to Upgrade instead of doing reimplementations?
    2. What is the time frame to do upgrade? given the fact that many companies having customizations which need to be carried over (or probably can be terminated because it can be cater by new functionalities in Oracle)

    • irroberts Says:


      Appreciate the questions.

      1. Usually a re-implementation occurs if you have some really very significant business driver. Typically a major change in the Chart of Accounts or Merger/Company takeover or if you’ve decided that your initial implementation just simply has become so bad or so heavily customized that you want to start again. But a re-implementation is going to be seriously expensive, have horrific data migration implications (a lot simply cannot be migrated cleanly) and take a very significant time. Most companies will simply do an upgrade because it is simpler (although still complex), faster, cheaper and there are no business drivers for re-implementation. You must have a VERY VERY good reason from the business to re-implement, otherwise don’t even consider it.

      2. Depends on the site, which is why I recommend doing a quick test upgrade and assess how good/bad the impact was. With the new releases being more stable really between 6-9 months could be a reasonable goal for sites with reasonable levels of customization. Of course that requires high levels of commitment from both Business and IT. If you’ve done say an R11.5.5 to R11.5.10 I’d use the actual times from that upgrade and add say 50% additional as a rough guide as R12 is more complicated. But a quick test upgrade/study will get you to your own precise numbers.



  2. sachin Says:


    I would appreciate if you could share your Upgrade Project PLan in either MPP or Excel Format.


  3. sarita Says:

    Hi- I would appreciate if you can send the Release12 upgrade project plan and other test documents to saritat@gmail.com


  4. Kevin Says:

    Great article…Thanks for all the info

  5. Anne Says:

    I would appreciate it if there were any test scripts available for the Payroll upgarde to 12i. Does anyone have anything like this?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: