This article is part of a series authored by Zeth Baker previously from Republic Airways documenting their experience and decision to migrate from Automation Anywhere v11 to Automation 360 On-Premise. 

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.

Some practical advice that I can give anyone considering the migration:

• Communicate & evaluate with your Customer Success Manager - they are there to help in your evaluation and migration process. If you have concerns, they might be able to answer your questions or they will get you the answer you need. They also have likely worked with other customers who have gone through this migration process before – so leverage some of their experiences as you plan for your upgrade.
• Get Hands-On: Get your hands dirty with the Community Edition/request a trial license and understand what’s included changed in Automation 360 is before you migrate. The best way to learn if something is going to work for you is by trying it out – re-create some simplified versions of some of your bots just to get a grasp on how things work in the web-based development environment and how the new packages/variable types can be used.
• Upskill: Take some courses in Automation Anywhere University related to Automation 360 - both as a high-level understanding but also a technical understanding. There are specific courses available for those with v11 background, as well as course materials for those with no background in RPA at all.
• Measure Twice, Cut Once: Think through a logical plan on what a migration might look like for your environment. What new automation opportunities are unlocked due to new Automation 360 capabilities? How does the web-based development environment change your needs for dedicated dev machines? How might management of the RPA environment change with bot runners that you can push bot agent updates to?

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.