You’ve had it. Your RPA platform vendor’s new licensing costs are ridiculous, or the latest upgrade is wildly over-complicated and time consuming. Maybe it was oversold and now it’s taking too long to deliver underwhelming automation. Maybe you’ve added another platform to appease another part of the enterprise or to take advantage of a powerful feature. A combination of these reasons is leading you to the conclusion that it’s time to leave your current vendor and bring in new software that can help you and your team fully realize the value of your RPA investment.
The new vendor’s demo knocked it out of the park. It covered improvements and solutions to all the issues that are driving you crazy about the incumbent. You’ve even made a persuasive business case based on the license and infrastructure costs. Is now the time to make the deal and begin the migration? Or is now the time to step back and think more about getting to the new platform and less about what it will be like once you are there? Here are a few things to consider.
Brand new infrastructure
Your old production environment will need to stay up and running until all your bots are migrated but what about your development and test environments? An RPA platform migration can take many months, maybe more than a year. You’ll need to update at least some of your automation while you migrate right? Better plan to keep all the old infrastructure until the migration is almost complete.
Dual Licensing
During the migration you will need to pay for both licenses. Try to get your new vendor to reduce or eliminate the cost of their licenses during the migration.
Double the platform administration
Keep the administrative burden of the new RPA environment in mind when you are planning your migration. Operating System (OS) level administration, underlying databases and the platform itself all require the time and attention of your IT team.
Training
Can your new vendor get your team up and running on their platform quickly? A steep learning curve will harm RPA adoption more now than it did with the old platform. During the migration, you may find holdouts who are building bots with the old platform just because they prefer it.
Redesigns and rewrites
How confident are you that all your bots are clearly documented, commented, and can be easily converted to a new RPA tool? Dig into all your bots and get a clear understanding of the good, the bad and the ugly.
Are you rebuilding everything from scratch or are you going to invest in one of the RPA migration tools in the market which can move your bots from one RPA platform to another? Research them based on the tools you are using today and the tools you want to use tomorrow. Some of them are very impressive and map commands between two or more RPA tools. None of them perform migrations from the best practices of one platform to the best practices of another platform. If the gulf between your RPA vendor’s preferred frameworks or best practices is wide, then no amount of command mapping will eliminate the need for you and your team to think about how you re-architect your bots.
Think about how many times you worked with your current vendor to get your RPA tool to capture values or click controls in your legacy applications. Do you still run a Tandem mainframe that needs to be accessed by your bots? Java or VB applications which don’t use a common form framework? The last thing you want to do is re-investigate and re-solve all the issues you and your previous vendor overcame. Dig through your email, lessons learned, Runbooks, and your support tickets to find potential stumbling blocks.
Lastly, are your bots still providing a good return on investment? Ask your primary business users if the bot is still adding value; if not, why? Dig into the why as the bot may just need to be retired and not migrated; alternatively, the bot may need some enhancements or changes to notch up the value. Complacency can be the death knell for an automation program.
Testing
Test data, test data, test data. That’s all I need to write because one of my colleagues has already written an excellent article about its importance in making RPA successful. If you are already following automation best practices, a library of test cases and test data should already be available for your automations to accommodate minor enhancements and bug fixes…
But will it scale?
One of the classic meeting tricks, it can be used to make you seem smarter or it can be used to make you think about how your new platform will respond to the same scaling challenges you experienced with your old platform. Do month-end closing bots eat up all available licenses and computing power? Can your new vendor manage that with improved queuing technology and SLA management, or do they stress cloud integration and just-in-time provisioning? Look at your bot’s transaction data and make sure your new platform can manage the same scaling challenges you overcame with the old vendor.
Once you have thought about these topics re-assess your desire to switch vendors. Make sure the short-term pain is worth the long-term improvements.
