Power Automate alternatives, and when switching will not help

The short version

• The reason you are leaving decides the alternative: licence cost, flow complexity and judgement work lead to three different tools.
• Connector counts are a weak selection criterion, and Microsoft's own product page carries more than one of them.
• Per-user pricing means the automation bill tracks headcount rather than the amount of work automated.
• A step that needs judgement on unstructured input is not a flow, and no alternative platform has a box for it.
• Most of the work in a migration is inventory and deletion, not rebuilding.

Why are you actually looking for a Power Automate alternative?

Usually for one of four reasons, and they point at four different answers. The licence bill grew faster than the value. A flow got complex enough that the designer started fighting you. The work needs a judgement call, not a field moved from one system into another. Or the company was never a Microsoft company, so every useful integration sits behind a connector outside the standard set.

Name your reason before you shortlist anything. Teams that skip this step tend to migrate, spend a quarter on it, and arrive at the same ceiling under a different logo. 'The designer is slow' is a different complaint from 'our flows break at two in the morning and nobody notices', and the two do not have the same fix.

The cheapest good outcome is often not a migration at all. Move one class of work out, leave the rest where it is, and see whether the pain was the tool or the design. Automation platforms are not a religion. Running two is normal and frequently correct.

What are the real alternatives to Power Automate?

Five, in practice, plus the option of writing it yourself. Zapier, Make, n8n, Activepieces and Azure Logic Apps cover almost every shortlist a buying committee produces. They differ less in what they can technically do than in who is expected to maintain them and how they bill.

The table below is deliberately qualitative. Pricing on all of these moves, tiers get renamed, and the number you need is the one on the vendor's page on the day you decide, not the one in a comparison post written eighteen months ago.

Which alternative fits which problem?

What does a Power Automate licence actually stop you doing?

Nothing, until you meet the two ceilings that rarely come up in the sales conversation: request allocations and connectors outside the standard set. Microsoft documents request limits and allocations per licence in its own admin pages, and those limits are the reason a flow that looked free in testing gets throttled in production.

This should change how you design a flow. A trigger that polls every minute, or a loop over a few thousand spreadsheet rows, consumes allocation in proportion to how it was built rather than how much the business gets from it. Most teams meet this the first time a nightly flow stops halfway through and the error turns out to be about limits rather than data.

The pricing model pushes in the same direction. Microsoft publishes the Power Automate Premium price as a per-user figure, per month, paid yearly, so the bill tracks headcount rather than the amount of work automated. That mismatch is what sends most people looking: the ten people who need a licence are not the ten people generating the value. The same page carries the disclaimer 'Prices shown are for marketing purposes only', which is fair warning to anyone quoting a figure off it, including us.

Connector counts deserve less weight than they get. Microsoft's own product page gives more than one figure in different places, with the FAQ saying 'More than 1,400 prebuilt, certified connectors' while the features list gives a lower one. Neither number tells you the thing you need to know, which is whether the five connectors your process depends on support the specific operations, filters and auth model you require. Check those five. Ignore the total.

When is a different tool not the answer?

When the step that keeps failing needs a judgement call. 'Read this inbound email and decide which of nine processes it belongs to' is not a connector problem, and nothing on the shortlist has a box for it. Move that one step to something built for it, or write it, and leave the rest of the flow where it is.

The second case is unreliable upstream systems. If flows break because an API rate limits, times out, or returns a 200 with an empty body, a migration carries the problem across intact. What fixes it is idempotent steps, retries with backoff, a dead letter queue somebody actually reads, and an alert that fires at the business level rather than the step level. A new canvas gives you none of that.

The third case is worth saying plainly: sometimes the right move is to stop automating the process and change it. A flow with eleven branches is usually a process nobody has agreed on. Automating the disagreement makes it permanent and much harder to see.

What does a migration actually involve?

Inventory first, then deletion, then rebuilding what survives, which is usually a short list. Export every flow with its owner, its trigger, its last successful run, and the name of whoever complains when it stops. Expect a meaningful share to be dead: built for a process that has changed, or owned by somebody who left.

That last point is the one that hurts. Connections are authenticated as a named person, so a flow can run happily for two years and fail the week that account is disabled. Whatever you move to needs service accounts or app registrations from day one, and that is a decision to make before the migration rather than during it.

What does not come across in a migration?

• •Connections authenticated as an individual, which have to be rebuilt as service identities.
• •Triggers that depend on Microsoft-specific events, such as a SharePoint item being created or a Teams message being posted.
• •The approvals experience that lives inside Teams and Outlook, which users notice the first day it is gone.
• •Run history and the audit trail, which you lose unless you export it before you switch off.
• •Undocumented behaviour that somebody downstream has quietly come to rely on.

Is it cheaper to build the automation yourself?

Sometimes, and the comparison most teams make is wrong because they weigh licence cost against zero. The real alternative to a licence is engineering time. The US Bureau of Labor Statistics publishes a median annual wage for software developers, quality assurance analysts and testers, and whatever the equivalent figure is where you hire, a few weeks of it is the honest price of a custom build. Maintenance after that is not free either.

Low-code wins when the logic is shallow and stable: a form arrives, four fields get copied, somebody gets notified. Code wins when the logic is the product, when it changes most weeks, or when a mistake costs real money and you want tests around it. Most companies need both, which is why the hybrid is so common. Keep the plumbing in a low-code tool, put the hard step behind an API you own, and let the flow call it.

That split also protects you from the next migration. A flow that calls your own endpoint for the difficult part is far easier to move, because the difficult part was never in the canvas.

What goes wrong after you switch?

The same thing that went wrong before, which is that nobody owns the automations. These tools make it easy for anyone to build a flow, and nothing makes anybody responsible for it, so the count grows, failures go unnoticed, and the knowledge leaves with the person who built it.

A Zapier survey headline reports that 76% of SMB owners are automating work. Take the figure loosely. It is the vendor's own survey, and the only methodology on the page is 'We surveyed over 500 SMB owners and operators about how they're using AI and automation, what's holding them back, and what's gone wrong.' No fieldwork dates or panel details are given. The direction is believable. The precision is not the point.

Four things keep this from going bad, and none of them depend on which tool you picked: a named owner for every automation, a register saying what it does and what breaks if it stops, failure alerts that reach a human who can act, and a review that deletes the dead ones. Boring work. Also the difference between automation that compounds and automation that quietly rots.