BACK

Tutorial: Migration to Automation 360 On-Prem

CATEGORY:

Tutorial: Migration to Automation 360 On-Prem

Automation 360 delivers a browser-based, intuitive experience for business users and developers to quickly automate tasks and build automations. Automation 360 provides both On-Premises and Cloud deployment options and is the first platform that provides RPA-as-a-Service as an automation solution. It enables users to automate applications across different infrastructures and industries such as banking, telecommunications, and business process outsourcing (BPO) organizations. There are several migration options for users coming from Automation Anywhere v10/v11 looking to move to Automation 360. One of those available options is to migrate from an on-prem v10/v11 Automation Anywhere Enterprise environment to an Automation 360 on-prem implementation.

The tutorial above is designed to be a resource to help guide you along your journey of performing a successful migration to Automation 360 on-prem. If you’re interested in migrating to Automation 360 cloud, a similar tutorial will be available shortly demonstrating that migration process as well.

For the purposes of simplicity, the on-prem migration process is broken down systematically below with references to documentation for additional details to help with each step. Additionally, note that this tutorial covers performing only a migration of the Control Room from Enterprise v10/v11 to Automation 360. There is a secondary video focused on using the Bot Migration Wizard from within the Automation 360 Control Room to migrate your bots from atmx files to Automation 360 compatible bots (as this bot-migration process is the same regardless of using Automation 360 on-prem or cloud).

So let’s jump into the steps for performing a migration from Automation Anywhere Enterprise v10/v11 to Automation 360 On-Prem

Verify Migration Compatibility

In this step of the process, we need to do a sanity check to ensure that the version of Enterprise v10/v11 that you intend to migrate FROM is certified for migration to Automation 360. The referenced documentation is updated with each Automation 360 release, so be sure to check back regularly if you’re waiting for support for a particular Control Room version. Alternatively, consider using the Automation Anywhere Product Downloads page to upgrade your v10/v11 Control Room to a version compatible with Automation 360 Migrations.

Installing and Running the Bot Scanner Utility

The Bot Scanner Utility is a lightweight application that is used to scan your bot repository in preparation for migration to Automation 360. As a result of the repository scan, the Bot Scanner Utility will generate an HTML file that contains an analysis of the scanned Automation Anywhere Enterprise v10/v11 bots – providing insights into which bots are eligible for migration, which have special notes around the migration process, and which bots may need modifications either before/after the migration to Automation 360. The recommended rule of thumb is that if your “bots ready for migration” percentage is > 90%, you may safely proceed with your migration – acknowledging that certain identified bots may need some work before/after migration.

If your % of “ready to migrate” bots is below 90%, take a look at the “Bots that can’t be migrated now” tab to understand the specific reason that certain bots are ineligible to be auto-migrated. It could be something as simple as a dependency on an un-used Bot Store metabot, or something that could be easily adjusted to make the bots eligible for an auto-migration.

Database Backup and Restore

Pay close attention to this phase of the Control Room Migration. Remember: your goal is to perform a migration, not a net new install that requires re-setting everything up. Back up your Automation Anywhere Enterprise v10/v11 Control Room Database and restore it to your destination SQL Server environment for Automation 360. If you skip this step, the Automation 360 installer will create a NEW database in your SQL Server env, not install Automation 360 on top of your existing database. Fortunately, this backup and restore process is relatively simple and is demonstrated in the video above as well as the referenced documentation.

Special Note: the video above shows restoring the Control Room Database on the same server that Automation 360 is installed on. In most production implementations, you’d want to consider using SQL Server clustering and setting up the SQL DB on a server that is different from the server you intend to install Automation 360 on. For more details on Database requirements/options – see this link in the docs portal.

Bot Insight Migration (Not in Video Tutorial)

In addition to migrating your Automation Anywhere Enterprise Control Room Database, you’ll likely want to also backup and restore your Bot Insight dashboards and data to your Automation 360 Control Room. The instructions provided in the link above are relatively simple to follow, and step 3 & 4 of the process can take place in conjunction with the migration of the code repository described in the following section. Also note that if you are not using Bot Insight or don’t want to migrate over your Bot Insight dashboards/data, this step can be skipped.

Migrating The Code Repository

Migrating the Automation Anywhere Enterprise v10/v11 code repository is the final step before running the Automation 360 Control Room installer. In this step, we go through the process of creating the target folde repository structure in the to-be Automation 360 Control Room Server(s) and step through backing up/migrating all of the Control Room repository’s files.

Special Note: Similar to the note on the Database backup section, the video tutorial above goes through the process of migrating files to a single Windows Server repository. In environments where failover/redundancy is required, this repository may need to be established on a SAN/NAS drive to be shared across multiple nodes of a Windows Server Cluster. Alternatively in small/medium implementations, you could consider using virtualization technology to provide redundancy across multiple physical servers while setting up this new bot repository against the drive of a single virtual server. While multiple virtualization vendors may offer this similar technology, this explanation from VMware on their Vmotion capability explains the concept.

Running the Automation 360 Control Room Installer

With the Database, and code repository successfully migrated to the intended Automation 360 environment – the only remaining step is to run the Automation 360 installer. As previously mentioned with regards to the Database backup procedure, it’s critically important to pay close attention to the installation procedure steps shown in the video above & referenced in the provided link. If not followed closely, you may accidentally end up creating a new Automation 360 database or not appropriately importing your migrated Automation Anywhere Enterprise v10/v11 codebase.

Once the installation completes successfully, you should expect that each of the microservices powering the Automation 360 Control Room start up smoothly and that you’re able to log in to your freshly installed Control Room. Because you’ve migrated from an existing Automation Anywhere v10/v11 environment, you can expect that the same username/password combinations from your prior environment will work in the Automation 360 installation as well.

Conclusion

Automation 360 is a fully browser-based RPA platform from Automation Anywhere… with features that extend well beyond the capabilities of Automation Anywhere Enterprise v10 or v11. Migration can admittedly be a stressful time no matter the product, platform, or architecture – but with a plan in place and the documentation needed, it’s a much smoother and more enjoyable process. Plus – think of all the cool new Automation 360 packages you’ll be able to use once you migrate!

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