BLUE PRISM UPDATE FROM VERSION 6.5 TO 6.10.5

[DANILOSILVA]

Hello guys,

We are in the process of updating Blue Prism from version 6.5 to 6.10.5.
But when I updated the Database a new version was created.
Both in the documentation and in the tests I was not able to use the DB from version 6.10.5 to 6.5 to proceed with the migration, as we will be doing it in phases from October/2022 to December/2022.

I would like to know if I can use only one DB to perform this migration or will I really have to keep both DBs active until completion?

Awaiting.
Thanks.

[PvD_SE]

Hi D,

You do not write what environments you have, so I assume you have Development and Production. If you only have one environment, a mix of Development and Production, then you can forget about anything I write here.

As far as I am aware, initially you should have two environments, one 6.5 and the new 6.10.5. As the 6.10.5 is new, it will not contain any of your own processes and objects., only the standard BP setup Your own processes and objects have to be imported from 6.5 into 6.10.5. Once all your processes and objects have been migrated, tested and deployed in Production,  you do not need the old 6.5 anymore. 

You cannot deploy processes or objects from new 6.10.5 in Development to old 6.5 in Production. So my advice would be to keep working in 6.5 until you are ready to have 6.10.5 in Production.

Meanwhile, you import your processes and object into the Development 6.10.5 environment in order to be able to verify that they still work in the new version. As soon as all are verified to work in 6.10.5, you can upgrade your Production environment from 6.5 to 6.10.5. Then you import all processes and objects from Development 6.10.5 and you should be in business with the new version.

Note that during the time you still run 6.5 in Production, but are already verifying your processes in 6.10.5 in Development, you will have double maintenance. Any changes to your processes in 6.5 that are deployed in Production 6.5 need to be synced out to the processes and objects you already have in 6.10.5.

Happy coding!
---------------
Paul
Sweden

[swolonda · Accepted solution]

Hello, 

what Paul suggested is technically correct, but would say it might be an "overkill" . 

If your scope is not too big (let's say you plan to do the transition in two or three weeks) than there is probably no need for you to keep two parallel DEV environments.
Yes, it's true you won't be able to deploy, but you don't risk the forks (plus there is always a possibility to do an emergency change straight in PROD). 

Another thing I would mention is, that there is no need to create an empty 6.10.5 environment, you can just do a backup of the old DEV environment and then go straight for the upgrade. Or (if you want to run two DEV environments) make a clone and upgrade a clone. That way there is no need to transfer the objects, processes, credentials, calendars or to recreate the changes you have made to your db (i.e. local holiday added).

We are going through 6.10.1 -> 7.1.1 right now, have it planned for two weeks (we have 4 licenses and almost no usage of the problematic invokes).

[PvD_SE]

Hi,
Yes, Stanislava is correct too. In general, there are two basic types of environments:

• The smaller and more informal where the developer has edit access to processes running in production 
• The larger and very formal with restricted developer access to anything close to production

While my posting described what I work with: the second variety, Stanislava's post pointed toward the first environment. I certainly would not describe my posting as overkill, nor would the yearly financial and IT auditors describe it as such. Choose which best app!ies to your workplace.

Happy coding!
---------------
Paul
Sweden

[DANILOSILVA]

Hi Paul and Stanislava,

Thank you so much for the clarification and tips.

@Paul, in my case it would be the first environment

Att.