cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_S
Community Team
Community Team

Careful planning is key to upgrading any enterprise software. In this article, you'll find a collection of resources to help you make a plan for your SS&C Blue Prism Enterprise upgrade. It's split into 3 main categories:

  • Assessing upgrade needs and options
  • Planning your upgrade project
  • Executing the upgrade and post-upgrade stabilization

 

The Assessment Stage

In this stage, you'll decide:

  • Do we need to upgrade?
  • Which target version of SS&C Blue Prism Enterprise should we upgrade to?
  • What are the costs/risks associated that we need to consider?
  • What add-ons / other automation solutions are impacted by the upgrade?


Do we need to upgrade?

You can use our Upgrade Decision Tree as a foundation for deciding whether or not you need to upgrade and get an idea of whether you should do it now, next or later. 

You should also consider the features available in the latest version of Blue Prism and how they might impact your automation program. Newer features like backwards compatibility, webhooks and chromium spy modes may make your automations easier and faster to create or maintain. 

 

Which version of SS&C Blue Prism Enterprise should we upgrade to?

There are 3 factors to consider here:

  • What is your organization's appetite for risk?
  • What new features do you want to adopt?
  • How complex is the upgrade path from your current version?


Upgrade strategies and risk

Amongst our community there are 2 trains of thought when it comes to upgrades. Either be a first adopter, or opt for an "n-1" upgrade strategy.

First adopters move to the latest version of Blue Prism Enterprise as soon as they can to ensure they're always working with the latest features and improvements. However, they accept the risk of new versions carrying unresolved bugs or issues which need to be patched later.

n-1 take the approach of adopting the latest version minus one. So if the latest version is 7.5, they'll move to 7.4. They miss out on the very latest features, but reduce their exposure to known issues. 

 

What new features are available?

New updates means new features which may (or may not) be useful in scaling and improving your automation operations. For example, 7.5 introduces new ways to use webhooks - so if integration with external systems is on your automation shopping list, you'll want to target 7.5. 

We recommend reviewing the What's New section on our documentation site to get an overview of the key features in our latest releases, then discussing with your team.

 

How complex is the upgrade path?

If your current version of Blue Prism Enterprise has been patched / hotfixed, you might not be able to directly upgrade to your target version (this is due to database schema updates and feature dependencies - such as JavaScript improvements). We've built a tool that allows you to see these upgrade path limitations, and check whether you need to make a version "hop", here.

 

Tip: Always be sure to select the latest version at the top of the page when you visit the documentation site!

 

Is anything other than Blue Prism Enteprise impacted by an upgrade?

A big consideration that will inform your choice of when and how you upgrade (and sometimes even which version you upgrade to) will be the other products that form your automation tech stack.

For example, upgrades that involve Blue Prism Hub, Interact, Desktop etc add significant complexity - and we always recommend that customers make use of Knowledge Support hours or our Product Upgrade Assurance service to get professional help and advice on these upgrades. 

We also recommend checking the "Plan an Upgrade" section of the documentation site for additional considerations before proceeding. 

 

Planning your upgrade

In this phase, you'll make a plan for executing your upgrade. You'll need to:

  • Understand the scale of the upgrade project
  • Decide on how you will execute the upgrade
  • Involve the right stakeholders and decide work-to-be-done / RACI
  • Make a contingency plan in case you need to rollback

 

Mapping the scale

Understanding the scale and scope of your upgrade is vital for allocating appropriate time and resources, and setting expectations with stakeholders. We've put together a few example questions you can ask about your processes and infrastructure here.

 

How you'll execute the upgrade

There are multiple ways to carry out an upgrade and which one you select is largely dependent on the scale of your automation programs, and the number of "business-critical" automations you have running. The 4 common approaches are:

  1. The in-place upgrade: You'll install the upgrade directly onto your existing infrastructure. Best for smaller operations, teams with high risk appetite or limited infrastructure budget/availability.
  2. Side-by-side / Parallel / Migration: You create an entirely new Blue Prism Enterprise environment built on the new version, which keeping your existing environment running during the upgrade. Once your new environment is built, you migrate your processes to it. Best for teams that want zero downtime and a clean start - but requires significantly higher up-front effort than in-place.
  3. Cloning: Similar to Side-by-side, but instead of creating an entirely new environment - you clone your existing production environment and upgrade it directly. This is best for organizations that need to keep their environment history without the risk of an in-place upgrade. 
  4. In-place with Backwards Compatibility: This is a wholly new approach available to users of Blue Prism Enterprise 7.5+, and is effectively a "staggered" version of the in-place upgrade method. Here, you would use backwards compatibility to upgrade your Application Server and Database, but leave your runtime resources on supported older versions. This allows you to take advantage of new features for future automations, without having to make changes to existing automations as part of the upgrade project. 

You can find out more about the different approaches to executing an upgrade, including a table of pros and cons, here

 

Involving the right team

Upgrades impact several stakeholders across your organization, and it's likely you'll need support from other teams. It's a good idea to map out:

  • What the specific tasks you'll need to carry out during an upgrade are
  • Who will execute those tasks
  • Who is responsible, accountable, consulted and informed (RACI) about those tasks

Planning this with plenty of time allows you to set and manage expectations with stakeholders about the impact of the upgrade. It also allows you to ensure that other teams have sufficient resource available to help you during the upgrade - preventing unexpected setbacks. 

We've put together a sample RACI for you to customise here - though keep in mind the specific "jobs to be done" and accountabilities will be different for your organization setup. A "Centre of Excellence" style automation program will have very different RACI to one that is run by a central team.

 

Contigency / Continuity Planning

Being prepared if things go wrong is part of good planning, and knowing what you'll do if the upgrade fails, takes longer than expected or causes unexpected changes to your environment will help you and your team reduce the impact on your stakeholders. This is sometimes (ominously) called "Disaster Recovery" (or DR for short). 

Some things to consider for your DR plan include:

  • Taking comprehensive backups: In particular of your database, configuration files, licenses, user credentials, virtual machine images and encryption keys. This is especially important if you're carrying out an in-place upgrade.
  • Clear "Go / No-go" milestones: Make sure everyone involved in the upgrade knows where these checkpoints in the process are, and what criteria must be met before the upgrade can proceed. 
  • Detailed rollback procedures: Documentation that covers the exact steps to restore the database and other backed up files to return to business-as-usual if necessary.

For more on Disaster Recovery and contingency planning, visit the Robotic Operating Model 2 page on Operations.

 

 

Version history
Last update:
‎24-02-26 11:15 AM
Updated by:
Contributors