IMS Generic Software Upgrade Plan

Products

• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)
• DX Unified Infrastructure Management (Nimsoft / UIM)
• IMS TOOLS - MISC

Issue/Introduction

When upgrading a Broadcom IMS Software product having a written upgrade plan can help ensure a successful upgrade or
 make sure the necessary backups and configurations have been saved to recover should things go wrong.

The  Software Technical Documentation landing site  provides useful links that cover Release Notes, Installing, Upgrading, Securing, Maintaining and Administering the product .

The Resolution section  of this article include best practices to help guide you in developing an upgrade plan that Support can review with you.

A couple weeks ahead of an upgrade, please:

• Open a case with Support.  You'll be asked for an upgrade plan. This article can be used as a basis for your upgrade plan.   An upgrade plan is typically a couple of pages long, but sometimes can be detailed down to the smallest detail so that nothing is missed and Support knows what's happening if something goes wrong and troubleshooting is needed.
• Contact your account management team and request a Hot Site for your upgrade event so we can engage you and perform a pre-event review with you to ensure everything goes smoothly 

Environment

IMS Products 

Resolution

Pre-Event Planning

Testing:

• Did you test this in non-production first?
  • If possible, configure your Test Environment to mimic the Production Environment.
  • If test and production are not similar, what is difference between the two?
• Create a Testing Plan to include:
  • Tests to be used on Test Environment to validate upgrade
  • Tests to be used on Production Environment to check if upgrade is successful and doesn't need to be rolled back.
  • Tests to comprehensively validate that all deployments are working as planned once the upgrade has been fully completed. 
• Did you run into problems with the non-prod upgrade?  If so, what sorts of problems did you run into?  The workarounds/solutions should be noted.

 

Backup plan:

• What will you be backing up prior to upgrade?
• When will you take the backup?

 

rollback plan:

• When will you make the decision to back out in case something goes wrong?
• What steps will be taken to back out of the upgrade?
• Do you have a workaround in the meantime?

 

Timeline should include:

• When does the installation or upgrade begin (date and time)?
• What date/time will you stop components that need to be stopped?
• For each component:
  • What date/time will do you plan on updating each component?  
  • How long will these take?  
  • When do you expect to be finished with each component?  
  • How long will testing take to be sure it upgraded correctly?
• When will you make the decision to back out in case something goes wrong?
• When do you plan on having the upgrade end (date and time)?
• If there is monitoring of  APIM components, ensure they are turned off or ignored during upgrade window. 

 

Technical:

• Components:
  • What components are being upgraded?
    • Core  Product components
    • Other
      • Are there any 3rd party components being upgrade?  Examples:
        • Database (from, to type and versions?)
        • OS patches (from, to flavor and versions?)
        • OS in general (from, to flavor and versions?)
  • What steps/commands are you using to upgrade each component?
  • Are you copying a database?  
    • If so, is there enough space on the target server?
  • Is this an upgrade of a current system?  
  • Are you migrating data from one system to another?
  • Is there any pre-work to be done on the system before stopping to upgrade?
  • In what order will you be stopping running components?
  • In what order will you be starting components back up?
    • What commands will you use to start them up?
    • What user and environment settings are normally used to bring up the processes?  What will be used during and after the upgrade?

 

If something goes wrong:

• What is an acceptable situation/workaround if something does go wrong?  How long can it stay like that?
• What is your rollback plan for each component?
• Who from your team needs to be available for troubleshooting? This should include:
  • All key personnel/stakeholders within your organization (Operations, Database Management, Networking, Release Managers, etc..).
  • CA/Broadcom Technical Support. Do you have the support number to call in case something goes wrong?  Severity 1 cases cannot be raised from the website.  Use a new case when running into a new issue.

 

 

Additional Information

The attached document can be used as a generic baseline for your upgrade planning/runbook.

This document can be modified to include

• Prerequisites
• Upgrade Tasks
• Post-Upgrade Tasks
• Helpful Documentation Links
• Recovery Steps (Not Included but easily added)