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

Special Note: In the time between publishing the first article in this series and publishing this article, Automation Anywhere Enterprise A2019 has been re-branded to be Automation 360. As such, this article will refer to Automation 360 exclusively, but the language refers to the platform that was previously known as Enterprise A2019.

With the introduction of the Automation 360 bot scanner and migration package, we have seen several major improvements with each new version.

This was a very encouraging data point in our decision to move forward with our upgrade because it re-enforced the desire of Automation Anywhere to keep improving the migration utility and to make the migration experience as automated as possible in support a smooth transition from previous platform versions. Even as I am writing this today, I have been asked to provide additional feedback and ideas for the migration utility to continue to improve it for other customers…they genuinely care about making this as smooth as possible for everyone. In this article, I’ll talk about the decision we made between performing a migration using the package provided in Automation 360 or rebuilding the bots/processes net new on the new platform.

The migration package works well for migrating processes over from Automation Anywhere v10/v11 to Automation 360… you can even build a bot to migrate them all using a few actions within a loop.

Wait did I just say build a bot to migrate bots what a cool concept!

If a customer is looking to get on the newest platform swiftly and effortlessly, this is going to be your ideal solution. Once all your bots are initially migrated, you will still want to, of course, do some regression testing - and you might have to fix a few components here and there - but overall the bot should work similarly to how it worked in v10/v11.

Automation Anywhere has done a good job of creating documentation and resources to help with the migration and supporting an organization’s decision to migrate - all of which can be found on the Documentation Portal (these are great resources if you don’t currently use them).

As part of our original analysis of migrating to Automation 360, I ran the migration package on all our bots and processes to see what it would look like on the new platform. It worked smoothly, and we could’ve gone solely with that approach and our migration would’ve been done quickly with a few tweaks in each bot.

Now you are thinking What’s the catch? What am I missing? Why then does this article keep going?

Well here comes the twist, I decided not to use the migration utility fully and instead decided to re-build some (not all) of our bots mostly from scratch in Automation 360. As I said before the migration utility is great for converting v10/v11 bots to Automation 360 as-is, and it would totally get your RPA program back up and running on the newest platform. However, using the migration utility alone doesn’t mean you get all the full benefits of the new platform. There are some scenarios where I have used the migration utility to capture certain elements such as object cloning > recorder actions or just to visually see what it would look like once converted. More than anything I chose to use the migration utility as a reference tool to review the accuracy/conversion of the new bot builds.

Why Consider Rebuilding Some?

So why go through the process of rebuilding some of them? What’s so great about Automation 360?

The first thing I wanted to be able to take advantage of was the multitude of new variable types which help improve the reliability of the bots, so you don’t have to add some qualifier like you might have needed in the previous version. The migration tool does convert existing variables to the new types but then you get stuck with the conundrum of variable naming conventions. I wanted our naming convention to be unilaterally standard between previously existing bots and net-new bots – and as a CoE Lead - I believe it is important to establish sound development standards and for them to be religiously followed.

In this instance, we elected to follow the Hungarian notation naming convention which makes identifying variable types by name straightforward, as well as providing us with the flexibility of semantically naming input and output variables. The other major factor in our decision to re-build was that there are now packages and features that previously didn’t exist - which help to remove some dependencies on custom v11 solutions we’d previously created.

If there is a function native to the platform, I would prefer to use that over something custom we’d built. In the long run, that becomes one less thing we are responsible for maintaining as customers and one more feature we can use of the new platform - which ultimately helps our overall scaling and speed to delivery efforts.

As a side to this point, I’d also mention we were very interested in getting our hands on some of the freely available Bot Store packages. While not directly a part of the core product, we found that there were many useful packages on Bot Store that made our lives way easier – like the JSON Object Manager, Credential Manager, and GUID Utilities to name a few.

This leads me to my next point - modular development!

We’ve been laser-focused on a modular development approach since we started our RPA journey - leveraging reusable subtasks and/or metabots to increase our development speed and decrease our maintenance tasks. In Automation 360, subtasks can contain input and output variables instead of bi-directional variables like v10/v11. This is another great feature to take advantage of during building. It makes it clear for other developers what data elements are needed and enables us to standardize this formatting/naming in a logical way.

In my opinion, the time to transition a task to a subtask in Automation 360 versus the previous version has significantly improved, but you’ll have to wait for a future article for me to breakdown the surprising performance improvements we have experienced!

A final consideration in determining your migration approach (using the migration utility or going the rebuild route) is to determine the priority or order to migrate your bots. Fortunately, Automation Anywhere has been very accommodating in this area by providing some flexibility on the bot runner licensing side to make it as painless as possible. The approach that made the most sense for us was to focus on a single bot runner at a time. Most of our processes run unattended on a dedicated device so without spinning up new servers the next best option to was choose all the bots that are scheduled on the device and migrate them all that the same time. At that time, we would uninstall v11 from the device, install the bot agent and connect it to the control room.

Overall this has been a successful approach and our business partners have been none-the-wiser that any migrations have even taken place.

Conclusion

We are still undergoing our migration efforts and we are hoping to have it finalized by the end of March.

Admittedly, I was originally hesitant about Automation 360… early releases seemed slow from a performance perspective and some of the advanced automations we were creating didn’t seem possible in the new platform. As of late, however, with the more recently released updates, I have since fallen in the love with the platform and I can now build bots faster and more efficiently than I could in previous versions. It is truly a great platform and it continues to improve with each release.

If you haven’t had a chance to get familiar with it yet, I would encourage you to do so sooner than later. Maybe just try to build a bot for your personal life like paying bills, picking your March Madness bracket, or maybe even some online shopping in Community Edition and see how you like it! It still amazes me that all of this can be done 100% in a browser.

A Few Key Takeaways From This Article:

• Don’t be afraid: Don’t be afraid to get your hands dirty and try using the migration tool. Don’t be afraid to suggest re-building your bots. Don’t be afraid to try a hybrid approach. Don’t be afraid of the new platform. There are many ways you can approach this migration – even leaving some bots as is after migration and focusing on re-building others. You just will need to make the best decision you can knowing your environment, your organization, and the new capabilities at your disposal.
• Forward Thinking: Think about what the migration might look like when it is complete. How will you move forward with new bots? What standards are in place that can stay the same or change? (This is your chance to get it right if you didn’t love some of your v10/v11 practices) Consistency is an important pillar to a successful RPA program, so make sure your development processes and standards will pave the way for where you want to go with your RPA program.
• Try, Review, Repeat: Evaluate the different approaches at your disposal for a migration to occur and give it a try. Review what worked well and what needs improvement. Start over and try again and repeat until you have identified the best plan for your migration efforts. Also always be sure to review what new features are added to the migration tool and the overall platform with each release! All of the recent releases have introduced meaningful platform updates that have made each update completely worth it.