Managing the Dynamic Datacenter

Datacenter Automation

Subscribe to Datacenter Automation: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Datacenter Automation: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Datacenter Automation Authors: Shelly Palmer, Automic Blog, Pat Romanski, Elizabeth White, Liz McMillan

Related Topics: Oracle Journal, Datacenter Automation, SOA & WOA Magazine, Java Developer Magazine

Article

Tips for Making the Right Decision for Your Organization

Upgrade vs. Reimplementation for Oracle EBS R12

Executing change management and version control for applications like Oracle E-Business Suite can be a daunting challenge, especially when you're talking about upgrading Oracle E-Business 11i to version 12, commonly called "R12." Your choices to achieve this change include a traditional upgrade to EBS R12, or reimplementation, a rip-and-replace of the current version with R12.

Each approach has its own unique set of advantages and disadvantages, and the path you take to R12 also can depend on whether your organization has EBS 11i, or an older version. In the long run, upgrading is less expensive, but carries a higher technical risk. Reimplementation, which rebuilds your existing Oracle E-Business Suite based on existing data, presents lower risk and requires less technical effort by an experienced DBA, but is more expensive. An EBS R12 upgrade can be challenging and complex, but, with knowledge of a few key fundamentals, you will survive, regardless of whether you're perspective is technical or functional.

For some background, Oracle E-Business Suite 12 presents both technical and design upgrades to 11i, and has been out since 2007. Due to the economic climate of the past few years, Oracle has extended support for prior versions, but soon will discontinue support for EBS 11i, offering extended support only until 2013. Caveats to that extended support include the fact that it comes at an expense to the organization, and requires minimum levels of 11i that can cause enough pain that many organizations decide it's time to rip off the band-aid and simply move to R12. The organization also runs the risk of running on an unsupported version that carries such key business functions as finance.  Plus, business users want R12 functionality, both from new products that didn't exist in 11i, and from the 300 new features and bug fixes now found in R12.

As we've already mentioned, once you've decided to move to EBS R12, you have two alternate paths for making the change: upgrade or reimplementation.

  • In an upgrade, you will essentially massage your existing system and data into the new version.
  • In a reimplementation, you will stand up a completely new instance and either insert your old data where possible, or rebuild it in the new instance.

Upgrading can be less costly since you're essentially making do with what you have, and will require less staff time. Reimplementations often are more complex, requiring more care and feeding by staff. These soft costs are what tend to make this path more costly to the organization.

The key advantage of reimplementation, however, is that it generally presents lower technical risk to the system. The effort, in this case, comes from the functional team in rebuilding the application setups, rather than from the technical team in migrating all the data.

Another consideration is your "starting point" in EBS. If you're using a version older than 11.5.9, your business may have changed as dramatically as EBS over the time since your version was released. Couple this with the R12 recommendation that you be on 11.5.10 or newer to upgrade, and you might find yourself facing a lot of patches to 11.5.10 before you even reach the point where you are ready to upgrade. If you are in this group, you should look closely at the reimplementation option. However, if your business has not undergone many major changes since 11i, and your configurations still apply, you should consider an upgrade.

To summarize so far, here are the pros and cons of each approach:

Upgrade (massage existing into new):

  • Less costly
  • Requires more effort by experienced DBA
  • Requires less effort from functional users
  • Carries a high technical risk

Consider this approach if:

o    You are on EBS 11.5.10 R2

o    There have been no major changes to the nature of your business since 11i, and your configurations still apply

o    Your technical effort and financial resources are tighter

Reimplementation (rebuild new based on existing data):

  • More costly
  • Requires less technical effort
  • Requires more functional effort
  • Carries low technical risk

Consider this approach if:

o    You are on an older version of EBS 11i (11.5.9 or older)

o    Your configurations should change to reflect material change in the business since 11i

o    Your technical resources are fewer, but you have more money available

Your most important task before you begin the move to R12 is to assess your organization's need and the impact of the upgrade. What are your functional needs, what are the technical requirements, and from what version are you beginning? Answering these questions will help you both determine whether to upgrade or reimplement, and start defining the change requirements.

If you choose the upgrade option, make sure you're aware of pitfalls that can present stumbling blocks to your project. To avoid them from the start, be sure to account for all your customizations - both documented and undocumented - and know up front which ones you want to keep; make sure you are current on all your patches before you begin the project; take care to upgrade any custom applications as you move to R12; and, most importantly, make sure that you test thoroughly and often.

Choosing the Right Tool
A good application change lifecycle management solution will be your best friend, whether you choose an upgrade or reimplementation. A solution that gives you increased visibility into application change, as well as control over it, will allow your organization to be more responsive to change, saving both time and money during the upgrade.

Besides helping you manage change, your solution should also assist you with establishing and maintaining version control, and ensuring your organization achieves regulatory compliance during the upgrade. It should be able to address:

  • Issue tracking to track and control progress on all application changes
  • Workflow so you can define the processes and ensure they are enforced in a repeatable, consistent manner
  • Full version control functionality with flat files, Developer, AOL, Function setup, and schema objects
  • Migration management and the ability to ‘drag and drop' configuration and code changes when authorized while invoking the appropriate Oracle technology
  • Patching and impact analysis to schedule and automate application patches, as well as protect developers' work and provide pro-active insight into what changes the patch will make
  • Auditing and reporting on the who, what, why, when, and where changes were made

Regardless of the solution you choose to facilitate your change to EBS R12, and whether you choose upgrade or reimplementation, here are a few best practices you should follow to make your project as trouble-free as possible:

1. An Ounce of Prevention is Worth a Pound of Cure

o    Ensure that all stakeholders are on board

o    Make sure management approves the initiative and the staff, and the costs to execute the project

o    Make sure functional leaders are chosen by competency with the module/business process

o    Select a PMO to own the total project and commandeer execution from start to finish

2. Test thoroughly

o    Do a test upgrade followed by an impact study

o    Test, test and more test through a QA environment and UAT before you push to production

o    Specifically test the third party tools that run with modules/applications

3. Train users properly

o    Stand up a "vision" instance early and encourage users to utilize  it to become familiar with R12 in advance of the production implementation

o    Make sure users are aware of the net-new functionality in R12, plus improvements to existing functionality that are very different from 11i

Planning and successfully upgrading to EBS R12 can be challenging, but, armed with the knowledge of the differences between an upgrade and a reimplementation, along with the circumstances that favor one approach over the other, you should be on your way to making the right decision for your organization.

With the combination of an application change lifecycle management solution that offers you control, visibility and automation; plus knowledge of potential pitfalls and a tried and true set of best practices, you should be ready to embark on a successful upgrade with confidence.

More Stories By Fernando Volonte

Fernando Volonte is the product manager for Stat for Oracle E-Business and Stat for PeopleSoft at Quest Software. He has more than 13 years of experience with change management and version control for enterprise resource planning (ERP) platforms, and has been working with Stat since its outset. During those 13 years, Fern has done everything from tech support to training in English and Spanish. He is considered a Quest subject matter expert in this space and has spoken at conferences around the country on the subject.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.