Hitting the Reset Button for R12 - The Upgrade vs Reimplement Decision

tel: 407.591.4950 | toll-free: 1.888.943.5363 | web: www.eprentise.com
Hitting the Reset Button for R12:
The Upgrade vs. Reimplement Decision
an eprentise white paper

Hitting the Reset Button for R12: The Upgrade vs. Reimplement Decision
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 2
© 2014 eprentise, LLC. All rights reserved.
eprentise® is a registered trademark of eprentise, LLC.
FlexField Express and FlexField are registered trademarks of Sage Implementations, LLC.
Oracle, Oracle Applications, and E-Business Suite are registered trademarks of Oracle Corporation.
All other company or product names are used for identification only and may be trademarks of their respective owners.
Author: Helene Abrams
Published: October 20, 2009
www.eprentise.com

There are two paths for moving to a new release of an enterprise software package. The first is to use the
vendor-supplied patches to upgrade the existing instance. The second is to start from scratch and
reimplement. This paper explores the factors that influence whether an upgrade or a reimplementation is
the customer’s preferred choice. First, some definitions:
Upgrade refers to the process of starting with an existing database instance and data, and then applying
patches to get to a new release.
Reimplementation starts with a blank database that is installed and configured from scratch. Existing
data is migrated into the new application instance after the configuration is complete.
This article looks at the decision points of Oracle® E-Business Suite (EBS) customers as they evaluate
whether they should reimplement or upgrade. Though EBS customers are taken as the example here, the
decision is basically the same for any enterprise system.
1. Oracle E-Business Suite (EBS) R12 is a significant new version with valuable new features and
capabilities. Most people currently think some customers are forced to reimplement in order to take
advantage of R12, but that other customers may be lucky enough to reap the new release benefits
via Oracle’s upgrade process.
2. Most EBS customers upgrade if given a choice because that is the path of least
resistance. Compared to reimplementation, it is simpler, uses fewer resources, will likely cost less,
and the time-to-value is shorter. We observe that software vendors usually make upgrades easier
than starting from scratch, if they know how and can do so at an acceptable cost. If not, individual
customers shoulder the reimplementation burden.
3. We also observe that some customers’ business users and IT staff have been frustrated with their
current EBS implementation and its restrictions. They accept the requirement to reimplement as an
opportunity to break with the past and get a clean start with Oracle. Because it’s perceived as a
requirement, they have an easier time justifying the additional expense, effort, and delay of putting
R12 into production. Nevertheless, reimplementation drains the business’s resources more than a
typical major release EBS upgrade.
4. The organization’s Oracle specialists, consulting firms, and industry analysts should look at the
current situation and re-think why they accepted that the new architecture required you to start over
and reimplement.
5. The E-Business Suite 11i environment may have conditions that seem to require Customer
reimplementation plus data migration. An Oracle document, R12: Upgrade vs. Reimplement
(Financials) clearly defines the terms and introduces some of the key factors. These factors primarily
focus on underlying infrastructure pieces of the applications that are very difficult to change once
EBS is in production (i.e. Chart of Accounts, Calendar, Organization Units).
6. There are some reimplementation consequences in the areas of implementation, data history,
disposition of the 11i instance, reporting, and business intelligence:
o You have to implement a fresh installation of R12.
o You are on your own to get your historical data from the legacy 11i instance into R12.
o 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.

o Even though data conversion tools these days are powerful, and programmers in the global
programming centers are inexpensive, 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.
o You will keep the 11i instance in “legacy” mode. Some call this a “sunset” instance. It must be
frozen and restricted to read-only access. Even though the instance is read-only, there may still
be associated maintenance, license, and support costs.
o You will devise reporting mechanisms to span the legacy 11i and operational R12
instances. That includes translations, reconciliations, mappings, and external reporting
environments. Every time that access is required for the data in the sunset instance, it needs to
be changed so that you can report on like things. For example, if you change your chart of
accounts in R12 and need to report on accounting entries that span both the 11i and R12
instances, you will need to translate the chart of accounts in 11i to match the new one in
R12. Sometimes this involves creating mapping tables, sometimes implementing and
maintaining pointers and references to the old data, and most certainly includes some degree
of reconciliation to make sure that the translation is accurate.
o If you have a business intelligence environment or data warehouse, you will make changes to
incorporate the frozen legacy 11i and operational R12 environments.
7. Oracle’s description of R12 reimplementation comments on configuration setups and data migration:
o There is “greater flexibility in your setup and in how you migrate your historical data using
supported public interfaces.”
o “Flexibility” here means you have another opportunity to make major IT decisions to live with
for a long time. This is an advantage if you are not satisfied with your 11i setups. If you
upgrade, Oracle maintains that you will have to live with your 11i setup.
o Many tables do not have an API (Application Programmatic Interface) that allows you to bring
data into EBS. There are almost no formalized interfaces or extracts for getting the data out of
the current 11i instance, meaning that there is no guarantee that you will get all the related
data and load it in the right sequence to maintain the relational integrity. The translation scripts
that you will use to change the data from your 11i instance into the format that you have
defined as your target R12 instance are all custom-coded.
o Oracle’s description concedes that reimplementation is more difficult, complex, and resource
intensive compared to an upgrade.
o “It is a project that you would generally undertake with the support of a professional services
provider, such as Oracle Consulting.”
8. Customers now have a choice. Available third party software allows you to make changes to the
setups of the 11i Applications that you inherited. This software allows you to change only the pieces
of your EBS suite that no longer align with the business. Not only can you retain more of your
investment in the 11i instance, but you can also take advantage of Oracle’s upgrade software, for
which you pay as part of Oracle Support.
9. The result is an R12 instance with all the desired target characteristics and all the historical data. All
the transactions in all subledgers reflect the new setup parameters.
o You have the same opportunity to change set ups (flexibility) to define the target R12 instance
as you would have if you were to reimplement.
o You would reduce the consulting services and the time required to run through several
conference room pilots and make decisions all over again.
o Software allows the flexibility to change your mind – you can use software to make the changes
you think will accurately reflect how you want to do business, then generate standard reports to
see how your decisions impact your operations.

o Software generates the code automatically so that the resources you bring onto your project
don’t have to worry about maintaining relational integrity. You don’t have to worry about the
skill level of the consultants and whether they have had experience with the modules in your
environment in R12.
o You may be able to launch R12 and start capturing the business benefits from 1 to 2 quarters
earlier.
Curious?
For more information, please call eprentise at 1.888.943.5363 or visit www.eprentise.com.
About eprentise
eprentise provides transformation software products that allow growing companies to make their Oracle® E-Business
Suite (EBS) systems agile enough to support changing business requirements, avoid a reimplementation and lower the
total cost of ownership of enterprise resource planning (ERP). While enabling real-time access to complete, consistent
and correct data across the enterprise, eprentise software is able to consolidate multiple production instances, change
existing configurations such as charts of accounts and calendars, and merge, split or move sets of books, operating
units, legal entities, business groups and inventory organizations.

Hitting the Reset Button for R12 - The Upgrade vs Reimplement Decision

More Related Content

What's hot (19)

Similar to Hitting the Reset Button for R12 - The Upgrade vs Reimplement Decision (20)

More from eprentise (20)

Recently uploaded (20)

Hitting the Reset Button for R12 - The Upgrade vs Reimplement Decision