This article is the first in a series authored by Zeth Baker from Republic Airways documenting their experience and decision to migrate from Automation Anywhere v11 to Automation 360 On-Premise. Should your organization be on the fence about upgrading from v10/v11, hearing from customers (in their own words) can be a great way to see yourself in their story.
With the introduction of Automation 360, the web-based building/testing capabilities, and the ability to create and use custom packages – we began thinking about when the best time would be for us to migrate from Automation Anywhere v11 to Automation 360. We’ve been happy with the stability of v11, and while we didn’t want to be the first to migrate, we wanted to be a fast follower in being able to take advantage of all the newly introduced functionality that Automation 360 has to offer. To be very honest, it can be a difficult decision to take the plunge on a platform migration – especially when you’re the individual who will primarily be responsible for upgrading the bots and handling the migration.
When the Bot Scanner Utility was released, we started utilizing it immediately – finding it provided enough insight into what patch release version made the most sense from a timing perspective. Each new update of the Bot Scanner Utility informed us on which bots/commands were eligible for automatic migration so we could know when the timing was right. We ran the bot scanner every release and shared the results with our Automation Anywhere CSM (Customer Success Manager) and release over release we saw improvements and additions of additional bots that could be auto-migrated, and more and more commands that had direct Automation 360 counterparts.
Starting with the .16 release, we decided to take it a step further and begin doing some beta testing of our own with the migration utility, packages, and bot agent features that were available. As we performed our testing and evaluation, we felt comfortable enough to begin planning for migration. You might be asking “But what was the determining factor for you to make the move?” and I honestly can’t say that there was a single factor that made the decision for us. Overall it appeared that the commands we primarily use were present, they functioned correctly – and our initial tests proved that our sample bots could execute as expected if not better and faster…not to mention our excitement to make use of features like auto-updating bot runners, global variables, and using some of the new packages.
Beyond what we saw in our own testing, it has been comforting to see that releases for Automation 360 happen more frequently – so if an issue was identified, then ideally it might be resolved relatively quickly. Another key consideration for the upgrade planning was knowing that packages are version control-based, so we’d have the option of an extra level of flexibility to roll a specific package reference forward or back if an issue did arise.
That’s all for the planning and decision-making considerations to move to Automation 360. In the next article, I will discuss our evaluation related to the bot migration package in Automation 360 and our high-level plan on how bots are being migrated.
A-Lister, RPA Developer, CoE Lead @ Republic Airways
Zeth is a self-taught RPA Developer working in the RPA space for 2 1/2 years using Automation Anywhere. In his free time, he enjoys hanging out with his 3 rescue dogs, cooking, and playing cornhole (bag toss).