UiPath to Power Automate migration services for a small robot estate

The honest reason people leave

There is no forcing event here, and any consultancy telling you otherwise is selling urgency. UiPath is a current, supported product; nothing has been retired and no deadline is running down. What happens instead is a renewal quote landing on a finance director's desk next to a Microsoft 365 bill, and somebody asking why the company pays per robot for work that a platform it already subscribes to can do. That question is usually asked by a company with a handful of bots rather than a robotic operations team — the estate grew from one clever automation, then four more, and it never reached the scale where a dedicated RPA licence pays for itself.

The comparison is genuinely favourable, but only structurally, and only for small estates. RPA licensing is priced per robot; Power Automate's desktop automation is priced per user and per unit of unattended capacity, on top of Microsoft 365 rights many organizations already hold in part. Whether that lands in your favour depends entirely on how many unattended runs you need and how many people trigger automations by hand, which is why the scope names the count instead of promising a percentage. We quote no savings figure on this page, because the only honest number comes from your own bot inventory against the live figures on Microsoft's Power Automate pricing page (opens in new tab). The second reason people move is quieter: an RPA estate maintained by one departing contractor is a risk, and flows sitting in the same tenant as the data, the approvals and the reports are simply easier for an in-house admin to pick up.

Why this is a rebuild rather than a conversion

Microsoft publishes no importer for UiPath projects, and no third-party tool hands you a finished automation either — the accelerators that market themselves this way produce an inventory or a partial skeleton that still needs an engineer. That is not a tooling gap so much as a difference in shape. A UiPath process is one XAML workflow executed by a licensed robot that carries its own scheduling, queue and credential context from Orchestrator. The same work in Power Automate is usually split in two: a cloud flow holding the trigger, the branching, the approvals and the connector calls, and a desktop flow (opens in new tab) holding only the part that genuinely has to drive a user interface. Deciding where that line falls, for each bot, is the work. The table below is the map we use; the inventory in your written scope is a filled-in copy of it.

Two of those rows decide your timeline. If most bots are scheduled, unattended and driving a browser or an ERP screen, the work is selector-heavy but predictable. If they carry queue logic, document extraction and exception routing built on the Robotic Enterprise Framework, there is genuine redesign in front of us, and we would rather price that as the scope it is than discover it in week three.

Attended, unattended, and what each one costs to run

This is where most UiPath migrations go wrong, because the two platforms draw the line in different places. In UiPath, attended and unattended are robot types you buy. In Power Automate, they are run modes gated by different licences: user licences carry attended capability, capacity licences carry unattended capability, and a machine has to be registered by a licensed user before capacity can be allocated to it at all. Microsoft's own machine management documentation (opens in new tab) sets out the registration and unattended-bot mechanics we work from.

We fill this table in with your bot names during scoping, and it is the part clients tell us they were never given by their original RPA vendor. Where the answer is that Power Automate would cost you more — a genuinely high-volume, many-parallel-run estate does exist — we say so and you keep your money.

Selectors, and why the applications matter more than the bots

Selectors are the single most under-estimated part of an RPA migration. A UiPath selector is a serialized description of a control in an application's accessibility tree; Power Automate builds the same idea out of UI elements, and neither one can read the other's format. The saving grace is that the underlying applications do not change, so what looks like rewriting is really re-capturing: the same button in the same window, described again. Power Automate for desktop captures UI elements (opens in new tab) using UI Automation by default, with MSAA available for older Win32 and VB6 applications that never exposed a modern accessibility tree, and a raw mode for awkward custom-rendered or Electron interfaces.

The practical upgrade is that a single UI element can hold several selectors, tried in order until one matches, and that selectors can be anchored to an element's visible text rather than its position in the tree. Where your existing bots break every time a vendor ships an update, that is usually a position-anchored selector, and the rebuild is a chance to fix it rather than reproduce it. It is also the reason we insist on running old and new side by side for a period before switching anything off: a selector that works on your engineer's screen and fails on a locked, differently-scaled unattended session is a classic RPA failure, and parallel running is what catches it.

Blue Prism and Automation Anywhere estates

The same service covers them, and for the same reason: the licensing model, not the vendor, is what usually prompts the call. A Blue Prism estate splits work between reusable Objects and the Processes that orchestrate them, with a Control Room scheduling sessions and work queues feeding them. Objects map cleanly onto the reusable subflows and UI element repository in Power Automate for desktop; Processes become the cloud flow layer; the Control Room's schedules become cloud flow triggers, and its work queues become work queues. Automation Anywhere estates arrive in a similar shape, with the Control Room holding schedules and credential lockers and task bots doing the screen work, so credentials move to connection references and Key Vault while the bots themselves are rebuilt as desktop flows.

We deliberately do not publish a separate page for each of these. The inventory, the attended-versus-unattended mapping, the selector re-capture and the parallel-run cutover are the same work in each case, and a page per vendor would be the same advice with the nouns swapped. If your estate mixes two RPA tools — which happens more often than vendors admit, usually after an acquisition — it is scoped as one project.

Is this the right page?

Several of our services end in a Power Automate flow, and they are not interchangeable. The difference is what you are starting from.

Who this is for — and who it is not

This page is written for an organization of roughly 20 to 500 people running three to ten bots: an overnight robot keying orders from a mailbox into an ERP, an attended bot a billing clerk fires twice a month, a screen-scrape that produces a report because nobody could get at the database, an invoice-reading bot with a document model behind it. The estate was never a programme. It was a few good ideas, and now it carries a renewal.

It is not written for a twenty-plus bot estate with a robotic centre of excellence, an in-house development team and a governance board. Several of the consultancies ranking for this search sell exactly that, as a multi-quarter engagement, and they are the right call at that size. We are a fixed-fee shop delivering in weeks with senior US-based engineers, and pretending otherwise would waste your time and ours. If you are between the two, say so on the form and we will tell you honestly which side you fall on.

Once the rebuilt automations are live, new work that starts from a process rather than an existing robot sits under our Power Automate approval workflow consulting. Bots that should have been an application belong with our custom Power Apps development service, and anything that turns out to be system-to-system integration is scoped as Azure Logic Apps consulting services in your own subscription. We serve all US states remotely from our Orange County, CA base.

Delivery in three phases

Most small RPA estates sort into three phases. The table shows scope and typical timeline rather than prices, because an honest number requires reading your bots first — the same principle described on how our fixed-fee process works.

Everything produced is yours from the first day. The flows, the solution files, the UI element definitions and the documentation live in your own Microsoft tenant, never in ours, and your own admins can edit any of it after we leave.