Apps & Automation
From the field archive · Learned in 2024
Moving From UiPath or Blue Prism to Power Automate: What I Look At First
Before anyone converts a single bot, these are the questions I ask. Most of them have nothing to do with the conversion tool.
In 2024 I spent a good part of the year in conversations with customers who were running UiPath or Blue Prism and wanted to know whether Power Automate could take over. The question usually arrived as "can Power Automate do what our bots do?" That's a fair question, but in my experience it's the second question you should ask, not the first.
The first question is what your bots actually do today, and whether all of them still need to exist. In this post I walk through how I approach an RPA migration, what I learned from the customers I worked with, and what has changed in Power Automate since then. I'm not here to compare vendors. The platforms these customers used are capable. The goal is to help you move with fewer surprises.
A few things make this conversation easier today. Hosted machine groups let you run unattended desktop flows at scale without building or patching your own VMs; Power Automate provisions and autoscales the bots, within the Hosted Process capacity assigned to the environment. Work queues give you prioritized, SLA-aware queues for transactional work. Process mining and task mining are built into Power Automate for discovery. The Automation Kit has a migration module with planning guidance and conversion samples. And Copilot Studio now has a computer use tool that lets an agent operate websites and desktop apps from natural-language instructions. Some of its hosting options are still in preview, so check current status on Microsoft Learn before you plan around them.
01Start with an inventory, not a converter
Almost every migration conversation I had in 2024 started with a demo of a conversion tool. I understand why. But converting a bot you should have retired is wasted effort, and converting a bot whose process has drifted just moves the problem to a new platform.
Here's how I approach it. Before anything is converted, I ask for a simple inventory of every production bot with a few columns filled in:
- Business owner and the team that depends on the output.
- Run frequency and volume, plus what happens when it doesn't run.
- Systems touched, and whether each one has an API or connector today.
- Credentials used, and whether they belong to a person or a service account.
- Last change date, and who on the team can still explain the logic.
That last column matters more than people expect. If nobody can explain what a bot does, you're not migrating a process, you're reverse-engineering one.
If you have event logs from the systems your bots touch, run them through process mining in Power Automate first. It's a quick way to see whether the process you automated years ago still matches how the work is done now.
02Sort every bot into one of four buckets
Once the inventory exists, I sort each bot into one of four buckets. One clear decision per bot keeps the project honest.
| Bucket | When it fits | What I recommend |
|---|---|---|
| Retire | Low volume, no clear owner, or the underlying system has changed | Turn it off, confirm nobody notices for a cycle, then archive the definition |
| Rebuild with connectors | Every system involved now has an API or a Power Platform connector | Use a cloud flow. It's easier to maintain and doesn't need a machine |
| Move to a desktop flow | At least one step only works through a user interface | Use a desktop flow for the UI steps, called from a cloud flow |
| Redesign with an agent | The work involves judgment, unstructured input, or a conversation | Consider Copilot Studio, with desktop flows or computer use as tools |
In my experience, the "rebuild with connectors" bucket is bigger than customers expect. Many bots were built years ago because an API didn't exist yet. It often does now.
03Map the concepts, not the actions
Teams that know another RPA platform well sometimes look for a one-to-one action mapping. I'd temper expectations there. The better exercise is to map the operating concepts, because that's where your runbooks, monitoring, and support model live.
| Concept you already run | Where it lives in Power Automate |
|---|---|
| Central orchestration and scheduling | Cloud flows trigger desktop flows; machines and machine groups are managed in the Power Automate portal |
| Bot runtime machines | Your own registered machines, hosted machines, or hosted machine groups |
| Transaction queues | Work queues, with priority, SLA settings, and auto-retry on IT exceptions |
| Run queue and priority | Desktop flow queues, with High or Normal priority per run |
| Credential vault | Power Automate credentials backed by Azure Key Vault or CyberArk |
| Reusable components | Subflows and child desktop flows, packaged in solutions |
| Release management | Solutions, connection references, and pipelines across environments |
One thing worth knowing about work queues: Microsoft documents that only some work queue actions can currently be classified in data loss prevention policies, and cloud flow usage of work queues can't be restricted by them. If DLP coverage is part of your design, check the current list before you commit.
04The email question
The most common functional question I got was about email. Many finance and operations bots start with a mailbox: read new messages, save attachments, pull data from an Excel file, update a system, reply.
A customer's finance team shared what their accounts receivable bots did and asked, step by step, how Power Automate would handle each one. I walked through each step with them, starting with email: Power Automate for desktop includes actions to work with Outlook and Exchange mailboxes, so a straight port is possible. The refinement I'd add for any team in that position is a split: let a cloud flow own the mailbox trigger and the attachments, and keep the desktop flow for the steps that truly need the user interface.
Cloud flows are better at waiting for events, and desktop flows are better at driving screens. Don't tie up a machine polling a mailbox.
05Conversion tooling: accelerator, not finish line
Automated conversion is useful, and I've seen it save real time. The Automation Kit's migration guidance describes a typical pattern: assess and scan your existing automations to size the effort, convert them to equivalent Power Automate for desktop actions, and mark anything that needs a developer's attention with TODO comments so the remaining work is visible. Partners offer tooling that follows this approach.
A utility running a large Blue Prism estate wanted to understand its options. I arranged a demo and discussion with a migration partner so the customer's automation team could see assessment and conversion tooling for themselves. The part I point teams to first is the assessment scan. It turns a vague "how big is this?" into a list of processes ranked by complexity, which makes the pilot much easier to choose.
Here's what I recommend once you have conversion output:
- Pick three to five processes for a pilot: one simple, one complex, one business-critical.
- Treat every TODO as a design decision, not a typo. Some are better solved with a connector.
- Run the old and new bots in parallel on real data before cutting over.
- Measure run time, failure rate, and the effort to fix TODOs. Use those numbers to estimate the rest.
Validation gates help here. The Automation Kit guidance describes using ALM checks to make sure TODO items are removed and DLP checks pass before a solution moves to production. Even a simple checklist in your pipeline catches a lot.
06Infrastructure, licensing, and identity
This is where I see the most avoidable delays, because it involves infrastructure, security, and procurement teams. Start early.
Your own or hosted?
Registered machines give you full control. Hosted machine groups remove VM setup and autoscale bots across groups, up to the Hosted Process capacity assigned to the environment.
Attended vs unattended
Attended and unattended runs are licensed differently, and hosted machines need Hosted Process capacity. Check the current Power Platform licensing guide before you size anything.
Who does the bot run as?
Decide early which accounts sign in to machines and which identities own the cloud flows. Service principal ownership keeps flows running when people leave.
Identity is the one I'd spend the most time on. In 2024, several customers planned to reuse the same service accounts their old bots used, which is reasonable, but those accounts were often subject to password rotation. I wrote about how to handle that in a separate archive post on service accounts and password rotation.
A telecom provider asked me how RPA fit with their broader Copilot strategy. The underlying worry was finishing an RPA migration only to redo it for agents a year later. My advice to teams with that worry is to keep UI automation modular: build desktop flows as small, single-purpose units with clear inputs and outputs. That way a cloud flow can call them today, and an agent can use them as tools later.
That advice holds up even better now. Copilot Studio agents can call agent flows and desktop automation, and computer use can operate an application from instructions when there's no API at all. I'd still use deterministic desktop flows for high-volume, rules-based steps, and reserve computer use for work where screens change often or the steps need some interpretation.
07Governance from day one
An RPA platform tends to accumulate privileged access: machine credentials, system accounts, and broad connectors. Set the guardrails before the first production run, not after.
- Put every migrated automation in a solution, in a dedicated environment, not the default environment.
- Store machine and application credentials as Power Automate credentials backed by Azure Key Vault or CyberArk, not in flow variables.
- Use data policies to classify desktop flow action groups and block what you don't use.
- Use connection references so production connections are mapped on import, not edited by hand.
- Turn on monitoring in the admin center and review failed runs weekly during the first months.
For the wider toolbox, including inventory, monitoring, and data policies, see my governance tools guide. For environment strategy, see Environment Strategy and DLP.
Where I'd start
Build the inventory first and sort every bot into retire, rebuild, desktop flow, or agent. Map your operating concepts, not individual actions. Run a scan to size the work, pilot a handful of processes in parallel, and sort out machines, licensing, and identity before the pilot ends. Conversion tools are a real help, but the decisions you make before conversion matter more.
Happy to go deeper on any of this.
— K.G
Sources
- Microsoft Learn: Introduction to the Power Automate hosted RPA; Hosted machine groups; Hosted machines
- Microsoft Learn: Work queues overview; Work queues actions; Monitor desktop flow queues
- Microsoft Learn: Overview of process mining and task mining in Power Automate
- Microsoft Learn: Secure your data (desktop flow coding guidelines); Create an Azure Key Vault credential
- Microsoft Learn: Support for service principal owned flows
- Microsoft Learn: Automate web and desktop apps with computer use (Copilot Studio); Configure where computer use runs
- Automation Kit for Power Platform: RPA migration module; Microsoft Power Platform Blog, "Begin your Robotic Process Automation modernization journey"
Get new posts by email
Provider: your email provider
