I’ve been exploring the OpenCore stack as a cost-effective alternative to UiPath and want to recommend a migration to my client.
I’ve deployed UiPath bots for this customer over the years, and if we move forward, they’ll definitely expect me to migrate all existing bots to the new stack.
A full rewrite would make this a tough sell, especially that I know there will be snags I don’t even anticipate right now.
Is there a way to reduce the rewrite effort? Can OpenRPA leverage UiPath activities to ease the migration? Any tips or tricks to lighten the migration workload would help!
hey
On one hand, that would be really easy since you can copy and paste from the UiPath designer into OpenRPA and back. However, all activities used in UiPath depend on UiPath DLLs and custom language handling. So, for this to really work, we would need to have one activity in OpenRPA that maps to a similar one in UiPath.
Next, UiPath selectors are very different from OpenRPA selectors (they use XML, we use JSON; they have a much more flexible way of creating selectors, like having anchor points, while we have three different ways of constructing selectors). It would be a nightmare and almost impossible to automate.
Lastly, we often have “two steps” for things in only one activity in UiPath (they have “set text,” we use “get element,” and then “assign” to set the text using item.value, etc).
Thanks for the insights, Allan! I’ll give it a shot by porting their smallest bot and see how it goes. I’ll keep track of how much time it takes, and if I can show them they can drop the uipath cost and just pay a small fraction for some rewrite work, they might actually go for it. Hopefully, this all works out
BTW, I remember seeing a discussion about a year ago where you had concerns about Node-Red drifting away from its open-source nature. Do you still think that’s an issue? Should we push for any API workflows to be built in Python or .NET instead? Honestly, I don’t mind writing the code—it’s just that Node-Red makes for some pretty cool demos
