Skip to main content

Do you need to migrate or copy an A360 Control Room to a new Control room in the Automation Anywhere cloud? If YES, then these resources are for you. 

For on-prem to on-prem migrations there is an established process whereby the DB and repository can be moved from one place to another. (See APeople KB and documentation site). However for moving to a cloud hosted A360 control room this is not possible, as you dont have access to the database. This page provides a set of resources to help you with the process.

Automations and a guide to using them for your migration are attached to this post.

 

NOTE THAT THIS IS A COMMUNITY PROJECT AND IS NOT OFFICIALLY SUPPORTED BY AUTOMATION ANYWHERE. THE AUTOMATION LOGIC IS PROVIDED ‘AS IS’ TO ASSIST YOU.

 

A360 Migration Project Steps

Broadly, the process of migrating data would encompass the below steps once your cloud CR is deployed. Notes have been made against each data type about the suggested approach and any available logic to automate the process.

Note that not all of these items need to be considered - this will depend on what functionality you have implemented. (For example, if WLM is not being used then Queues and Run with Queue settings can be ignored).

Steps to Move Supporting Data for Automations:

  • Control room configurations. This is pretty much everything in Administration > Settings. It is suggested that manually setting these up would be the best approach. There is no API to copy or set these values anyway, so manually reviewing and setting them according to your needs is the best approach.

  • 1. Public Folders. A bot is available which will automate creating public folders. This bot will also create a mapping file to map folder IDs from the source CR to new IDs in the destination CR. That mapping file is used by subsequent automations for migrating other data.

  • 2. Custom Security Roles. A bot is available which will automate creating custom roles and permissions (including folder permissions) using the control room APIs. This bot also creates a mapping file to map role IDs from the source CR to new IDs in the destination CR (used by subsequent migration logic).

  • 3. User Records. A bot is available which will automate copying users, and will link them to the relevant roles created in the step above, as well as to all system roles that the user was assigned to. A role mapping table is used to map role IDs from the source CR to the new role IDs in destination CR when creating users. A user mapping table is also created when migrating users. (Note that disabled users will also be created in the new control room. Delete them after migration if preferred).

  • 4 Credential Lockers & 5. Credentials. Two bots are available which automate copying across Lockers, Credentials, and Credential Attributes using the control room APIs. (Actual values for the credential attributes are not copied, so these must be entered manually).

    • Run the bot to create Lockers first. This will create a mapping file from the old Locker ID to the new

    • Then run the bot to create Credentials. This will create credentials, attributes, and will link the credentials to the lockers.

  • oAuth Data. No known APIs at this stage, so will need to be copied manually.

  • Global Values. No known APIs at this stage, so will need to be copied manually.

  • Custom Packages. No known APIs at this stage, so any custom packages need to be copied manually. (Packages can actually be copied along with automations as they are migrated).

  • Queues. There is potential to copy these across with a bot using APIs. However logic has not yet been created for this. Most organisations have very few queues, so at this stage it is assumed these can be easily setup manually.

  • Devices. It is recommended that connected devices be setup manually as various bot workloads are progressively moved to the new control room (see notes below under Other Considerations).

  • Device Pools. Given that devices will be setup manually, it is recommended that device pools be also setup manually as workloads are progressively moved to the new control room.

  • AARI / Co-Pilot Process schedulers. No known APIs at this stage, so will need to be copied manually.

Move the automations, LIs and other files

  • Learning Instances. There would not normally be many of these, so it is suggested that the standard export & import process would be acceptable.

  • Automations, forms, processes, templates and other supporting files. It is suggested that the new Bot Promotion capabilities could be used to move these across. Simply setup the new CR as a destination for promoting bots and processes. Then promote the Automations as workload is progressively moved to the new control room (see notes below under Other Considerations).

  • AARI / Co-Pilot Process Configurations. Once the processes have been moved the process can be configured in AARI with relevant settings (Teams, Process Scheduler, Process Key, etc.)

  • Unattended Bot Schedules. As mentioned above, it makes sense to migrate automations across progressively to the new CR. Therefore these would need to be setup manually as the relevant workloads are migrated.

  • Run With Queue. Once bots running in the WLM model have been copied across, you need to kick them off manually using Run with Queue.

 

Other Considerations

  • It would make sense to move across production automations incrementally. This way devices could be moved across from the old CR to the new CR incrementally. This saves the cost of setting up a completely new set of bot runner machines, as well as the risk of missing any required desktop software or other required bot runner configurations. A longer overlap of licencing for the two CR environments would be required so that this could be facilitated. Please contact your Automation Anywhere representative or partner to obtain any necessary dual licencing.

    • Carefully consider any interruptions to production workloads as this is done.

    • Dont forget to set the default device for run as users (bot runner accounts) and the device login credentials after moving devices across.

  • It makes sense to test your migrated bots in the new cloud environment before moving the workload for that bot to the new CR. This is especially important with mission critical bots. If the customer also has a new Test CR or Sandbox CR in the cloud, then bots could be migrated there first, tested properly, and then ‘promoted’ to the production control room. This should highlight any issues in the migration process. Using a Sandbox CR for testing in this way would also help establish test scenarios for Sandbox moving forward. BUT note the following:

    • For the migration period, the Sandbox and Production CR must be the same version

    • Ability to ‘promote’ bots from Sandbox to production should be removed once completed

  • Incomplete instances of processes that exist at the time of migrating a process will need to be managed, including documents waiting in validation.

  • If you have attended users, consider how to manage migration of these users across to the new control room. Any attended user triggers will need to be setup again on the new control room.

  • The above considerations are mainly about a production CR. When migrating a development CR all bots in partial development would need to be considered. Note that it is currently only possible to use bot migration functionalities (both promotion between CRs and export) with bots in Public folders. Developers could be moved one at a time to the new environment, and they could migrate their in-development bots manually.

 

 

Hi @Lee Matthews

This is amazing have few followup questions, 

1. How to migrate bots, using promote feature?

2. Whenever we get a new project, we manually create new folders in the CR based on the project type and name. Secondly, we copy the standard BotFramework bots to the newly created project folder manually. Is there a way we can automate this? Perhaps by running a bot that will take the project type and name as input, create the new folder in the CR, and copy the BotFramework bots with the new bot name into it?

 

It will be great If you could share bot for point 2

Hi @Mike55 

Details on the functionality to migrate bots between environments is here: https://docs.automationanywhere.com/bundle/enterprise-v2019/page/move-bots-across-environments.html

You could use the REST APIs to automate what you are describing. To take a look at the APIs and test them, just enter https:///your-control-room-url]/swagger/ . You can also deconstruct my logic in the bots above to see how the JSON is built. Just comment out the section where it writes to the destination CR if you want to test and use a message box or debugger to look at the JSON.


Note that when beginning a new project, for any re-usable logic (like standardised reporting or error reporting logic) you should not be making a copy of them. Instead, reference them in a shared folder so that you can edit the logic (if needed) in one place and then all bots will pickup the changes.

Have you see the Automation Success Framework? Here is a link:

 

Reply


Terms & ConditionsCookie settings