Two Roads to 11i: Upgrade vs ReImplementation

How do we get to Release 11i? For many businesses this comes down to: Upgrade versus Re-Implementation. This article discusses the differences between the two approaches, what is involved in each one, the advantages and disadvantages of each and what factors influence the decision between them.

What’s the difference?

During the move to release 11i many people are choosing to re-implement their applications rather than upgrade them.

So what’s the difference? An upgrade of the applications involves running a series of programs on the database to ‘transform’ it into the Release 11i structure (the tables, views and so forth). A re-implementation, on the other hand, involves creating a brand new, completely empty Oracle Applications installation and setting up from scratch.

What Happens in an Upgrade?

The basic tasks for an upgrade are as follows:

  1. the DBA lays down a Release 11i filesystem (the programs),
  2. the upgrade team performa a series of pre-upgrade steps to prepare the data for upgrade,
  3. the DBA runs the AutoUpgrade program to transform the database into the Release 11i structure (the tables and other database objects),
  4. the upgrade team perform a series of post-upgrade steps and set up new functionality

What Happens in a Re-Implementation?

For comparison, a re-implementation follows a slightly different process:

  1. the DBA performs an install of the Release 11i software (programs and database)
  2. the re-implementation team set up each of the applications as per the previous setup with any required modifications including new features
  3. the re-implementation team convert required data from the old database and pull it in to the new.

Advantages and Disadvantages

The key advantages of the upgrade approach are that it is often cheaper as involves significantly less work from the functional team for setting up the applications, and in general all the data comes across as part of the upgrade so there is no data conversion effort. An upgrade does, however, require significant effort from an experienced DBA and is more technically challenging, being susceptible to more technical problems.

The re-implementation involves significant effort both in applications configuration and in data migration. If business process re-engineering and/or significant setup changes are also being implemented then the effort from the business in increased. Technically, however, the risk is lower which can be a mitigating factor for very high-risk upgrades.

Some Factors to Consider

Several factors can tilt the scales towards one or the other alternative when planning your move to Release 11i. These include:

Multiple Set of Books Architecture (MSOBA)

Multiple Set of Books Architecture (MSOBA) refers to multiple installs of subsidiary ledger products such as AP, AR & PO, rather than to multiple sets of books defined in General Ledger.

If you currently use MSOBA on Release 10.7 there are three main ways to get to release 11i:

  • Upgrade as is. Whilst MSOBA is still technically supported in Release 11i, the upgrade scripts (AutoUpgrade) were not written with MSOBA in mind and as such will need to be altered by a very experienced DBA with guidance from OWWS.
  • Convert to Multi-Org prior to upgrading to release 11i. This involves picking one ‘primary’ set of books and disabling all the others. This means that no history will be available for any of the other subsidiary ledgers (eg. AP2, PO2, AP3, AR2, etc) unless a conversion effort is undertaken. All history will still be available in General Ledger as it is not affected by the MSOBA architecture.
  • Re-Implement in Release 11i. Since most companies prefer to keep at least some history from the subsidiary ledgers (open invoices, for example), depending on the volume of data it is often more straightforward to re-implement on Release 11i. The additional work involved can often be reduced to conversion of GL and FA data – when your project team has done this before they already have the scripts available to convert the data, significantly reducing conversion development time.

Dual Currency conversion to Multiple Reporting Currencies (MRC)

Dual Currency in General Ledger is functionality which enables businesses to translate your account balances from your functional currency to a reporting currency using weighted-average rates as well as standard translation rates (period-end, average and historical rates). Using Dual Currency under both the Journal Method and Reporting Method results in a reporting set of books. This set of books structure can be adapted to service the Multiple Reporting Currencies (MRC) setup if required.

The big differences between Dual Currency and MRC for those considering the move are:

  • Dual currency uses a weighted average rate, MRC uses the daily rates
  • With MRC the reporting set of books contains current balances at any time during the month since conversion to the reporting currency is done at the time journals are posted. With Dual Currency conversion occurs at the end of month so reporting currency balances are not representative on a ‘live’ basis.
  • Dual currency occurs only within the General Ledger, MRC extends to subsidiary ledgers. For example with MRC Payables transfers to General Ledger twice – once in the primary set of books and once in the reporting set of books.

Restructuring your Chart of Accounts

Often where the business has changed significantly since implementation or where several different businesses are being amalgamated into one Oracle Applications database the business need arises to restructure the Oracle Chart of Accounts. Depending on the degree of change this may be best handled within your current Oracle environment or by re-implementing into a new one.

For example, on one end of the scale we have the desire to change what two unqualified segments are actually used for within the chart of accounts.

Company Cost Centre Account Sub Account Region Project Code
 2 5 6 6 2 5

to

Company Cost Centre Account Sub Account Channel Spare
 2  5  6  6  2  5

This sort of thing can easily be accomplished within the current accounting flexfield structure, often prior to the upgrade project, and does not require re-implementation. On the other end of the scale, lets assume we wish to change the chart of accounts structure from

 Company  Cost Centre Account Sub Account Region Project Code
 2  5  6  6  2  5

to

 Company Account Cost Centre Region
 3 5 4 3

 

This type of major restructure may be more easily performed by re-implementing – if it affected the majority of sets of books, for instance, or if the mapping between the two was entirely manual, if historical data requirements were minimal, etc. Of course, upgrade and consolidate are an easier option if for example the restructure affects only one set of books, representing say 10% of the database.

 

Significant Business Change since Implementation

Many organisations, over the course of their evolution, find that the nature and characteristics of their business change significantly. As business streams are bought and sold, the focus of the business may change considerably. As such, the business may find that the configuration decisions made at the time of implementation and gradually as the business has evolved, do not fit the business as it plans to be over the coming years. Often a re-implementation provides an opportunity to re-visit these decisions, starting with a blank piece of paper to determine the required configuration of the applications that will suit the businesses requirements going forward.

Similarly the business may have identified a requirement for significant business process re-engineering. In order to take best advantage of such an effort, a re-implementation imposes less restrictions on the BPR which can be effected within the applications configuration than an upgrade.

Lack of Confidence in Integrity of Historical Data

Often long-term users of Oracle Applications (implemented on Release 9 and earlier) may have lingering questions regarding some of the data in their database. This is usually as a result of several factors:

  • Prior to Release 10, the standards for customisation of Oracle Applications were not as strict nor were they as strictly followed. This has resulted (for some companies) in data being directly written to Oracle Applications tables and it is often this data which causes problems during autoupgrade. The long-term effects of significant unsupported customisations may give a certain weight to the advantages of re-implementing in Release 11i either as close to a vanilla implementation as is practicable or at the least using only supported customisation methods.
  • Each new release of the Applications has provided additional functionality and additional validation for the data entered into the applications. As a result, data entered in earlier releases of the applications may not fully conform with the current and new strict requirements. Where transactional data is the issue, this can often be purged from the applications, eg. AP Invoices, however not all data is able to be purged (eg. FA depreciation can be purged, but not the assets themselves. GL Journals can be purged but never GL_CODE_COMBINATIONS). In the latter case a re-implementation starts to become more attractive.

So which is appropriate for our business?

Good question. And one it is difficult to answer, since every single case is different and each has it’s own peculiarities. Selecting the appropriate road forward for your business involves both awareness of what is involved in each approach and consideration of these factors. If your business has any drivers leaning towards a re-implementation then it is often worthwhile to scope out both approaches and decide on the basis of work effort and your corporate culture. Do you anticipate doing this all in one hit (in which case the re-implementation may be faster – especially when the people doing it have done it before and already have the scripts) or would you prefer a series of ‘bite-sized’ projects (in which case upgrading is one of them and the other required changes are performed separately).

So, as usual, there is no one ‘right’ answer for everyone.

Further Reading

Oracle Corporation. 2001. Supported Approaches For Migrating a Multiple Install Architecture (MSOBA) to Multi-Org and 11i.

Kent Noble, Oracle Corporation. 2001. Upgrading to Release 11i: A Technology Perspective.

Kevin Glynn, Oracle Consulting, 2000. The Advantages of Moving to Multi-Org.

Oracle Corporation, 2000. Strategic Planning for an Oracle Applications Instance Consolidation Project.

Oracle Corporation, 2000. Strategic Approaches for Consolidating Multiple Oracle Applications Instances.

 

Leave a Reply

Your email address will not be published. Required fields are marked *