OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.

htm

SUCCESSFUL UPGRADES
(A Generic Guide to Managing Your Upgrade)
Cathy Cakebread, Consultant

Abstract

This paper is based on my experience in managing six upgrades. It includes tips for how to successfully upgrade
including: managing the project, getting your users involved, dealing with new features, heading off problems before
they occur, and controlling your custom work.

Introduction

With the introduction of the GUI products, the pending loss of support of Release 10SC, and the need to deal with
Year 2000 issues more and more companies are facing the need to upgrade their Oracle products. The purpose of
this paper is to provide tips for how to successfully complete this process.

The Project

DON’T UNDERESTIMATE THIS PROJECT! The biggest problem that I have seen regarding Oracle applications
upgrades is the tendency to underestimate both the complexity of the project and the resources required. As
someone once said, "this isn’t a Word upgrade." A typical upgrade can take 3 to 6 months to complete. Many
upgrades will have a more global business impact than the original implementation, since an upgrade involves ALL
PRODUCTS and ALL USERS at one time -- you cannot phase it. It may mean that your production systems will be
unavailable for 4 - 12 days! You need the help and support from representatives for every product. You need to
coordinate users, Information Services staff and machines. You need to manage expectations and provide plans for
how you will deal with the potential down time. You also need to get upper management involved up front so they
know what to expect so they can help in getting resources. This is a BIG job! All of this applies whether you are
moving from Release 9 to Release 10 or just from one 10 point release to another. The keys to success are:
planning, coordination, knowing what everyone needs to do, and doing it!

The Coordinator

You need an individual whose role will be to coordinate and manage this process. They are the liaison between
users, Information Services, Oracle and other staff. They are the focal point to ensure that things continue as
planned and to provide solutions when they do not. This could be a two day a week position, but the person should
be dedicated to the process during those two days.

The coordinator is responsible for drafting and administering the plan, for removing roadblocks and often acting as
the "whip" that reminds everyone of their responsibilities and ensures that they continue to make progress.

The Team

You also need to assign at least one user per product who will be responsible for ensuring that the required tasks for
that product are completed. This should be someone with real working knowledge of the product and not your worst
employee (because they have the time since you do not trust them to do anything else). Their managers should
acknowledge that this project will require 8 - 16 hours PER week of their time and should lighten their other
responsibilities, wherever possible.

These are your product representatives who will help to determine: what new features you want to use and how you
could improve your current ways of doing things. They will also ensure that the products work as you expect --
PRIOR to going live. They may also need to ensure that the documentation and procedures for their product are
updated. Quite a lot of responsibility -- choose well!

These team members should not have to do ALL the work themselves, they should get help from others in their

1 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

departments. They are just responsible for insuring that the work actually gets done.

The Information Services members of the team should include: the DBA, programmers, Help Desk personnel and the
person responsible for doing the actual upgrade (if not included above).

The team should meet at least weekly to ensure that progress is being made, to identify roadblocks and as a not so
subtle reminder that everyone has things to complete prior to each meeting. GUILT!

Planning

It is necessary to have a road map of where you are, where you are going and who will be responsible for ensuring
that each task is completed successfully. The more detailed your plan the better (that way you have more things to
check off as you complete them and you are less likely to forget things).

Know who will be responsible for what, what tasks are dependent on other tasks and where you are in relationship
to the plan -- at all times. Ownership is critical.

Other key aspects of the planning include determining:

- The best timing for the "cutover"(to switch from the old release to the new release)

- What you can do before the cutover window and

- Who will need to do what and when during the cutover.

When you actually "cutover" to the new release, your production systems may not be available for 4 to 12 days --
what will the impact be? What will the users do when the system is not available? Especially in critical business
areas that CANNOT stop -- you need to clearly define and communicate all of these things prior to the actual
cutover. Do not forget your users in external offices.

You may have to do things on paper and then re-enter them when the system becomes available -- if this is an
option. You also need to be sure that upper management is aware of this shutdown far in advance -- this would not
be a good surprise!

You need to determine the best time in your business calendar for the cutover (that will have the least business
impact). A slow time in your business, right AFTER a quarter close, holiday weekends and scheduled production shut
downs are good candidates. Not during quarter close or year end close.

I prefer to start on Thursday evening, after all work is completed, since you have at least 3 solid days to work on the
upgrade, before the next work week. If AutoInstall runs quickly enough, you should then only be down for one
production day.

You should work to minimize the time that you will actually need to take the system. This can be accomplished by the
following:

- Perform MULTIPLE test upgrades (every time you do it you learn how to make it faster)

- Pre-do as much as you can

- Multi-task where possible -- don’t rely on just one person.

You also need to identify if the new release is certified for your current version of the database and your current
version of your operating system (especially applicable for Release 10.7). If not, order the upgrades and define a
strategy for how you will upgrade the database and/or the operating system too. Will you upgrade the database
and/or operating system with the applications upgrade or separately? This is a much more critical issue if you are
still on Version 6 of the database since there are significant differences between Version 6 and Version 7. Especially
if you are running on VMS DEC VAX.

Kickoff Meeting

Once I have defined the team, I like to hold a ‘kick-off’ meeting with the whole team. The point of this meeting is to
explain the importance of their roles and the impact of this process. Also, to identify all users who will be involved in
the project.

2 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

I create a list of all applicable users, their location, their Oracle Responsibilities and their printers. Prior to starting
user testing, I ensure that all of these users are set up on the test system with their relevant responsibilities and that
their printers work properly. See Printing Issues.

What’s New?

You are upgrading to take advantage of all of these ‘great new features’ so how do you find out what they are?
Oracle provides manuals that document what the changes and new features are The Oracle Financials and Oracle
Government Financials Changes Manual, the Oracle Applications Product Update Notes, and Oracle Applications
Documentation Library Release 10.x (the CD). These manuals include a chapter for each product explaining each
change (I make copies of ‘their’ chapter available to each applicable user). The Oracle Applications Database
Changes Manual documents the technical changes. Be sure that the manuals you are looking at are for the actual
"point" release the you will be using to go live.

As one of the early steps in the upgrade (after the first test upgrade), I have a consultant who is very familiar with
each product’s old and new features provide a demo/training session. They demonstrate (using our upgraded data)
the new features, how they work and how you could take advantage of them.

At a minimum all official testers should attend but if everyone else who will eventually use the product could attend, it
would be even better. This consultant should be available later to answer questions as issues arise as a result of the
testing. I usually schedule 1 - 2 follow-up meetings for further questions and issues. This is also a good opportunity
to discuss problems with the way you are currently doing things. The consultant can also suggest how to improve
your current procedures.

It may have been several years and various staff members since you originally implemented. The way that you
originally chose to use the system may no longer be relevant, and you may be able to improve your processes,
especially given the new features. This is a good opportunity to re-evaluate your set up values and how you do things
-- you could improve things now (even before you upgrade)!

Custom Work

One of the more challenging tasks can be to identify the custom work that was done when you previously
implemented or upgraded your system. You then need to determine if they are still relevant. Often you create
custom reports or screens to ease the transition from your old systems to Oracle, so they may no longer be
necessary. Wherever possible, combine custom reports and screens to reduce the number that you have. Also verify
that the custom reports and screens are really the best they can be. Why replicate something that is just O.K. if you
could easily make it great?

All custom work should be readily identifiable as custom. By the report or screen name, by the QuickPick or List
values and menu paths, by the programs name, by the application they are registered to and by where they actually
reside. You, of course, will use proper registration of your custom programs to the custom applications and will store
them in the custom directories so that you can easily find them. Right! See attached document for suggestions for
naming conventions regarding custom work. It provides guidelines for naming, registering and locating your custom
work. I have also included a sample of a form you can use for documenting the location and reason for custom work
(to prepare you for the next upgrade). See paper #45 by Paule Kodjou in the Spring 1996 OAUG Proceedings -
‘Architecting Your Application Environment For Development and Preservation of Your Customizations’ for more
ideas in setting up your custom work, including using the new APPS schema.

DO NOT UNDERESTIMATE THE IMPACT OF REPORTS 2.5. The majority of the standard Oracle reports are now
written in Reports 2.5. Since most custom reports involve minor changes to standard reports and the standard
reports are in 2.5 you will need to train your programmers in Reports 2.5. Allow for the fact that minor formatting
changes can take a VERY LONG time. Do you have enough resources to convert your custom work? If not, who will
do it?

You are not required to use Reports 2.5 for your custom work, and you have other options such as SQL*PLUS that
may work just as well or better. Evaluate this on a case by case basis.

Testing - Users

3 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

I believe that user testing is the real key to the success or failure of your upgrade. It is far better to find and resolve
problems in a test environment then it is in production, especially when the system has already been down for
several days. The hardest issue is the resources you need to do this (the real users), since they already have their
‘real’ jobs to do (keeping the business going -- nothing important). That usually takes 120% of their time and now you
want them to do more -- are you kidding? No, so you need to: 1) allow enough elapsed time for them to actually get
in and test, 2) get management support to make more of their time available, and 3) acknowledge and be
compassionate regarding these other demands. You could use Information Services and consultants to do your first
pass of testing but only real users who know the data and processes will know if it really is O.K.

If you are upgrading from one point release to another, it is especially hard to get a lot of user involvement since the
changes and benefits are not so apparent as with a major upgrade. But you need to treat the system as if you have
never seen it before and test it just as thoroughly. Just because a screen looks the same doesn’t mean that there
were no underlying code changes.

I believe in 2 levels of user testing -- ‘Break It Testing’ and ‘Simulated Close.' ‘Break it’ testing has two purposes: 1 --
to confirm that the products work as expected and 2 -- to try out the new features and new ways of doing things in
an uncontrolled environment. You can see if the new features or procedures will work for you and how you could use
them. This means running EVERY report, and using EVERY screen and EVERY process (unless it is obvious that
you will NEVER, EVER, EVER use this feature). Did they work? Did you get the results that you expected? Be
careful of reports that might be huge -- you might want to set your number of copies to 0 and only print when you are
sure that the output is not too, too big.

The point of this test is to play -- try funny things. Did you get a reasonable message or did you have a serious
problem? Have you ever wondered what would happen if you did something? Try it and see what happens. You
cannot hurt anything and you may find some better ways of doing things, in a safe environment.

When I personally test, I first go into EVERY set up screen, I add a record called ‘Active’ and I save it. I then create
one or two other test setup records. If there is an end date -- I create a new record called ‘End Date’ -- I save it,
and then I update it with an end date prior to today and save it again. I do the same thing if the set up has a status
value, I create an ‘Inactive’ or ‘Disabled’ record. By doing this I have proven that I can: add and update records in
each set up screen (setup screens can have bugs too). I have also created test values that should NEVER appear in
any QuickPicks (or Lists). If they do appear, there is a bug since most processes are dependent on your only being
able to select truly valid values.

I then test every report and screen. Test ALL interfaces between products, both Oracle and other outside systems.
Be sure that you also test all multi-step processes such as check runs.

Review your setups. This would be a good time to cleanup any unused values and you can clean them up RIGHT
NOW in production (after testing - of course).

I use SQL*PLUS to create a list of all enabled reports, screens and processes. I use these lists as checklists to
indicate what has been tested so far and by whom (initials) and which are not applicable. This gives you a good
visible count of what is still left to do.

Define what a successful test is and who will be responsible for making that decision. Would every tester be willing
to sign a form that says that they have completely tested their product? See sample form

Simulated Close

The purpose of this set of tests is to again test everything but this time, in a controlled environment. Here you are
actually replicating what you did for a period end close. This tests entry of actual data and validating reports and
interfaces between systems to ensure that everything works exactly like before or better (with known expected
results). I try to replicate the work for the last 3 days of the period and I allow 2 - 3 weeks elapsed time for the
actual testing. The more actual users you include in this test, the better off you will be. This requires a bit of planning
and LOTS of coordination BUT it is worth it. Beyond the things that just plain do not work, you will find about 80% of
the bugs in this test.

You should only start this test after you have identified and resolved all bugs in the ‘break it’ test.

1 - Determine the day’s work you will be replicating. The last few days of the period are usually best since most
interfaces between products occur at that time. You should include processes such as check runs -- where possible.

4 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

2 - Decide (by product) on the 4 - 5 ‘baseline’ reports that you will use to verify the consistency of the data. This
should include reports with both balances and transaction details that are good measures of the accuracy of the
data.

3 - During the night prior to your first ‘test’ day, run the baseline reports in production, after all work has been
completed for the day (noting the parameters that you used). You may want to ‘stage’ the running of these reports
e.g. AP at 6:00, AR at 7:00 ... so you don’t create a bottleneck.

4 - That same night, Information Services creates a full export of the database (after the reports finish).

5 - Make copies of all details of work performed in production for the ‘test’ days. The ease of this will vary by
department. Some departments already file their work by day or can use detail reports to replicate what they did.
For some work, you just have to make copies and save. Do not forget the outer offices and their work.

6 - In the test environment, use the export from step 4: import the data and perform the upgrade (including the pre
and post upgrade steps).

7 - Run the baseline reports again against the upgraded data (using the exact same parameters). Note that a few
weeks may elapse between when you originally ran the reports and when the test environment is available,
remember where they are.

8 - Compare the results of the reports. They should be identical -- if not, you have a problem.

9 - Replicate all of your work for the ‘test days’. Run the period end reports and compare to the actual period end
reports.

10 - If you did not run ALL of the standard interfaces in the window of test days, either change the window or
complete the controlled test. Then run each interface using the real data and compare the results to the ‘real’ results
you had in production.

General Ledger generally does most of their work after period end close. Be sure that they also enter a reasonable
amount of their real data.

Due to product interdependencies, you may need to coordinate the tests for each ‘test day’. You may need to
control when each department starts a new day’s test. For example, AP can only start after PA finishes. I hang a
chart on the wall to indicate where we are and what can happen next. Make it fun -- see who finishes each day first!
Communicate when everyone is done with each day so you can begin work on the next day. The point of this test is
not to test your data entry skills but to test the system functionality using real data. Pick days with a reasonable
amount of work but not huge amounts. Since lots of time in daily work is spent researching and resolving issues --
this test should go much faster than when you entered the data the first time.

Reporting Bugs

Provide each tester with copies of the standard BUG reporting form -- see sample. Assign one or two people as the
key contacts who will log, report and track your open TARs (Bug Coordinators). Each tester should try to explain in
as detailed as they can: where exactly they were, what they were doing and what happened. Also, use the Oracle
‘Help Version’ feature to determine the form name and the version they are working with -- record this on the bug
form too. Use screen shots and report samples to demonstrate the problem, when applicable.

The ‘Bug Coordinators’ will log the TARs and work with Oracle to get them resolved. They will work with the DBA to
get the patches installed and will notify the tester when they can re-test.

Keep a log of all TARs including: product, description, status, resolution, date called in, date resolved and the patch
number. This way you always know what is still open and what you did to solve the closed items. You also know
which patches you will need to apply when you go live (and for subsequent tests.)

Testers should not limit themselves to obvious bugs, if something is unusual or you cannot understand it, maybe
Oracle can help.

I like to get a list of the latest known patches for each product we are testing. I keep this handy so we can check the
known bugs before we spend a lot of time trying to replicate something that someone else already found. When I

5 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

order the patches on the list, I usually ask for the latest version PLUS all related and pre-requisite patches. NEVER
apply patches in production without first testing them in your test environment.

Testing -- Information Services

PRACTICE, PRACTICE, PRACTICE! The more times that you do practice upgrades -- the better off you will be. It
often takes 4 - 6 WEEKS to successfully complete your first upgrade. This includes the pre-upgrade, upgrade and
post-upgrade steps. You should be prepared for this!

I recommend at least 3 test upgrades and more if you are still having problems in the 3rd test upgrade (better to
practice in a test environment than in a down production system). The first test is just to get it to work. The second is
a second test and the third is for the ‘simulated close’ test.

As you run each test upgrade step: note the time it took for each step. Also note the results and the name of any
scripts you had to create to complete the step (this includes each pre and post upgrade step). If they aren’t
provided, note the menu paths for each step, so you know what to do next time. You can re-use your notes in your
subsequent upgrades and you can use it to estimate the time required to do the actual upgrade in production
(allowing for environment differences).

You can assign pre and post upgrade steps to different people. This spreads the responsibility and shortens the
amount of time required but be sure that everything is covered especially Human Resources and other ‘shared’
products. You may want to complete the pre-upgrade steps for Human Resources before starting the pre-upgrade
steps for the other products and they are generally pre-requisites for many off the other products.

It is great if you have a test environment that has enough room for two full test instances. One for the user testing
and one for the next test upgrade (that way you your users never have to stop testing – momentum!) I often have
clients with special ‘test’ machines. If this is the case for you, be sure to factor in performance and size differences
when you are predicting the cutover time requirements.

If you are using outside consultants to perform your upgrade, ensure that your internal staff knows exactly what they
did and how. Documentation!

Policies And Procedures

Since you may have new screens, reports and often, menu paths -- your old procedures may be obsolete. So, one
of your upgrade tasks will be to ensure that all of your procedures are updated PRIOR to going live. This is
especially critical if your processing occurs in multiple locations.

The first task will be to find the soft copies of the existing documentation -- often easier said than done. Print clean
copies and distribute to your testers (that way they can note the necessary changes as they are testing). Allow for
the new capabilities and for the possibility that some polices and procedures will change as a result of this process.
Will someone have to approve this? Who? What is necessary to ensure that the changes are approved prior to the
actual cutover date? Before training?

Assign the tasks of updating the documentation and distributing the changes to the appropriate people to ensure that
they really are done (prior to the training).

If the policies and procedures are enough to train from -- great! If not, you will need to also create new training
manuals or to modify your existing training manuals.

Training

Now that you have new policies, procedures and features, you need to share this information. Ideally you should train
1 - 2 weeks prior to actually going live but logistical issues may force you to spread this out. Training done in isolated
rooms where each user has their own terminal is the most effective. Provide lots of examples and exercises where
the trainees can practice what they have learned. Practice until they are truly comfortable with what they are doing.
ALLOW ENOUGH TIME! It is better to practice in test than to ‘practice’ in production and it should help to alleviate
the inherent frustration of dealing with change.

6 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

What about users in outer offices -- how will you ensure that they are properly trained? Do not forget them!

Go/No Go Decision

At least one week before the actual cutover, the team needs to indicate whether or not they feel comfortable in
going live. Do you have any ‘show stoppers’ or issues that need to be resolved before you cutover? Can you cutover
with work arounds? Is that acceptable? The team needs to sign-off that they are really ready to go ahead with the
production upgrade.

Prior To Cutover

Pre-do as much as you can. Cleanup your data, your setups, your users and responsibilities. Define your new
menus, responsibilities and report groups on paper and assign the creation of these to the proper person in the
cutover window. Create new descriptive flexfields and new value sets.

If you are converting from Release 9 to 10 - be sure to clean up your vendors and customers with invalid countries
(identified in the pre-upgrade processing). Also, clean up any FSGs that did not have a name assigned to them or
that you no longer use.

Predefine your new environment as much as you can. You can even unload the new programs prior to the cutover.

Cutover

This is it -- you are really ready to do it! You have plans for what everyone will do (by hour), both those involved in
the actual project and those who will be ‘kicked off’ the system. You have completed all of the preparation work and
everyone knows what to do and when! And, of course, you have allowed enough time to do it properly.

You will follow the same steps as you did when you created the 'simulated close' environment. See attached sample
of a detailed cutover schedule. This schedule is based on AutoInstall ONLY running for 24 hours, your AutoInstall
process may take much longer, depending on what you are upgrading and your volume of data.

Once all work is completed for the last work day, run your baseline reports for each product. You will again use
these reports to confirm that no data corruption occurred due to the upgrade.

Create a full export. Start the upgrade. Do NOT change ANY variable from the way that you tested them otherwise,
it invalidates the tests and you will be going live with untested variables -- not a wise idea! You can assign various
pre and post upgrade tasks to more than one person in order to save time (you should have done this in your test
upgrades too). Wherever possible, avoid having critical steps (such as the pre and post upgrade steps) during
normal sleeping hours versus in the middle of the day. I know that I am much more accurate when I am not half
asleep and these are, after all, decisions for your PRODUCTION system. Unfortunately for the person responsible
for monitoring AutoInstall -- it needs to run 24 hours a day. Set up a schedule so that one person is not going without
sleep (watching AutoInstall) for the whole cutover. But, I insure that it is always monitored.

Once the upgrade completes (including post upgrade steps) -- run the baseline reports using the exact same
parameters and compare the results -- there should be NO SURPRISES!

Do not forget to back up your production system – ideally before AND after the pre-upgrade steps and again after
you have confirmed that the system is working correctly.

If you have the space -- it is ideal (but not always on option) to create a backup instance of your current production
instance (that you create with the export from the night you started the upgrade). That way should you have a
disaster of some sort, you can fall back to where you started without losing much time. Other factors regarding this
are: how long will it take to create this other environment and what will the impact be on the upgrade. If you have
time, you could start it when the post upgrade steps are done. If you can do this on a different machine, you could
do it while AutoInstall is running.

Only allow key users into the system for a final verification that everything is OK. When it is OK -- let everyone know
that you are LIVE - YEAH!

7 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

Do not forget to keep outer offices informed!

Continue to utilize the test environment to test patches and for future tests of new features.

Specifics Issues

The following are major issues I have experiencing in upgrading from Release 9 to Release 10. If you are upgrading
from one point release to another vs. from Release 9 to Release 10, these may not be applicable to you but you
may want to confirm that these are not still applicable to you.

10.7

I recommend that you upgrade to at least 10.7. This positions you to use the GUI (Smart Client) and Web Deployed
products, it is the latest release and should have eliminated a lot of the earlier Release 10 bugs AND it supports the
Year 2000 (this of course, does not guarantee that there will not be new bugs).

Printing Issues

Every client I have worked with in upgrading from Release 9 to Release 10 has had significant problems with getting
their printers to work properly. Problems such as page overflows, showing nothing but the heading on the page or
not printing anything at all.

You will need to define your printer drivers to Oracle, this includes the detailed print commands from the manual for
your specific printer (you will need to do this for each print style - Portrait, Landscape...). Reports 2.5 properly
handles the carriage return but SQL*PLUS reports do not. To fix this, you need to define your printer drivers
including the carriage return. The best source for the printer driver values for you printer can often be found in your
printer vendor’s home page on the World Wide Web. Hewlett Packard’s page is www.hp.com. Check under Support
and ‘Frequently Used PCL Commands’. You can cut and paste the values without having to enter a complex string of
characters.

For reports that are wider than 132 characters, assign the Style - Landwide

when you define them as concurrent programs.

Note that when you make changes to the printer setup, you need to deactivate and restart the concurrent manager
BEFORE they will take effect.

Contact Mike Conant at mike@attaininc.com for a copy of his paper on printer setup issues in Release 10.

Receivables/Revenue Accounting

Due to the merge of the 2 products, be prepared for the fact that some of the values in the baseline reports will
change. For example, the Journal Entries report in Release 10 includes invoices and credit memos and in Release 9
it does not. This will impact your comparison but should not be an issue if you are ready for it. In running your
production baseline reports, run both the Sales Journal by GL Account (in Revenue Accounting) and the Journal
Entries Report (in Receivables).

All of the menus, most of the screens and a lot of the functionality changed in Release 10. Allow enough time for
re-training.

There is an optional pre-upgrade step that says ‘either do all of it or none of it.'

Believe them, if you stop in the middle -- your data will be irreparably trashed.

There is a new seeded Descriptive Flexfield, ‘Line Transaction Flexfield’. For the Context value ‘Order Entry’,
Segment 6 is defined and Required = Yes and Display = No - so you get stuck. At a minimum, set Required to No
and recompile.

8 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

Oracle Assets

In Release 9 there were no controls regarding the dates you used to select data for your reports. In Release 10 you
use QuickPick to select the periods to report. With this new feature -- you can run certain reports for a period ONLY
after you have run depreciation. This will impact what you can use for your baseline reports.

Oracle Payables

Oracle has changed the way that they deal with pre-payments in Release 10 and part of the upgrade is a script to
modify the existing data. The date (in relation to the open period) in which you perform your upgrade will impact
whether this is a minor or major issue.

Previously Oracle did not validate the country fields in vendor addresses, in Release 10 it does. A post upgrade step
will provide you with a report of vendors with invalid countries. You can actually correct the countries in production,
prior to the actual upgrade (one less thing to do).

Oracle General Ledger

In Release 9, if you ran FSGs using a report set but you did not assign the report a name - the upgrade process will
assign a name of Adhoc and a number. Clean out and/or name any of these reports prior to the cutover. Note that
you will need to save, analyze and then clean out RG_REPORT_REQUESTS prior to cleaning out the components
(reports, row sets, column sets).

In order to re-activate your budgets (after the upgrade), use the Define Budget Amounts screen (\Navigate Budgets
Enter Amounts)

- Query a budget -- any one will do, go to one of the account fields -- overlay a value with the same value and save.
This will invoke a process to activate your budgets.

General

In Application Developer -- several profiles attained funny end-dates and you cannot use them unless you remove the
end date. \Navigate Profile, Query where Option like ‘Curr%’ and blank out the end date(s).

In System Administrator -- various responsibilities have no Data Groups assigned. \Navigate Security
Responsibility Define. View all active responsibilities -- if there is no Data Group assigned, use QuickPick the
select the applicable value.

AutoInstall

You will get ‘deadlocks’ while AutoInstall is running, so keep an eye on your log. This occurs when one of your
workers stops running. In another session, simply determine the worker ID and re-start the worker.

AutoInstall uses lots of freespace as it runs the various process (it then releases it). Every 30 minutes or so, check
your tablespace freespace. If your see that you are running out of freespace, add more as needed. You can’t rely on
your final free space usage as a measure of what you need since AutoInstall uses and then frees up the space as it
goes along.

Also, check regularly for fragmentation (using lots of extents for a specific table). Increase the amount that will be
allocated to the next extent and increase the maximum number of extents, then you will have enough.

These checks will keep you busy when you have the task of ‘watching’ AutoInstall AND they could keep you from
experiencing much more serious problems.

Upgrading To GUI

9 sur 10 09/09/2010 19:32

OAUG BALANCING PAPER http://www.cathycakebread.com/papers/_upgrade.htm

(Smart Client)

My experience is that most companies continue to use the character screens even when they upgrade to GUI. There
are significant training and adjustment issues with going to GUI. There is no use for the backslash key. You should
use the Tab Key versus the Enter Key and you need a substantial PC to even run the products. You need to
determine how you will handle this -- a phased approach? Everyone at once? One department at a time? And, how
will you insure that they have adequate support? You may want to stabilize your systems on the new release in
character mode before you jump into using the GUI screens.

Web Deployed Applications

These are the web versions of the Smart Client products. Release 11 has been announced as being fully "Web
Deployed" (no more GUI). Prod 16.1 was scheduled to be released as "Web Deployed" by the end of 1997. Even if
you are not ready to be the first on the block to use these products - it is important to keep current on what Oracle is
doing and the system requirements since this is what we will all be using in the future. We were told that you still
need a Pentium 166 or above to effectively run the Web Deployed applications.

Conclusion

An upgrade of Oracle Applications is a major undertaking that requires lots of time and lots of involvement from many
areas of your business. Create detailed plans, build a great team, get management backing and TEST, TEST, TEST
and you should be very successful.

About the Author

Cathy Cakebread - Consultant

(650) 562-1167
cathyc@compuserve.com

I am an independent consultant specializing in Oracle Financials. I have over eighteen years experience in designing,
developing and implementing financial software and I was one of the original designers of Oracle Receivables and
Revenue Accounting. I also have acted a the project manager for six upgrades.

Thanks to Melanie Bock, Mike Conant, Kellie Green and Lynne Paulus for their great tips, which I included in this
paper.

10 sur 10 09/09/2010 19:32