Orchestration migration tool

orchestrator
i_considering
migration

#1

Hi UiPath,

we are hosting RPA-solutions for our customers and have a setup of two Orchestrators: ORCH#1 (PROD) and ORCH#2 (STAGE). We are using the STAGE miljeu to upgrade and test new versions of UiPath software (ORCH + clients) before we release it to the customers. We intend to do two upgrades per year - a spring update and a fall update.

Our (primarily customer’s) concers are these:
When we successfully have tested and released a new version of ORCH + clients, then we have changed physical servers and thus the database is not the same. This means that when customers login to their upgraded miljeu they find their ASSETS, LOGS, PACKETS, ORG UNITS etc. missing. Naturally they are unhappy about this and ask us to migrate these from the previous miljeu to the new miljeu.

We know this is stored in the UiPath database i various tables, and could propably create a handful of sql-scripts to extract and migrate the data. However, we are not sure whether other tables or functions are touched by the data. But we ARE certain that by doing so we would potentially introduce all kinds of errors and unforseen instabilty to the platform. We would certainly want to avoid that.

Therefore, would UiPath consider creating a (set of) tool(s) which could help us and others in this task?
It would be nice if the tool could look at ORCH#1 (old version) and migrate the contents of the relevant tables to ORCH#2 (new version): data like tenant, users, robots, assets (please!), org units and perhaps even packets and environments these are very time-consuming to enter each time we switch between the ORCH-versions (twice a year) - and prone to errors. It would be a great help if just some of these elements could be migrated.

Naturally, we realise that not all data is suited for migration, that going from an lower to a higher version can entail some difficulties and that ORCH#1 and ORCH#2 not necessarily have the same tenantID. However, by providing a COPYING tool the data would be enforced on the new miljeu with the same IDs and thus the tenants would not notice any difference.

It does not have to be the silver bullet right from the start. If just a couple of elements could be migrated - that would be a huge help. Later versions could allow for more elements.

Woudl that be something UiPath is willing to look into?

Best regards
/Klaus Ambrass


#2

Hello Klaus.

Excellent post, I am about to do that with a client we are about to config an orch and will try to migrate after testing the workflows, I will gather data and will return here to tell you about my expirience.

regards.


#3

Hi @KlausA, @beesheep,

Have you taken into consideration moving stuff from one Orchestrator to another using its API?
I think this is a much safer method than getting your hands on its database, taking into consideration the dependencies between tables.

Here’s an example that I’ve created for moving assets: https://github.com/bogdan-popescu-uipath/scalability-utilities-for-rpa/blob/master/Deploy/Get-AssetsFromOrchestrator.ps1
https://github.com/bogdan-popescu-uipath/scalability-utilities-for-rpa/blob/master/Deploy/Add-AssetsFromJsonFile.ps1

Tell me what you think about this approach.

By the way, have you heard that we have now a PowerShell library with commands dedicated for Orchestrator API? You don’t need to build every time the HTTP request, we’ve done that for you, you just have to call a PowerShell command. This can be found here: https://github.com/UiPath/orchestrator-powershell

All the best,
Bogdan Popescu


#4

Hi Bogdan,

this is awesome!
I’ve tried it and it worked beautifully. If the password could come over aswell (encoded, of course) it would be perfect.
I can definately use this script for my RPA hotel. Thanks a lot, Bogdan.
Best regards
/Klaus