BACK

Migrating v10/v11 Bots to Automation 360

CATEGORY:

Migrating Bots From v10/v11 to Automation 360

Upgrading your Automation Anywhere environment from Automation Anywhere Enterprise version 10.x or version 11.x to Automation 360 offers a host of empowering new features that enable bot-builders to automate repetitive business processes more quickly and easily. That said, the migration process is the intimidating blocker holding many organizations back from truly accelerating their automation program.

Where This Fits

The general migration flow from Automation Anywhere Enterprise v10/v11 to Automation 360 follows a 3 phase process.

Phase 1 involves checking your migration readiness (compatibility for migration), running the Bot Scanner Utility, and evaluating its results.

Phase 2 is all about migrating your bots/data to this new Automation 360 Control Room. If moving to Automation 360 Cloud, the Cloud Migration Utility can provide a HUGE lift here in easily migrating your files/data over.

Phase 3 (and the topic of this blog post) focuses on the process of migrating and validating your bots. While phase 2 is focused on moving files (atmx/mbot) and data over to your new Control Room, it’s not until phase 3 that you start to migrate your automations (atmx/mbot files) to Automation 360 compatible bots.

A final note before we deep dive into bot migrations:

Automation Anywhere has put together a SUPER helpful Upgrade Launchpad to help guide users through the process of performing a migration. The launchpad takes users through each of the 3 phases, with specific sub-topics representing the actual steps you need to take to perform a migration (with resources for each). It’s a great way to get guidance on your migration and see helpful resources/videos/references along the way.

Graphical user interface, website Description automatically generated

 

Bot Migration Approaches

Technically there are 2 Approaches to performing Bot Migrations. The video tutorial above walks through them both in detail, but we’ll outline them here as well:

Bot Migration Wizard Approach

If you’ve followed the Automation Anywhere documented approach to performing your migration, then you’ve seen that it references the Bot Migration Wizard. The Bot Migration Wizard approach leverages a bot runner to perform one-off or bulk migrations of Automation Anywhere v10/v11 atmx files to Automation 360 compatible bots. This approach is used for Migrating (converting) atmx/mbot files that have already been copied to the Automation 360 environment and can be found in the Administration > Migration menu system of the Control Room.

While you technically can perform the migration (conversion) of a large number of bots at once using this approach…however, that may not be the best approach. A better approach would be to migrate (convert) bots process by process – testing, updating, and validating as you go along, as opposed to a bulk migration (conversion) of every atmx file in the Control Room.

Example: If one of your atmx-based processes is the HR Onboarding process – and it’s made up of 5 atmx bots and 3 mbots, you’d want to convert all of those using the wizard so you could start to test and validate this process. This approach is superior to migration HR Onboarding + HR Access Management + Invoice Processing + etc… unless you were immediately going to start reviewing and validating all of those processes at once.

To re-emphasize an important point here, this approach DOES require that all of your atmx/mbot files have already been copied to your Automation 360 Control Room. If your atmx/mbot files have not yet been copied to your Automation 360 Control Room, you may prefer to go with the Migration Package approach below.

Bot Migration Package Approach

While the documented approach for migration is what’s recommended by Automation Anywhere – there may be situations where you need to migrate one-off bots… or you’re a free-bird who just insists on doing things your own way. If that describes you, then the Bot Migration Package approach may be what you’re looking for. For those who are migrating from Automation Anywhere Enterprise v10 (where the cloud migration utility isn’t available), or you migrated to an on-prem Automation 360 setup (which could’ve been from Enterprise v10 or v11) but didn’t already copy all of your atmx/mbot files to your new Control Room – then you may be looking for an additional option for migrating bots. If that describes you, then you may find the Bot Migration Package approach is more useful than the Wizard approach.

In the Bot Migration Package approach, you’ll need to build an Automation 360 bot that leverages the Bot Migration: Migrate Legacy Bot action. This action could be – for example – run inside of a loop that is looping through all the files in a specific local/network file directory – set up to migrate each atmx/mbot file it finds within that directory. More specifically, this action should be used with a conditional statement to ensure that the file for this iteration of the loop is actually an atmx/mbot file – and not some other file type found within your directory.

Make note of 2 things when taking this approach:

  1. Your bots will be migrated to whatever folder you ran your “migration bot” from…irrespective of the bot repository path from your v10/v11 environment
    1. Special note here – be sure to run this against ALL Dependencies for an automation, not just the parent bot without mbots.
      1. You’d likely just want to copy the dependent mbot folders into the same folder as the atmx files…Automation 360 doesn’t care about directory structure the same way that Enterprise v10/v11 did.
    2. Second Special Note: Because the repository structure itself isn’t automatically being created using this Migrate Legacy Bot action, you’ll need to manually re-create the repository structure, manually update bot references (parent to child, bot to mbot, etc), and possibly move things around a bit to match your target automation repository structure.
    3. Bonus Pro Tip: If you didn’t love the repository structure/organization of your Enterprise v10/v11 environment – use this as an opportunity to improve things! Speaking from experience, when enterprises get started with Automation Anywhere, they don’t think of the consequences of putting everything in the root of “My Tasks” (v10/v11 language) or “Bots” (Automation 360 language)…so use this migration as an opportunity to improve your repository structure/best practices to a more organized and sustainable structure.
  2. The atmx/mbot files in this approach aren’t actually copied into your Automation 360 Control Room…only the Automation 360 compatible bots will appear in your Control Room.

Reviewing Results & Testing

Regardless of the migration approach taken, once your atmx/mbot files have been migrated to Automation 360 bots, you’ll want to jump into reviewing the migration results, and starting to test.

Pro-Tip: Start with some of your simplest automations as you begin migrating/testing migration results. This will enable you to figure things out on a simpler process – working up to some of your more complex automations – ideally with some bot-migration-experience under your belt.

Now one thing that you’ll want to first review (if this is one of the first bots that you’ve migrated) is how your Global Values are set. If you remember back to Automation Anywhere Enterprise v10/v11, most bot builders frequently leveraged system variables – AAApplicationPath, AABasePath, etc – to support migrations, these values are now represented as Global Values (as in values available to all automations). Check/set these values (you may need to use an admin account or adjust developer permissions to see these) for your bots to use going forward – noting that the concept of a dependency on the Automation Anywhere Application/Base path within the logged-in user’s document directory isn’t a thing anymore…so if you want to start logging debug/error details to a new, more standardized location – this is your opportunity to do so. (Micah recommends creating a “Bots” directory in C:\ProgramData\AutomationAnywhere – since that path will automatically exist on any machine where Automation 360’s Bot Agent has been installed).

Graphical user interface, application, Word Description automatically generated

Figure Use Debug Mode with breakpoints to step through and evaluate your migrated automations.

As you start to review the logic for your migrated automations – you’ll likely see some variables that aren’t totally familiar to you. This is in-part due to the fact that Automation 360 uses strongly typed variables (which is great) – while Automation Anywhere Enterprise v10/v11 used loosely typed variables (which was frustrating at times…i.e. dates 7/23/2012 turned into mathematical statements). If you get confused as to how those variables are being filled, what they are being used for, etc – consider adding a message box in certain parts of your bot or run the automation in debug mode so you can see how each variable is being filled. For readability/maintainability’s sake, you may also choose to add comments or even change variables around a bit so that future maintenance can be done more easily.

Beyond reviewing variables – you’ll want to pay close attention to any subtasks that are being called by your bot – Are the paths valid? Is the path following the v10/v11 directory structure path, or has it been mapped correctly to the corresponding Automation 360 subtask? Are the metabots that were converted to Automation 360 bots being called appropriately? Checking for these dependencies/references can help ensure that your bot is correctly invoking other migrated (converted) objects.

Side Note on MetaBots: Regardless of if your MetaBot was DLL based or Screen/Command based – upon conversion to Automation 360, you’ll notice that you have one bot per function that was originally defined in your MetaBot. This approach is actually quite nice – as each migrated (converted) bot now operates as an independent subtask – which can be invoked from any other bot. Just like when calling a function in other programming languages, you map required inputs to the selected subtask, and an optional return value(s) is provided.

When it comes to testing your automations – it really comes down to the applications used, making note of what may not be working, and adjusting as needed. In my personal experience preparing for this video, most of my automations worked with only minor tweaks related to references to local file repositories. You’ll hopefully find similar results, though you may have to make additional adjustments based on the applications you’re automating with (SAP, legacy thick client apps, etc). Additionally, continue to test as you go – it will be the easiest/cleanest approach to do continuous testing – as opposed to doing a bulk migration and not knowing exactly which files have been revAiewed/tested and which are still outstanding.

Enhancing Migrated Bots

Once your atmx/mbot files have been migrated (converted) to Automation 360 compatible automations that have been tested/validated – you’ll come to a decision point:

  1. Schedule the migrated/validated automations and let them go
  2. Make enhancements to the automations to take advantage of the additional functionality offered by Automation 360 packages

Your decision here will obviously depend on a number of factors – your timeline for getting all automations migrated, the expected life-span of the automation in question (is it due to be retired anyway?), your penchant for readability in all of your automations, etc. The fact of the matter is, there are several opportunities to leverage new Automation 360 packages to improve the readability and simplicity of your automations.

Examples:

Working with a REST API or JSON config files? Automation 360 includes a JSON Package for parsing values from JSON – to include lists of JSON objects, working with arrays of JSON objects, etc. Extracting data from JSON Objects is significantly easier than the alternatives in v10/v11 – which likely included custom JavaScript/VBScript or advanced string manipulations.

Remember how confusing it was to loop through an Excel file in Automation Anywhere Enterprise v10/v11? You had to use the loop, but then it was using a system variable + column and row # with the counter value? Not the easiest thing to quickly look at and understand – especially for someone new to Automation Anywhere. Thankfully, not only is Excel looping way easier in Automation 360, but new variable types like the record variable make extracting data from spreadsheets a breeze. Going even one step further – there are actually TWO Excel packages in Automation 360! Excel Basic (no requirement for Excel install on Bot Runner) and Excel Advanced (Excel required on Bot Runner). These packages also offer a ton of additional functionality that wasn’t available in Automation Anywhere Enterprise v10/v11 – and may help to reduce your logic down significantly since alternatives to some of their actions may have resulted in multiple commands in v10/v11 automations.

These are just a few examples – but as you become more familiar with Automation 360 and the packages available, don’t be afraid to jump back into a migrated bot and clean it up a bit to pare down its complexity and improve its readability.

Conclusion

Automation 360 offers a TON of great functionality over its Enterprise v10/v11 predecessors. While a Control Room full of automations may seem like a daunting hurdle to getting to Automation 360 – take it process by process, bit by bit – knowing that each migrated/validated automation gets you closer to full-time Automation 360 development.

A final note on this – doing the migration of a full Control Room worth of automations is not a weekend project. Take your time, doing all net-new development directly in Automation 360 while migrating all legacy bots to the Automation 360 platform. Good luck, and Go Be Great!

Related Articles
A2019
Guest Post
Migration
v11
Automation 360 Migration: Analysis and Planning
Sometimes the best way to learn about migrations is by hearing about how its been done first hand by individuals who are leading them. In this post, CoE Lead Zeth Baker takes us through the process of analysis and migration planning. Read More
A2019
A360
Guest Post
Migration
v11
Automation 360 Migration: Migrate, Rebuild, or Both?
CoE Lead and Developer Zeth Baker is back with another blog post on Republic Airway's Automation 360 approach. This time, Zeth breaks down migration bots vs rebuilding bots and the concept of taking a hybrid approach between the two. Read More