Migration isn’t glamorous. Stakeholders and leadership teams don’t see us driving more value to the business—whether it’s in the form of headcount, cost, or time savings—when our only focus is moving old code to a new system. However, this doesn’t mean we should rush through the development cycle in order to push through migration and getting back to creating new automations. For each process we migrate, we should be going through the full development lifecycle, with a heavy emphasis on testing, to ensure a successful overall migration.

At BSC, we’ve been leveraging Automation Anywhere since 2018 and have hundreds of automations within our ecosystem that needed to be migrated from V11 to A360. We started migration in mid-2022 with a goal to complete migration by mid-2023. Even though it was a big task, we focused on taking the time needed to migrate each automation thoughtfully and successfully. Here are steps we took and how I recommend proceeding should you have the large task of migration ahead of you:
 

1. Plan – Work with SMEs to understand if each automation is still necessary. Ask them to reflect, “is this automation still providing the value it once was to the business, or can we retire it?” Also, continue to build a backlog of automations, ensuring that the processes and requirements are groomed and ready to go when migration is complete.
2. Analysis – For each automated process, you should next reflect whether the automation is still providing the best employee experience or whether the bot process should change to ensure a seamless employee experience.
3. Design/Implementation - Now is the opportunity to look at individual automations and evaluate if there is a faster or more efficient way to code each one. While you have the system open, does the value of moving an old UI automation to leverage API make the process more efficient and manageable in A360? In the case of BSC, we had some automations that were built when we were just starting our RPA journey 5 years prior. So, for us, stepping back to look at the code and evaluate if there was a better, faster, or more efficient way to code these older automations was the smartest way to move forward. Also take the time in this phase to ensure that all documentation, such as an old Process or Solution Design Document, is updated. You have probably made small adjustments or edits to automations for maintenance purposes over time that may not have been captured in the documentation. While you have the automations open, take care in confirming that all documentation is up to date.
4. Testing – Technology helps make migration from V11 to A360 faster and easier on developers as they don’t have to go through recoding the entire automation. That being said, as code migrates, it’s important to ensure that a stringent UAT plan is in place for each automation that includes both the developers and the SMEs. If SMEs aren’t looped in, a developer may miss something that looks correct to them, but could be a fail and cause potential risk.
5. Deploy/Maintenance – Enjoy your success and celebrate each successful migration! And with the updated automation design, there will hopefully be less maintenance needed going forward.

With this carefully thought out migration process put into action at BSC, Dylan Mahan and our HR CoE are on track to complete our full migration of 60 bots in V11 production by June. Furthermore, throughout the migration our team has been able to learn the new A360 platform and understand best practices for developing in the new environment. So when it‘s time to flip the switch to A360, they will be able to tackle our backlog of automations right away.

Adam Favreau (Most Valuable Pathfinder) is a Senior Manager, HR Technology at Boston Scientific.