It is 6:40 on a Tuesday morning and the ops lead is refreshing an inbox, waiting to find out if last night's invoice-approval sequence actually ran. Half the mornings it did. This morning it didn't, and nobody finds out until 4 PM when a vendor calls asking why they haven't been paid.
The script that kicks off the sequence lives on a server in a closet down the hall. It choked on a reboot nobody scheduled, and the one contractor who wrote it three years ago is on vacation. Nothing about the workflow itself was wrong. The infrastructure underneath it just had a bad night, and there was no one watching.
That specific failure, a process going dark because the machine running it went dark, is the exact case cloud based workflow automation is sold to eliminate. Move the sequencing logic off a server you maintain and onto a vendor's infrastructure, and the "did it run last night" question stops depending on whether anyone remembered to check on a physical box.
TL;DR:
- NIST's official definition of cloud computing lists four deployment models, and the one most relevant to a business already running legacy systems is hybrid, not the pure public cloud most vendor pages picture.
- Stonebranch's 2026 Global State of IT Automation Report found that 88 percent of organizations run automation across both cloud and on-premise environments at once, and 89 percent manage more than one automation platform to do it.
- The same report found cloud automation investment jumped to 64 percent of organizations, up 21 percent since 2024, which is the demand vendors are racing to capture with simpler pricing pages.
- Make's published pricing bills by operations, not seats, which means a workflow's real monthly cost depends on how often it runs, a variable the sticker price never shows.
What "cloud based" actually means, and why it's rarely pure
Every vendor page selling cloud based workflow automation shows the same picture: a clean dashboard, no server rack, access from any laptop. That picture is accurate as far as it goes.
NIST's cloud computing standard defines four deployment models: public cloud, where the vendor's shared infrastructure runs everything; private cloud, dedicated to one organization; community cloud, shared by a small group of organizations with common requirements; and hybrid, a mix of two or more of the others connected together. Most businesses buying cloud based workflow automation assume they are buying the public model. In practice they are running hybrid, because the workflow's trigger might live in the cloud while the data it touches, an ERP, a practice management system, an old billing database, still lives on a server in the building.
That gap between the marketing picture and the actual deployment is not a hypothetical. Stonebranch's 2026 report found that 88 percent of organizations run automation across both cloud and on-premise environments simultaneously. Pure cloud, with nothing left on-prem, is closer to the exception than the rule.
The benefit the vendor pages get right
To be fair to the pitch: the accessibility and maintenance argument is real. A workflow running on a vendor's cloud infrastructure does not go down because someone forgot to patch a server, and it is reachable from any device without a VPN into a local network. That is exactly the failure mode from the opening scene, and cloud automation genuinely fixes it.
Stonebranch's data shows cloud automation investment climbing to 64 percent of organizations, up 21 percent since 2024. That is not hype outpacing reality. It is businesses correctly recognizing that infrastructure they do not have to maintain is worth paying for.
The mistake is stopping the evaluation there, at the part the vendor page already sells well, instead of pricing the two costs the page leaves out.
The integration bill nobody prices upfront
Here is the first cost the comparison pages skip. Connecting a cloud automation platform to a system that is not itself in the cloud requires one of three things: a pre-built connector the vendor already shipped, an API the legacy system exposes that someone has to build against, or middleware installed inside your network to bridge the two.
None of those are free, and none of them show up on the pricing page. Stonebranch's report found that 89 percent of organizations already manage more than one automation platform just to cover their hybrid environment, which is a direct measure of how often "one cloud tool handles everything" turns out to be false in practice.
This is the same problem we cover from the reliability side in our breakdown of workflow orchestration: a pile of individually working automations is not the same as a system that keeps working when one piece changes. A cloud based workflow automation tool that cannot see what is happening on your on-premise systems cannot alert you when the connection between them breaks, and that gap is exactly where the Tuesday-morning scenario from the opening happens again, just with a cloud vendor's name on the invoice instead of a closet server.
The per-task pricing trap
Here is the second cost the comparison pages skip: most cloud based workflow automation platforms price by usage, not by seat, and the starting price on the marketing page reflects light usage, not real production volume.
Make's published pricing is a clear example. The Core plan starts around 9 dollars a month for 10,000 operations, which sounds inexpensive. As an illustration, a five-step approval workflow that runs 10,000 times in a month uses 50,000 operations, not 10,000, because every step in a run counts separately. Scale that to two or three workflows running at real business volume, and the monthly bill can land well past what the homepage number implied.
This is not a criticism of usage-based pricing, which is often fairer than a flat per-seat fee for a tool a business barely uses. It is a warning that the number on the pricing page describes a light test run, not the workflow once it is actually load-bearing.
What to check before migrating a workflow to the cloud
Run the decision through this order instead of the vendor's feature list:
- Map every system the workflow touches, not just the one that triggers it. Each on-premise system in that chain needs its own connector, API access, or middleware, and each one adds to the real integration cost.
- Get a written data residency answer, not a compliance badge on a marketing page. If the workflow touches regulated data, confirm where it is actually stored and processed before migrating it.
- Estimate real monthly operation volume, not the demo volume. Multiply the workflow's step count by how many times it runs in a typical month to get a realistic number before comparing platform pricing tiers.
- Ask what happens when a connected on-premise system changes. A cloud automation platform that silently fails when a legacy system's schema shifts is a bigger risk than the server-reboot scenario it was bought to prevent.
- Decide if this needs a platform subscription or custom engineering. A single, well-defined process might fit a template inside an off-the-shelf tool. A workflow spanning several legacy systems with real compliance requirements usually needs the integration built and maintained by someone who understands both the cloud platform and what it is connecting to.
If your workflow falls in that second group, that is exactly the layer our workflow automation team builds: the process mapped, the legacy connectors built and tested, and the orchestration layer wired in so a broken connection gets flagged instead of discovered by a vendor's angry phone call. For workflows that also involve an AI step, like reading an invoice or routing a request based on its content, our AI automation team builds that logic directly into the same pipeline instead of bolting a separate AI tool on top.
For a broader look at picking which process to automate first before evaluating any platform, our guide to business process automation software walks through the math that should happen before the tool comparison starts.
The rule that keeps the surprise off the invoice
Do not price a cloud based workflow automation platform by its advertised monthly plan. Price it by the connector cost for every on-premise system the workflow touches, plus the operations bill at real production volume, and only then compare that total against what a server closet was actually costing you.
If a vendor cannot put a number on the connector cost during the sales call, that number does not exist yet, and it becomes your problem the week after the contract is signed.
If you would rather have the integration mapped, built, and maintained by a team that has already done it for hybrid environments instead of guessing at connector costs from a pricing page, our workflow automation team can scope your specific systems and tell you exactly what the real monthly cost looks like before you sign anything.
