APIM Software Upgrade Plan / Pre-Upgrade Review

Products

• CA API Developer Portal
• CA API Gateway
• CA API Gateway Enterprise Service Manager (Layer 7)
• CA API Gateway Precision API Monitoring Module for API Gateway (Layer 7)
• CA API Management SaaS
• CA Mobile API Gateway

Issue/Introduction

As a APIM Software  customer planning on upgrading API Gateway / API portal , what are the best practices in ensuring a successful upgrade? 

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

The Resolution and Additional Information sections 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

APIM 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?

 

Backout/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 API 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 backout 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

Upgrade Planning

The guidance offered in the Upgrade API Gateway page or  Upgrade API Portal should be used as a basis for your upgrade plan. This section is split into two parts to:

1. offer additional guidance (not explicitly documented in the Upgrade page).
2. Some additional information and useful links.

 

Additional guidance (not explicitly documented in the Upgrade API Gateway or Portal page): 

• Review the Release notes  page to make sure the versions of Operating Systems and Databases used in your environment is supported by this version of  API Gateway or Portal.
• Review the Compatibility Matrix  page to make sure the upgraded version is compatible with other API products like Oauth, Mag and any other integrations you may have.
• The recommended goal should be to upgrade the latest supported version of API Gateway or API Portal  and then apply the latest cumulative patch.  
  • Cumulative fixes can be found here: CA API Management Solutions & Patches
  • The latest version of the product can be found in the download section  My Downloads - Cyber Security Software

Additional information and useful links:

• CA API Gateway - Upgrading your Gateway Appliance from 10.0 to 10.1
• API Gateway: Reinitialize replication in a multi-node cluster