How to move off Make (Integromat) as your workflow tool

Leaving Make as your workflow tool barely counts as a migration, because most of what you’d move isn’t a workflow at all. A Make scenario is a chain of modules that shuttle data between apps in the background. Make, the kind of point-to-point integration plumbing that AI agents increasingly handle on their own, is genuinely good at that shuttling, and none of this is an argument to switch it off. The reframe is smaller than that. A handful of your scenarios stopped being plumbing somewhere along the way and turned into workflows. They sprouted a manual step, then an approval, then a router that waits until a person decides. Those are the ones to move, because a scenario can’t track a person.

That sorting is the entire task, and it’s worth saying plainly: Make didn’t let you down, it just got handed work it isn’t shaped for. A module fires and moves on. A workflow waits on people, shows who’s stuck, and remembers what’s done. Telling the two apart is the same clear-eyed call you make in any vetting workflow software decision, and it’s most of the value here.

Why Make quietly became your workflow tool

Nobody decides to run approvals through an integration platform on purpose. It creeps in. You build a scenario to push a form submission into a spreadsheet, and it works. Then you bolt on a module to ping a manager. Next a filter, so only the big ones go through. After that a router, so urgent cases branch off. A few months later that “scenario” is a messy multi-person process held together by a tool that can’t show you one of those people.

A pattern we keep seeing with teams on Make is how little of their scenario library is really integration. Plenty of it is workflow wearing a costume: someone has to look, judge, and pass it on, and the scenario is just the wiring around that person. A fair amount of what gets automated this way, invoice handling being the obvious case, is human work dressed up as a data pipe.

The pain lands in predictable spots. A scenario errors quietly and nobody notices until a customer does. The operations-based bill climbs as the modules multiply, because Make counts every operation, including the ones that only check whether anything changed. And when someone asks where an approval is, the honest answer is to open the run history, because the people aren’t tracked anywhere.

So what’s the goal here?

To pull the human workflows out of the plumbing, so the people in them are visible and accountable, while the genuine data moves keep humming along untouched.

What you can actually export from Make

Here’s where Make differs from the spreadsheets-and-databases crowd: there’s a real export, and it still doesn’t get you where you want to go.

Make lets you export a scenario as a Blueprint. Open the scenario, click the three dots in the top corner, and export the blueprint as a JSON file to your device. That Blueprint holds the scenario’s modules, their settings, and the values mapped between them, a reusable copy of how the whole thing is wired. You can share it with another Make user or paste it into a fresh scenario, and it rebuilds exactly.

So why doesn’t that solve the migration?

Because a Blueprint is a Make definition, not a portable workflow. It pastes back into Make, into an LLM, or into another tool that speaks Make’s format. It doesn’t import into Tallyfy, and no converter would make it. You can read your scenario’s structure from the JSON, which is genuinely handy, but you can’t load it anywhere that runs human work.

That sounds like a dead end. It isn’t. Since the Blueprint won’t import, you skip the half-broken conversion and start from what the scenario actually does. Which modules are a person deciding something? Where does it pause for a human?

Reading that takes a few minutes per scenario, and it’s the same reading you’d do anyway to rebuild the workflow properly. The export turns out to be a map you read, not a thing you carry across.

Which scenarios actually belong in Tallyfy

Not all of them, and knowing which is the line between a smart move and an overreach.

Walk through one. Picture an order-exception scenario: an order that fails a validation check fires a Make scenario that flags it, posts to a channel, and writes a row to a data store. It looks automated. But the real work, a person deciding whether to refund, reship, or escalate to a manager, happens off to one side in email and chat.

In Tallyfy that becomes a blueprint instead. A failed order kicks off a process, a review step lands with the right person, an approval step gates the refund, and you see where every item is sitting without chasing anyone. The channel-notification module can stay precisely where it is. It’s the human judgement that belongs in a workflow.

Flip that around. A scenario that copies new Stripe charges into your accounting tool and does nothing else has no person in it. No decision, no wait, no hand-off. That one stays in Make, or moves to whatever connector layer you land on later. Leave the plumbing be, and move the parts where people live.

A realistic way to make the move

Expect a few weeks, and spend the first one sorting rather than building.

Week one is the audit, and it pays for itself. Walk your scenario list and tag each one: pure data move, or human workflow in disguise. The test is blunt. Does a person have to look, decide, or wait? If yes, it’s a workflow. If it only carries data from app A to app B, it’s plumbing.

The giveaways are specific in Make. A sleep or “wait” module that holds the scenario until later. Then a router whose branch depends on someone’s reply. Or a manual trigger a person fires by hand, or a data store that exists only so a human can come back and flip a flag. Each is a spot where the scenario is really waiting on a human, not on data. Those are your scope. The rest stays put.

Weeks two and three, rebuild the human ones. Take the disguised scenarios one at a time and build each as a Tallyfy process: the kick-off form, the steps a person works, the approvals, the routing. You’re not importing a Blueprint, you’re recreating the people-part from what you read, which goes quicker than it sounds because the logic was always simple, just buried in modules.

Then leave the plumbing alone. The genuine app-to-app scenarios keep running, and over time you can move those to AI-native integration as it matures. There’s no flag-day cutover, because the two halves never touched. You’re not turning Make off. You’re taking the people out of it.

What Tallyfy won’t replace

Here’s the honest boundary, because this is easy to misread: Tallyfy is not an integration platform, and it won’t replace your connector layer.

Middleware moves data between apps. Tallyfy runs the human work that data is meant to serve.

Tallyfy doesn’t move data between hundreds of apps in the background. There’s no module library, no per-trigger wiring between your CRM and your mailer, none of the substrate Make is built on. You still need a connector layer for real app-to-app moves, and more and more that layer is AI letting AI write the integration when you ask for it rather than a per-operation bill. If that’s the job, keep Make or move to something AI-native, and don’t ask Tallyfy to be it.

What Tallyfy takes over is the other thing, the human-workflow layer that crept into your scenarios and never belonged there. Forms, approvals, ordered steps, and a status view a business user can actually read, all the parts a module can fire toward but never run. So you end up with two layers, not one tool beating another. Modules move the data. Tallyfy runs the people.

Forcing middleware to do the people part is how you got workflows nobody can see, which is the reason you’re reading this. It’s also what teams shopping for AI automation tend to work out a step late, because the agent still needs a defined process to act inside.

Common questions about moving off Make

If you’re weighing the move rather than ready to make it, our alternatives overview shows where Tallyfy sits against the tools teams put it beside. This guide is the doing half of that call: how to lift the human work off the middleware once you’ve decided.

When you’re ready, the best first move is a short audit call: we walk your scenarios together, split the real integrations from the disguised workflows, and confirm which ones rebuild cleanly.

Book a 30-minute migration walkthrough and bring the scenarios with a person stuck inside. Those are the ones worth moving.