Upgrade Plan vs update sets with record customizations

[Kristin J]

Hello!

Regarding the new Upgrade Plan feature, I would like to use it in my future upgrades/patches but I need to validate my understanding of how to handle record changes.

If I understand the scope of the Plan when it comes to capturing changes to records, it will only capture changes made to skipped records identified in the upgrade on the Builder instance. The scenario I would like to validate is:

1. On my DEV instance upgraded to Utah, I have a behaviour that is not occurring on my Tokyo Test/Prod instances
2. The affected record was not flagged as "skipped" during the upgrade process

In that scenario, what I THINK would happen is:

1. Any change I make to that record will not be captured in the Upgrade Plan because it was not flagged as skipped
2. Any change I make to any record that was not flagged as skipped will not be included in the Plan
3. Fixes to non-skipped records need to be captured in an update set
4. Update sets are promoted through my other environments as usual (once they have been upgraded to Utah with the Upgrade Plan installed)

Thanks for any info or experience you have with this. 🙂 If anyone has used the new Upgrade Plan when moving to Utah, I'd love to know how it went for you.

Cheers,
Kristin

#tokyo #upgrade #utah #upgradecenter

[Luiz Lucena]

Exactly! 
Had some issues with that as well, which almost compromised other stuff we were working on because some of our customizations were then moved to an application "Global Customizations - Upgrade Plan".

We were working on some updates to few forms and UI actions and without we noticing, some of those were not in Global scope causing issues with different scopes in upper instances. 

To solve that, I had to mark the "Global Customization - Upgrade Plan" as complete and move to upper instances before commiting other update sets. 

Recently, looks like ServiceNow released an updated version of that, because I noticed that a recent change we worked on a record, created a batch update set for it. Which didn't happen when we upgraded to Utah patch 0.

[nickc1]

I thought Upgrade Plan was a great idea, but then I tried to use it.  There are so many gaps in the documentation and the implementation and it seems no one knows how it works. I went to the London Now Forum expecting a knowledge transfer, but literally no one knew about it!

First thing that is not clear is that you still have to schedule the upgrade yourself for each instance. Make sure you schedule the same patch as the one you have built the upgrade plan for, or it will get ignored.  Seems reasonable seeing it written here, but the docs do not specify any of this.

Second is that the upgrade plan is run as part of the scheduled upgrade, so when complete, all your plugins and apps will have been upgraded to whatever you did on your builder instance... except...

...if you get to prod and find that you have accidentally installed any plugin that you are not licensed for on the builder instance, then the upgrade plan will not update any plugins/apps.  This is infuriating as it is very difficult to be 100% certain of what you are licensed for on a subprod instance and unfortunately, it is not unusual for plugins you are licensed for being specified as unlicensed and if you are upgrading out of hours, you cannot contact the account manager to get it resolved. So then you have wasted your time sweating over this product and have to revert to manual mode.

Thirdly, there is the issue of what has been captured in the Upgrade Plan.

Skipped records were captured and updated when we migrated to test, but this completely failed in prod.  We took the opportunity to capture the skipped records in an update set, so were able to commit these in prod.  I haven't experienced the scenario described in the question above, where the individual updates were put in a different application.  

What was far more damaging was that 3 hours after we had finished the upgrade a handful of system properties were updated in prod which could only have come from the dev instance (the values had the suffix dev). This caused a major incident to be raised.  I've trawled through the upgrade plan and the sys_app table and I cannot find these updates anywhere.  The Upgrade Plan is completely opaque.

If you are a partner upgrading a small client with no customisations, no doubt this product will save you time.

If you are an end client and have meticulously planned your upgrade, then get ready to dispose of that plan when you get to the prod instance.  Make sure you have a fallback and have covered yourself and left enough time to do all the plugins/apps manually.

To conclude, despite all the problems I want to use Upgrade Plan again, as the potential savings in time and energy are huge, but I doubt anyone else in my team will agree with me.