Now, the organisation was going under a major structural change, so the customer wanted to perform the PeopleTools upgrade with a minimal disruption of their activities, as it was difficult at that time to obtain the needed sponsorship from higher managerial levels. In other words, they wanted to perform the upgrade as silently as possible. This translated in two particular requirements:
- Ability to perform the PeopleTools change with zero downtime, in order to avoid any impact on the users.
- Ability to gradually move users from the old PeopleTools release to the new one, practically limiting the impact of any product issue related to the upgrade. In case anything failed, they wanted to be able to move the users back to the old release.
I cannot say it would work for any other combination of PeopleTools and application versions, nor different customer usage of the application. Anyhow, I thought it may be useful to share it with you, in case any of you can enrich the approach with your feedback. In the next post I will describe the approach and in the third and final one I will describe the issues we faced during the implementation. So... keep tuned ;).
Sounds really interesting. Looking forward to reading about your approach.
ReplyDeleteSounds very interesting indeed.
ReplyDeleteDid you do it with 2 paralel systems with (near realtime datatransfer)?
@Duncan, thanks for your feedback. I hope you find the other post also interesting.
ReplyDelete@Frank, thanks also. Using DB links is probably not the fanciest approach, but it was quite simple.