Plan an upgrade

Upgrading software in an enterprise-level production environment is not a task that should be undertaken lightly and success is almost entirely down to thorough planning. A Blue Prism upgrade involves a large number of tasks, requires collaboration between multiple stakeholders, and includes risks that need to be managed appropriately. Therefore, planning is critical and its importance cannot be overstated.

The benefit of upgrading must be carefully weighed against the implementation effort: perhaps the performance of existing processes will be improved by a new version of Blue Prism; maybe new functionality is required to successfully deliver a new project; or more simply, the current version is nearing end-of-life and will soon become unsupported. It is important to note that upgrading the Blue Prism version is unlikely to resolve issues with the platform or individual processes if these issues are a result of poor design or implementation.

A Blue Prism environment is comprised of more than just the Blue Prism software and care must be taken to plan the upgrade carefully to make the execution goes as smoothly as possible. Planning can be broken down into the following stages:

• Upgrade Scale
• Upgrade Strategy
• Release Notes
• Operational Impact
• New Functionality
• Other Changes

Upgrade Scale

It is vital to understand the scale of the estate when planning an upgrade. A detailed understanding of the Blue Prism solutions and the Blue Prism infrastructure is necessary to plan the upgrade project effectively. Below are some key considerations. However, it should be noted that this is by no means a definitive list and there are many other factors which must be considered:

• How many processes are there? How many business objects are there?
• What applications do the processes use? Are they accessed via single-sign-on? How many credentials are there?
• Do the resource machines log into Windows via Login Agent? How many Windows accounts are used?
• Which processes are mission-critical or high-risk?
• How many users are there? What roles do they have? What permissions do they have?
• How many work queues are there? Do any processes use more than one?

The number of infrastructure assets across the estate also needs to be understood in detail.

• How many resource machines are there? How many clients? How many application servers? How many database servers?
• Which ones are for Production and which are for Dev and Test?
• Are any machines multi-purpose? For example, are multiple BP Server services running on the same application server? Or are there clients that can connect to both Dev and Test?
• Are any machines currently redundant? Are there resources registered in databases that are in fact no longer used?
• Will any machines become redundant after the upgrade?
• Will any new machines be required for the upgrade?

Upgrade Strategy

A strategy for setting up an environment, executing the upgrade, regression testing the processes and maintaining operational service should be meticulously planned.

1	Infrastructure Consideration should be given to the infrastructure intended to support the new version of Blue Prism and whether any infrastructure upgrades are also required. For example, is the operating system compatible, is the correct .Net Framework installed and do the machine specifications meet the requirements of the new version?
2	Regression test environment Although it is extremely unlikely that a new version of Blue Prism will introduce major problems to existing processes, regression testing should be carried out nevertheless, and where the testing will take place requires thought. Different options are explored in more detail in Process regression testing.
3	Upgrade sequence Knowing your estate it crucial to identifying high priority processes and planning the testing sequence accordingly. Quite how much time is to be spent testing each process is dependent on its criticality to the business, its complexity, the appetite for risk and the size of the ‘version leap’, i.e. the number of versions between the current version of Blue Prism and the upgrade version.
4	Back-up and rollback It is important to plan for what will happen in the event of an unsuccessful upgrade. Consideration should be given to ensuring backups exist for key data including the Blue Prism database, config files, encryption keys, passwords, machine images etc. Remember that, once upgraded, the Blue Prism database cannot be reverted to an older version. Additionally, Once the authentication mechanism is implemented, it cannot be changed. Backwards compatibility of processes cannot be assumed if importing from newer to older version.
5	Release notes Reading the release notes of every version of Blue Prism from the currently installed version and up to the upgrade version will not only provide an overview of new functionality but vitally, will highlight any additional actions relating to the planned upgrade path. Some versions of Blue Prism require additional upgrade actions (such as an upgrade to Login Agent) and it is essential to be aware of any such steps in versions between the current version and the upgrade version. Particular attention should be paid to the upgrade notices.
6	Operational impact The impact of an upgrade on the business should be defined and documented. Below are some key considerations. However, it should be noted that this is by no means a definitive list and there are many other factors which must be considered: Which processes are (most) business critical? Are any deemed high risk and require special attention? What will the BAU workload be during the upgrade? Are any peaks in demand imminent or likely? Can the business tolerate downtime during the upgrade? Which processes could survive some ‘loss of service’ and which must remain operational? Does the upgrade need to be performed during any particular time-window?
7	New functionality An upgrade can be viewed as an ideal opportunity to incorporate new functionality into the current processes; indeed, this may be the main reason for the upgrade. By contrast, such changes may be viewed as a risk best avoided during the upgrade, and instead the normal Change Request path should be followed after the upgrade is complete.
8	Other changes It is recommended that the amount of change introduced during a Blue Prism upgrade is kept to a minimum. Therefore, updates to Windows versions or application versions are not recommended at the same time as the Blue Prism version is being updated.