02-02-26 11:49 AM - edited 24-02-26 11:15 AM
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:
In this stage, you'll decide:
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.
There are 3 factors to consider here:
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.
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.
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!
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.
In this phase, you'll make a plan for executing your upgrade. You'll need to:
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.
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:
You can find out more about the different approaches to executing an upgrade, including a table of pros and cons, here.
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:
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.
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:
For more on Disaster Recovery and contingency planning, visit the Robotic Operating Model 2 page on Operations.