DocsHigh-level upgrade strategies
There are three general approaches to upgrading Blue Prism, each with advantages and disadvantages. No strategy is the best and the client must decide on the most appropriate choice. Regardless of the approach taken, there are steps common to each.
General procedure
- Create a detailed plan that as well as activity sequence, priority and dependency, also consider:
- Communication
- Workload and business continuity
- Process priority
- Process dependency (e.g. shared objects)
- Inflight delivery projects
- Assistance from outside of the RPA delivery team (e.g. business SMEs, IT, security etc)
- Rollback and DR
- Obtain support and approval for the plan from stakeholders and participants
- Execute the upgrade according to the chosen strategy – See specific strategy sections below
- Regression test processes
- Ideally start from the ‘pre-Acceptance’ test phase
- Reuse existing test scripts
- Focus on the object layer
In-place strategy
An in-place upgrade is where the new software simply replaces the old version. No changes are made to the environment, apart from any required by the new version of Blue Prism, for example an upgrade to the .Net framework. Essentially the idea is to simply upgrade Blue Prism and keep everything else.
The advantage of this approach is that infrastructure changes will be minimal, and the new version can be applied across an environment in one go. No data can be lost because the same database is being reused.
The main drawback is that such an ‘all or nothing’ approach carries risk: if there are issues during or after the upgrade then they must be fixed within the planned timeframe; a full rollback plan will be required in the event of serious problems.
Specific procedure
In addition to the common steps above, the following is a very high-level view of the in-place upgrade procedure:
- Bring the environment to a complete stop
- Back up the database and configuration files
- Make any necessary infrastructure upgrades
- Install the new version of Blue Prism and upgrade the database
- Restart the environment
- Test and confirm upgrade success (or execute roll back)
Obviously meticulous planning is key to avoiding problems and of course the Development, Test and Production (and maybe DR) environments don’t have to be upgraded simultaneously. The plan can and should determine an advantageous, lowest-risk approach, perhaps by upgrading Development first, or maybe by creating a temporary sandbox environment in which to test the upgrade.
Migration strategy
The migration strategy is where a new environment is prepared with the upgrade version and releases are imported into it from the old environment.
The advantage of this approach is that the existing environment can remain active while the upgrade is taking place, and if there are any problems, a rollback is not urgent. The risk of a big-bang approach is not essential, and the migration into the new environment can be done progressively, so that the old environment is gradually wound down, process by process.
Cost and effort are the disadvantages to migrating: new infrastructure needs to be procured and set up; applications need to be installed and configured; parallel environments need to be managed, albeit temporarily; processes need to be moved. A migration needs additional planning to maintain service commitments made to the Business, and care is required not to lose or duplicate workload between the old and new environments.
Having a new, empty database is a great opportunity for a fresh start, provided the effort to replicate the configuration of the new Blue Prism instance to match the old one is accepted and planned for. In contrast, restarting with a new database presents the risk of leaving data behind in the old database and losing important information. The fact that historical data (such as audit trail, logs and queue results) and operational settings (such as credentials and multi-team environment folder restrictions) that cannot be transported between databases via release files may make the migration strategy less desirable.
Specific procedure
In addition to the common steps above, the following is a very high-level view of the migration upgrade procedure.
| 1 | Prepare the new environment |
|
| 2 | Migrate the first process |
|
|
3 |
Regression test the first process |
|
|
4 |
Complete for all processes |
|
Special attention is needed to prepare and validate the packages that define the release contents. It’s not uncommon for package definition and quality to have lapsed, and migration planning should factor in the effort to assess and maybe correct packages prior to export. Similarly, the influence dependencies of shared assets like business objects may have on the plan should be evaluated.
Migration can be viewed as a larger than normal change management exercise, so procedures need to be well defined and accurately followed. If the current approach to project implementation and change management is too casual, then it will almost certainly be inadequate for a successful upgrade.
Cloning strategy
Upgrading through cloning is where the current database is copied into a new environment and then upgraded with the new version of Blue Prism.
As with the in-place strategy, this approach has the advantage of not having to migrate and potentially miss or duplicate something - the whole database is copied, and nothing can be lost. That said, aged and possibly unwanted data is cloned too, and perhaps additional effort to archive and clean such data will be required.
Like the migration approach, the cloning strategy requires cost and effort to prepare a new environment, but this brings the same advantage of being able to keep the original environment operational during the upgrade. Controlling the transition of workload and maybe the progress of inflight projects between the Blue Prism versions is an additional overhead, but the as with migrating, it means the overall upgrade project can be done gradually, with the fallback of the old environment.
Specific procedure
| 1 | Deactivate the old environment |
|
| 2 | Prepare the new environment |
|
|
3 |
Reactivate the old environment |
|
|
4 |
Regression test first process |
|
|
5 |
Complete for all processes |
|
The deactivation step above is to ensure that when the cloned database is brought online, the new application server(s) does not try to run schedules or contact resource PCs that don’t exist in the new environment. This is particularly true if resources PCs are to be reused – care should be taken to ensure the old application server(s) does not try to contact resource PCs that have been connected to the new environment.
Strategy comparison
As mentioned above, no strategy is better than the others and all require careful planning, not just for execution but also for business continuity and communication, and for a possible roll back. The table below presents some of the key features of the three general strategies. Note however that some characteristics can be seen both as a positive or a negative, depending on your viewpoint.
Positives and negatives
| +/- | Description | In-place | Migration | Cloning |
|---|---|---|---|---|
| + | Advantage of a gradual transition to the new version | No | Yes | Yes |
|
+ |
The original environment can remain operational during the upgrade |
No |
Yes |
Yes |
|
+ |
Advantage of a clean start |
No |
Yes |
No |
|
+ |
All data is preserved |
Yes |
No |
Yes |
|
+ |
Data such as audit trail and queue history available in upgraded environment |
Yes |
No |
Yes |
| - |
‘All or nothing’ or ‘big bang’ approach |
Yes |
No |
No |
| - |
Very high dependency on rollback and business continuity planning |
Yes |
No |
No |
| - |
Cost and effort to create new environment |
No |
Yes |
Yes |
| - |
Risk of failing to replicate original BP system settings |
No |
Yes |
No |
|
- |
Risk that applications in new environment will not perform as expected |
No |
Yes |
Yes |
|
- |
Risk of working cases twice or losing cases between environments |
No |
Yes |
Yes |
|
- |
Effort required to verify packages and prepare release files |
No |
Yes |
No |
|
- |
Downtime is required to perform the upgrade |
Yes |
No |
Yes |
