As we come to grips with the new technology and functionality it is all too easy to forget the basic, common-sense elements that will bring your upgrade in smoothly.
1. Upgrade Timetable needs to be very detailed.
The upgrade timetable sets out precisely who will perform what when during the upgrade weekend. It also contains the contact numbers (and backup numbers) for every person potentially involved in the upgrade effort. Start with the following list:
- System Administrator / Apps Support
- Functional Specialist(s)
- Network Support
- PC Support
- Operating Systems Support
- Finance Manager
- IS Manager
- Building Security
- Key Users (for Production Readiness Testing)
2. Upgrade Team Members Notes.
Prepare detailed notes for yourself for the go-live weekend. As you go through your test upgrades note down everything that you do, every profile option that you set, every piece of setup you change, ensure all back-end hacks are scripts. You have to assume that when it comes time to do your pre and post upgrade steps it will be around 2am and you will not be functioning at your best. Since there is no room for error here (the upgrade weekend is a precisely timed team activity) you will need detailed notes (with navigation paths and screen shots if possible – you may be hit by a bus).
3. Table changes won’t necessarily cause the customisation to fail
With certain customisations, such as SQL scripts, it is more effective to just copy them across to the new release and run them (the so-called “suck-it-and-see” approach to redevelopment). Some of these customisations will fail silently after an upgrade, for example your Release 10 custom EFT extract. The fields still exist in the transaction tables for bank account and bank number but they’re only populated for your old data. The new transactions only get an external bank account ID.
4. Don’t forget your interfaces.
It’s not just the Purchase Order and Cheque Prints that we need to worry about. Sociability testing is vital – we have to ensure that Oracle Apps can still “play nice” with the other kids in the playground.
5. Test the standard report or form before customising.
When a new release hasn’t had a lot of time to “bed down” yet we can’t afford to assume that the standard report or form already works before we start customising it. It can save days of redevelopment if you just run the standard report first. For example there are currently issues with the Invoice Print in Accounts Receivable on Release 11.5.2 11i.AR.B.
6. Archiving and Purging
If you’ve been thinking about archiving and purging … now is the time. Upgrading is like moving house – you throw out the old stuff before you leave rather than after you’ve moved. Archiving and purging prior to your upgrade has two main benefits:
• Performance – the smaller the database the shorter the downtime for AutoUpgrade
• Data Integrity – the older releases of Oracle Applications did not have the same data integrity constraints that Release 10 does. As a result, the data most likely to cause problems during the upgrade will be the oldest, entered in the earliest releases. If you can purge data entered in Release 9 and earlier, try to do so.
7. The Customisation Assassination Squad
An unofficial sub-agenda of most upgrade teams is “kill as many customisations as possible”. The maintenance costs of customisations are significant, multiply it by the number of anticipated patches to that functionality. Suffice to say, every customisation that you kill reduces the upgrade effort, testing effort and upgrade risk. From an upgrade perspective – Vanilla is a good thing.
8. Keep a list of normal batch jobs to submit after the upgrade.
Your recurring concurrent requests from Release 10 will have been cancelled and need to be re-submitted (we can’t just put them on hold as they may now have new parameters). Don’t forget the periodic alert scheduler and schedule your new Sysadmin jobs, such as Purging the data from the RX interface tables. Another good candidate is Generate Accounts in Fixed Assets since the first time it is run following an upgrade from Release 10 it needs to generate the accounts for every asset currently in the system. This may take a while so best to kick it off well in advance of month end.
9. Implement a software freeze in your production environments for all customisations.
During the upgrade, your $APPL_TOP is not “upgraded” only the database. You will manually copy your custom code (say $CUSPO_TOP/srw/cuspowow.rdf version 1.0) to the new R11i $APPL_TOP ($CUSPO_TOP/reports/cuspowow.rdf version 2.0) during the TEST upgrade and regenerate the report in Reports6i. After you have taken this copy of your customisations no further changes to the production version of the report will still exist in the post-upgrade world.
So if we were to make changes to the custom report in our production system (cuspowow.rdf version 1.1) we need to make the same changes to the Release 11i version of the report (cuspowow.rdf version 2.1) for these change to still be there after the upgrade.
10. Testing …. there is no substitue!
A little-known sub-law of Murphy’s – whatever you don’t test will not work when you go live. For example, run every single FSG that you require as part of end of month. Yes, all of them. In the time it takes you to argue about this you could probably have submitted them 🙂