This content has been marked as final. Show 3 replies
That's an interesting challenge coming up there.
If I resume, change hardware, OS, Peopletools and application, right ? When do what ?
I'd definately share your point of view, hardware and OS change are more welcome to be placed on the Peopletools upgrade rather than application. Especially within the Peopletools 8.50, depending of your OS, you could have no choice anyway (if it was a 32bit OS, it is not supported anymore within PT8.50). Having a stable environment is a must before going to the application upgrade, and if you can afford you to separate, then do not hesitate.
Someone also brought up a good point that with the app upgrade, they like to have the old 8.9 up and running in parallel with the new 9.1 and the best way to do that is by having separate servers,I'm not sure to get the point about parallel running of both applications. During the dev regarding the upgrade, then yes, both have to be up. But once it's in prd, the old appl should be "read only" (with backend queries?), just in case, but appl should be turned offline anyway.
Regarding separate server, I thought you wanted to change hardware, so better to keep up and running your 8.9 appl on old configuration, and the 9.1 on the new one. Choice also depends of your source OS as I said above, PT8.50 is not certified on a 32bit OS.
I'll give you a little insight in the situation at one of my clients, which is in exactly the same situation.
Customer decided to upgrade to HRMS9.1 with PeopleTools 8.50. New hardware was bought and implemented. We used Oracles Red paper on Clustering & High availability to setup the new hardware. We installed PeopleTools 8.50 with HRMS9.1 on the new machines. After that we copied the current Production environment into one of the new database servers and upgraded that database to tools 8.50. That database was used to create the entire new DTAP street. We basically cloned the to Tools 8.50 upgraded DB into a Development, Acceptance and Production environment. Once the new hardware was fully installed with Tools 8.50 and HRMS9.1 we tested the functionality of the load balancing etc. Once this was done we cloned the current production database again and did a Tools 8.50 + HRMS9.1 upgrade. Since the complete environment (appserver, prcs scheduler, webserver etc. etc.) was already installed, we only had to focus on the upgrade and testing itself. We left the old environment running as it is and it will be permanently brought down after a year or so.
The big difference is that we decided to do the upgrade in one big project, we didn't go live with tools 8.50 before HRMS was upgraded. This gave us a lot of freedom of configuring etc. since it didn't affect end users. I don't think you should have a separate go live moment in your situation, especially since you're already on tools 8.49. It only introduces a new test moment which requires a big chunk of work. You also have to introduce two downtime moments when splitting it. I also think it's better to have one big test moment and not two smaller ones. One argument that I sometimes hear is that if an error appears it's difficult to point out if it's tools or application related. I don't agree however; PeopleTools errors are very different from application errors and it's never hard to find out if an error is tools or app related.
Hope this helps a little.