Upgrade Plan Order of Operations - Application Versions

[ChadO]

Since Upgrade Plans were introduced in Tokyo we have used them for our Tokyo to Utah and now Utah to Vancouver upgrades.  Per the instructions in the docs and support articles, we upgrade, address any skipped records, and then create and publish the upgrade plan on the builder instance.  Then we go to one of our sub-prod consumer instances and install the upgrade plan and preview/process it.  Without fail there are Upgrade Plan Items after processing that are in the Error state with a message along the lines of "Application version not found in store."  This is because the version that is currently installed is not compatible with the upgraded instance version (e.g. a Utah-only version of an application while upgrading to Vancouver).

My question therefore is what is the right way to address this?

What I've done with the Utah upgrade and now the Vancouver upgrade is to go back to my builder instance, upgrade those applications that it's complaining about in my consumer instance, refresh and republish the upgrade plan, and then reinstall and reprocess it on the consumer instance.  However, I'm not sure that's the right way to do it.

Do I try and find any application versions that are going to be incompatible with the new instance version and upgrade those prior to doing the upgrade, skipped records, and upgrade plan?  If so, is there an easy way to find those applications needing update?

Is there some other guidance on this?  Any help would be appreciated.

[Kristin J]

Hi there,

Utah - Vancouver is going to be my team's first time trying the upgrade plan. What you're saying makes logical sense to me...but I haven't seen an "approved" way to prevent those errors in any of the literature.  Did anyone from ServiceNow get back to you on this?

When researching how to use this tool, I read that the UP captures changes to plugins as well as decisions around skipped records. So I'm thinking what we will do is:

• upgrade Dev instance
• process skipped records
• update any apps/plugins that have available updates. (No new installs...just updates for plugins that are already installed and less likely to break anything.)
  • We do this process monthly by going to the all applications/plugins list and filtering by "updates"
• build the UP

In theory, this would capture most of these types of errors? I think we will still get caught out on a couple apps/plugins that require an entitlement on Prod for a Vancouver-version only. I anticipate there will be no way to do those except after the upgrade to Prod.

[Ant1]

We are encountering this same issue as well on our first use of Upgrade Plans.  I haven't been able to find a lot of information about how to address those issues.  I'm assuming, we will have to address them manually post upgrade, however that's just a guess.  I put in a case with Support to see what they come back with.

UPDATE:  Feedback from Support was this

1. For records "Application not found in the store" is due to the same version not installed in the prod instance. For example: For 'ServiceNow Benchmarks', installed version on prod is 1.0.1. But in the upgrade plan the version is 3.0.2

-Action need to take :-
a:-For these you need to go to store
https://store.servicenow.com
b. Logged in
c. Search for the application then procured application / Get the application from store
d. Once it is available, install the same in prod

2. For the error "Download dependencies Sources failed from app store, please check the logs for more information"

-Action need to take :-
Please open the classic app manger page , install the versions and its dependent of the apps mentioned in the upgrade plan

3. For few apps , you will not find anything in the store. As these are maint only applications

-Action need to take:-
You should only need to set the 'Active' field to "false" for these upgrade plan items.

For solution in #1, we will address these post upgrade since we will be introducing new modules/apps into production.  Therefore, we will be setting those to false to be ignored during the upgrade.  We were reminded that we have the ability to test out many apps in sub-prods that may require subscriptions if you want to use them in production.

Hope this helps anyone encountering this issue.

[ConradJ]

This is really useful. I have found this by trial and error since I could not find this documented anywhere. It seems some apps in the Store also get updated Terms & Conditions which means you need go to https://store.servicenow.com and Get/Accept them again.

[Kristin J]

Great summary!  The error messages aren't exactly clear. I still have to re-learn what "Customized Version" means every time.

We now use Upgrade Plans for patches also, so that when there has been a store release, we can get the plugin updates done at the same time as a patch. It's been working well. High-level, what we do now is:

1. Clone our subprod
2. Upgrade lowest subprod instance to the latest patch level.
3. Review/manage skipped records.
4. Review available plugin updates & document which ones we are updating.
5. Go to the Store and ensure those plugins are entitled for that new version
6. Update the plugins in Dev & build the plan
7. We now just expect weirdness during the Production upgrade because there always seems to be something that didn't entitle properly or a dependency that's acting up, so we leave time & space in our Change window to install manually.