Upgrade Best Practices - Reverting Skipped Files
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-03-2022 10:13 AM
Hi,
I'm looking for some quick best practice guidance on the upgrade from Quebec to San Diego which we are currently working on. We have two sub instances ("Dev" and "Test") which we have already upgraded to San Diego. We are planning on upgrading our production instance to San Diego in July.
We are currently reviewing skipped files in our lowest instance "Dev" and are wondering about the best practice way to handle "Reverting to Base System" option. If we choose to revert a business rule for example, this change is tracked via an update set and then we can move the update set to the next sub environment "Test". Should this update set be moved before or after we have upgrade our next instance?
I have read some community posts with mixed signals with some saying you should move the update set to the next instance, and then upgrade. Other ones say you should upgrade and then move the update set.
Our assumption is the best practice is to track the skipped file in an update set first in your lowest environment and then move this update set to the next environments after it's already been upgraded.
Any clarification on this would be much helpful. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-03-2022 10:16 AM
Hi,
The update is moved AFTER the upgrade is done.
So essentially, only Dev would have been upgraded (this is so multiple environments aren't misaligned with the version and allows you to work on the fixes in the lowest environment first).
I wouldn't have had both Dev and Test upgraded and Test just sitting there while you all are working through your changes in Dev.
Only Dev should have been upgraded, you work through skipped changes, verify ATF and application functionality, full regression, etc.
Then, once everything appears good to go, Test is upgraded and right after that update set is moved from Dev to Test and committed. Then double-check things again in Test, you wouldn't work through the skipped changes all over again, as you've already done that in Dev.
Once Test is good, if anything is caught there, return to Dev, fix it, if applicable, make a second update set for those things, and then upgrade Prod, this time promote your main skipped changes fix AND the other update set (if applicable), and this time, lightly check things in Prod as best you can.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-13-2022 03:17 PM
Hi Tyson,
Just wanted to check-in and see how you're doing.
If my reply above helped guide you Correctly, please also mark as Correct.
Thanks and take care! 🙂
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-03-2022 12:00 PM
UC Berkeley Telecom Catalog instance does it in a similar way as expressed by Allen. Note: We have another instance which has a different process.
- we have 3 instances: dev, test, prod
- Run pre-clone ATFs in dev and test
- clone dev and test at the same time. Do post-clone activities
- run post-clone ATFs in dev and test
- upgrade dev
- in dev, do skip/revert/merges (some of which go into an update set)
- in dev, run post-upgrade ATFs
- in dev, validate system, post-upgrade
- in dev, export skip/revert decisions, close update set
- upgrade test
- in test, apply dev skip/revert decisions
- in test, apply post-upgrade update set
- in test, handle any extra skip/reverts
- in test, run post-upgrade ATFs
- in test, validate system
- in test, export skip/revert decisions
- upgrade prod
- in prod, apply test skip/revert decisions
- in prod, apply post-upgrade update set
- in prod, handle any extra skip/reverts
- in prod, non-invasive smoke-test to validate system
If you have any questions, please don't hesitate to ask.
Thanks,
Terri
---
Terri Kouba, ESM Service Manager University of California, Berkeley Berkeley Information Technology | Enterprise Service Management Email: kouba@berkeley.edu We champion diversity. We act with integrity. We deliver. We innovate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-15-2022 08:50 AM
Hi Terri - thanks for sharing this. I can't seem to wrap my head around how applying the update set with the Replace on Upgrade after the prod upgrade helps. Shouldn't these be set first, so that the upgrade replaces them with current and then gets them off the future Skip list.
Thoughts?