A Strategic Approach to Managing Plugins: Determining a strategy for addressing outdated plug-ins

amarks
Tera Expert

Challenge

I set out to review our technical position and develop a strategy for managing and upgrading our ServiceNow plug-ins. We’ve inherited an environment that’s lagging behind on updates, and getting a clear picture of our status proved more challenging than expected.

The difficulty lies in the fragmented nature of the information:

  • There’s no reliable mapping between technical plug-in names and their “friendly” names.

  • There’s no connection between platform/patch release documentation and plug-in release notes.

  • There’s no aggregated source for plug-in release notes.

  • And without a tool to collect and consolidate this data, it’s tough to assess where we stand or what our upgrade priorities should be.

App Store for Plug-In Info

The ServiceNow App Store seems to be the most promising single source. It can — at least programmatically — surface key details: installed and active versions, the latest available versions, dependencies/requirements, and even release notes.

 

The challenge is that release notes are tied to individual versions, and since many of our plug-ins are multiple versions behind, I need to understand what’s changed across all the versions we’ve skipped. That means stitching together multiple release notes to understand the cumulative impact of an upgrade.

Goal

My ultimate goal is to build a strategy — one that aligns upgrade priorities with organizational value and risk. To do that, I need a clear picture of:

  • Where we are today (current plug-in landscape)

  • Where we want to be (target versions)

  • What each incremental update includes (new features, fixes, deprecations)

That’s the only way to rationally prioritize upgrades based on how we use each application and what value or risk each update represents.

Solution [the ask from ServiceNow]

  • We need access to a repository of plug-in release notes, by plug-in version, by plug-in , by product/friendly name/module/etc., so that we can enumerate all the notes for all outdated plug-ins that are highlighted through the App Store and populated in the corresponding tables.
  • Accordingly, we need to understand the schema and understand how Versions, Products, Applications, Components, and Plug-ins are related.
  • Ideally, this would already be available as part of the upgrade management framework within ServiceNow.
 

Questions for the Community

  1. Does this ask have value for others? We have two use cases: a) A one-time effort to bring us back into "compliance" and b) an ongoing effort to remain compliant. Because the App Store can enumerate all outdated plug-ins, this could be a monthly effort that automatically reports outdated plug-ins along with the corresponding release notes.

  2. How robust and complete are the release notes for each version in the App Store? (That feels like the biggest unknown.)

I’m not trying to boil the ocean here — just invest the right amount of time into a sustainable solution. I think I’ve solved a key part of the problem, but I’d love feedback on how much ground this really covers.

Thanks,
Adam Marks

1 REPLY 1

pavani_paluri
Tera Guru
Tera Guru

Hi @amarks ,

 

We can try adding one more parameter Plugins by Business Capability. We can include Map plug-ins to business functions (e.g., Incident Management, CMDB, HRSD) to align upgrades with stakeholder priorities.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P