Charlotte Skawski of the Hartford (who I know from my participation in the Financial Services User Group) presented her upgrade.
She did a great job of dealing with technical issues (her powerpoint was not where it should have been, and she had to start without one). Fortunately, whe was able to provide her high-level overview prior to the point in which she needed the powerpoint to show additional detail (specifically her upgrade timeline).
Much of the presentation was a good discussion on the methodology for approaching an upgrade, getting buy-in from the stakeholders (especially the end-users who are responsible for doing the fit/gap analysis of the new release as well as testing the data conversion and functionality prior to going live). Also, because the powerpoint covered the topics pretty well, my notes centered on the Q&A.
Q: Could you migrate security in the upgrade?
A: They didn’t have the opportunity to revisit the security rules and kept things pretty much as they were. (this is the place for a shameless plug for a product we’re working on, which I didn’t do in the presentation)
Q: Did you use any automated testing tools?
A: Yes for performance… Use Mercury LoadRunner. All other testing was done manually, although they’re looking to find a solution in this area.
Q: How many test move to productions?
A: Did 3 or 4 originally scheduled. One thing that was a challenge for them was that they couldn’t even get through scripts as originally delivered by Oracle without some tweaking from a performance perspective.
Q: How many customizations were removed due to functionality versus not needing any more.
A: My gut feel is that there were a lot of both. Perhaps half and half.
Q: Did you have issues with your functional users getting pulled from the upgrade to do other things?
A: There were a good number of end-users involved (about 1 dozen), and this was a concern. She talked about how important it was to have a steering committe with executives and how this minimized the amount of pull-back because they had buy-in. Get commitment up-front and show timelines.
Q: Can you tell me more about how you assessed the 8.4 versus 9.0 functionality, including your customizations?
A: We use stat to move code from development to production. We did have documentation on every single piece of code that was moved. Used excel to analyze dumps of the checkin glogs for every piece of code to determine whether it was needed. THis was done in combination with upgrade compare reports.
Q: What about freezing changes and locking down new functionality?
A: We were frozen at end of august for november release. At what point did they lock-down on new functionality.
Q: Did I read that you started on Feb 06 and are still going for the upgrade?
A: No. That must have been an error. It’s a 1 year upgrade Feb-07 to FEb-08.
Q: HOw did table changes affect reports?
A: We didn’t have to rewrite our nVision reports. Most of our queries… We have a lot of queries out there… Ton of public and private queries… we migrated them all over. Not a lot of table changes, so it went smoothly.
Q: Why not upgrade to 8.9?
A: Because the PeopleTools 8.48 enhancements were adopted by the applications. The decision between 8.9 and 9.0 is relatively easy because 9.0 doen’t have that many application changes. Workflow… THey re-built their existing ones because the workflow engine is completely different in 9.0 (tools 8.48)
Comment from Oracle Development: We will now package upgrade directly to service packs versus taking to the GA of 9.0 and requiring customers to apply the maintenance packs themselves.
Labels: 2007, Events