Upgrade discussion

[mrobins100]

Hello everyone,

My name is Marcus Robinson, I am the ServiceNow admin at Clemson University. We are scheduled to upgrade from our current (and initial) version of Xanadu to Zurich next month (just barely before the deadline). 

I have not done a ServiceNow upgrade before (I have done other ITSM software upgrades though), and I was hoping for any advice or tips that you all would like to share.

Aside from learning about upgrades; I would be happy to talk about things I am familiar with; like catalog items and the customer portal, automated testing, and onboarding other IT-departments and non-IT departments into ServiceNow and how to set them up for success.

I do not see any events coming up on the calendar but I will keep any eye out. 

Looking forward to meeting and collaborating with you all.

Enjoy your day,

Marcus

[Tanushree Maiti]

Hi @mrobins100 ,

Step-by-Step Upgrade Process:

• Planning and Preparation:
  • Review Release Notes: Analyze new features, bug fixes, and deprecated functionality in the target release. Your accurate analysis can help you to test those specific component more where changes are there without impacting your customization.
  • Health Scan: Conduct an instance scan to identify potential issues before upgrading.
  • Clone Production: Clone your production instance to non-production instances (Development, Test) to ensure a mirroring environment.
  • Backup: Ensure recent backups are available for a rollback if necessary.
• Non-Production Upgrade (Sandbox (if any), Development , Test , Prod Staging(if any)):
  • Schedule Upgrade: Use the Now Support (HI) portal to schedule the upgrade for sub-production instances.
  • Run Upgrade: Execute the upgrade and monitor its progress.
  • Post-Upgrade Validation:
    • Review Skipped Records: Analyze the skipped records log to decide which customizations to retain, match, or revert. // Best Practices to manage skipped updates effectively during upgrades
    • Functional Testing: Perform manual and automated Regression testing (ATF) to verify core functionalities, UI policies, and business rules.
    • Fix Issues: Remediate any broken integrations or customizations found during testing.
• Production Upgrade:
  • Schedule: Once testing is successful in non-production, schedule the production upgrade via the HI Portal during a low-usage window.
  • Execute and Monitor: Perform the upgrade and actively monitor for defects for one to two weeks following completion.

[mrobins100]

Tanushree, thank you for the response.

I have questions about reviewing skipped records. Does this step occur on the builder instance?

What if we have not designated a builder instance yet? I just became aware of this concept yesterday, and we have already upgraded my Dev and Test2 environments. Currently we are using those are our development environments and using Test as our staging-ground for promoting update sets. I would like to set the Dev instance as the builder and all others as the consumers, but I am not sure if we missed the deadline for that.

Thank you again for the help so far.

Marcus

[DerekH120104488]

Hello,

The other comments are accurate with the steps for upgrading. However, you should also make sure to update the store apps when you upgrade your instance. Most people assume that upgrades automatically update your store apps, but they do not. After you complete your upgrade, I would then install any store app updates. So your steps would look something like this. 

1. Clone over dev & test
2. Upgrade Dev
3. Install Store updates to Dev
4. Mitigate any issues
5. Upgrade Test
6. Install Store updates to Test
7. Apply Update sets
8. Test
9. Mitigate
10. Upgrade Prod
11. Apply Store updates to Prod
12. Apply update sets to Prod

[goldenjc97]

 - This is kinda the steps we take. We have a PROD/TEST/DEV which really helps. 

• We do a fresh clone of TEST/DEV from prod and include attachments, etc...
• Then we will upgrade DEV
• Start your update set(s) to capture your changes (you'll need an update for each app scope you have changes in)
• Go through all of the Skipped Updates (really focusing on the high priority items as they are numbered)
• If we modified something and need to retain our version, we do so... otherwise we try to always revert to base and take the SN update
• Now we conduct our testing in DEV - make sure our integrations work, spot check everything. We are not a huge/complex company, so this isn't but a few days for us. 
• Scheduled upgrade for production
• Upgrade production and commit your update set(s)
• Spot check the same integrations and anything else you feel needed
• If you noticed, we skipped TEST. We do this intentionally to have TEST on our previous version. If any issues/weird things are brought up post-prod, we have our TEST environment to compare and see was this happening before the upgrade. 
• After a couple weeks, we clone TEST/DEV and get us all in sync.

Not sure if this is best practice, but what we have done for many years, and it has worked well for us. 

Hope this helps!