Updating all plugins to latest version after upgrade/skipped records
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
In the past for our annual double family upgrade, after completing skipped records, we would go back and update major plugins (HR Case Management, SOW, etc.) before developing for new features provided in the family upgrade. Recently, we've began updating every single plugin (200+) in the Application Manager under Updates right before testing and right before go-live because we want to have the latest version before testing the upgrade. This is because we rarely, if ever, update plugins in between family upgrades, so we want to have the "latest and greatest" when we go-live.
What does everyone else do in this scenario? Do you allow the upgrade to "true up" your plugins to the minimum compatible version and go with that? Do you upgrade plugins only when developing for them? If you upgrade every single plugin that has an update available, how do you do so (one at a time, CI/CD spoke, other method) and do you do so before testing and before go-live?
Our situation is further complicated with the newish SN application repository as several of our scoped apps have been mysteriously converted to custom applications we can no longer update via the Application Manager... but that's a different post.
Any and all experiences and suggestions appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
Hi @Sarah Travis ,
From my experience, we handle plugin updates during family upgrades in a few different ways.
Some let the upgrade itself “true up” plugins to the minimum compatible version, which keeps things simple and reduces risk. Others only update the plugins they actively develop against, so they don’t introduce unnecessary changes. And then there are teams like yours who prefer to update everything before testing and go‑live, so they know they’re running the latest versions across the board.
The trade‑off is effort versus stability. Updating all 200+ plugins before testing means QA reflects exactly what production will look like, but it’s a heavy lift. A phased approach is common: update critical plugins (HR, ITSM, SOW, etc.) before testing, then handle less critical ones later if needed. Some teams automate this with CI/CD spokes, while others still go one by one in Application Manager.
Your “update everything before go‑live” approach makes sense if you rarely touch plugins between upgrades — it ensures consistency. But you might save time and reduce risk by focusing on the major plugins first, then rolling out the rest in stages.
