Three signs you do not own your automations even though you pay for them
Ownership of an automated system is not settled by the invoice. It is settled by where it runs, whose name is on the keys, and whether anyone outside the person who built it can understand it. Three signs show up every time, and all three can be checked in an afternoon without telling anyone.
- You cannot get in on your own. If seeing how a process is doing means asking someone for a screenshot, you do not have access: you have a middleman. The test is literal — log in today, unannounced, and look at the last run.
- You do not know what it decides. If nobody on your team can explain why one case landed in the review queue and a similar one did not, the business rule is not yours. It works, but you do not own it.
- You cannot change vendor without stopping. If the only answer to "what if we drop them next month?" is "everything stops", what you bought is not a service: it is a dependency with a monthly invoice.
None of the three implies bad faith. Most of the time they are the natural result of having started fast: it was built in the builder's account because that was the quick way, it was connected with whatever credentials were at hand, and the rule was agreed over the phone. It works. And it keeps working right up to the day you want to move it. Which is why you check this while everything is fine, not once you have already decided to cut.
The account and the credentials: where the system lives and whose name is on it
This is the step most often skipped and the only one that, if it fails, invalidates everything else. There are two layers and they get confused constantly: the platform account where the flows run, and the credentials for every service those flows connect to.
- The platform account. The Make workspace, the n8n instance, the Zapier project. It has to sit on an email address on your domain —not anybody's personal one—, with your payment method and at least two admins on your side. If the vendor pays the plan and bills it back to you, it is not yours.
- The credentials of every connection. Access to your CRM, your ERP, the shared inbox, the payment gateway. Each one should be created by you, ideally as a service user with scoped permissions, not as the personal account of a consultant who will eventually leave.
- The domain and the webhooks. The URLs other systems push data to. If they point at a vendor domain, switching vendor means touching third-party configuration, and that is the slow part of any migration.
The honest check is a single question: if you changed the admin password tomorrow, would everything still run? If the answer is no, or you do not know, there is your outstanding work. And it is not a negotiation job: it is a two-day technical migration that also leaves your credentials inventoried, which is exactly what any serious control over what an automation is allowed to touch asks for.
Exporting the flows: what a file carries and what it leaves behind
This is where nearly everyone relaxes too early. You get a JSON file with the flows, you file it away and you consider the matter closed. The file is necessary, but it is not the system: it is the blueprint. And there is a part of the blueprint the platforms leave out by design.
- In Make, the scenario blueprint is a JSON holding the modules, their settings and the mapped values; connections do not travel inside it, so whoever imports it has to re-authorise every service with their own accounts.
- In n8n, the workflow JSON includes the credential name and id but not its contents; credentials are exported separately from the command line, come out encrypted, and only decrypt on an instance holding the same encryption key.
- In all of them, what the file leaves out is the environment: variables, headers, rate limits agreed with a provider, mailboxes authorised to send. That is the part that makes the same flow work here and fail there.
So you do not accept handover against a file, you accept it against a run. The test is simple and admits no nuance: import the flows into an account of yours and watch them complete a real case end to end, with your credentials, before anyone signs anything. If the process moves money or commitments to a customer, that test happens in a staging environment first, with the same discipline you would use to test any change without breaking the automation.
The business rule: the part that shows up in no export
An exported flow tells you what the system does. It does not tell you why. And the why is the expensive part: the 3,000-euro threshold, the list of five customers who never go through automatic approval, the reason emails from one specific domain have been ignored since March. None of that is in the JSON. It lives in decisions somebody made and never wrote down.
The way to get it back is not to ask for "documentation" —that word produces PDFs nobody reads—. It is to ask for a list of decisions, which is a far smaller and far more useful artefact.
- Every branch in the flow, with its threshold and its reason. One line per "if… then…": what it compares, against what value, and where that value came from.
- The named exceptions. Customers, suppliers or cases that get different treatment, and who authorised that treatment.
- What the system does when something fails. Who it alerts, what it retries, what it parks for a human.
- What it deliberately does not do. The list of things that were consciously left out is what stops the new team from "fixing" something that was fine as it was.
If the vendor cannot produce that list in a couple of hours, it is not ill will: it is that the system was never documented and the rule lives in someone's head. That is your risk, not theirs, and it is solved with the same method used to document any automation already in production: rebuild the why from real runs, not from memory.
The execution history: the asset nobody asks for and everybody misses
It is the request forgotten in nine out of ten handovers and the one most missed a month later. The history —what ran, when, on what data, with what result— is what turns an automation into something measurable instead of an act of faith.
- It is your baseline. Without knowing how many runs a day there were and what share failed, you cannot show the in-house system performs as well or better. You will argue it from memory, and memory always says it used to be better.
- It is your odd-case detector. The cases that break a flow do not appear in the documentation: they appear in the last six months of error logs. That list is worth more than the manual.
- It expires. Most platforms keep run detail for a limited window depending on the plan. Ask for it three months after cutting and it no longer exists.
Ask for it before you announce the change and store it outside the platform: an export of the log, raw if need be. It is also the material you need to work out what fell through and what has to be reprocessed if the migration leaves a gap.
The overlap: how you cut without cutting the service
A handover done properly has no D-Day. It has a window in which both systems coexist and only one is in charge. The classic mistake runs the other way: contract end date, lights out, and the new team discovering under pressure that the billing flow carried a condition nobody mentioned.
- Mirror first, command later. The new system runs in parallel without writing to production —or writing to a test destination— and results are compared for several days. Anything that diverges gets investigated before anything is touched.
- Cut in sections, not in one go. One flow moves across, gets verified for a week, then the next. The process that moves money goes last, never first.
- The old system gets switched off, not deleted. It stays disabled and reachable throughout the overlap. A flow deleted on cut-over day is a bridge burned with the only party who knew how it worked.
- A full cycle before you close. If there is a month-end close, the overlap includes an entire one. Odd cases do not show up on Tuesdays: they show up on the 30th.
The logic is the same as any well-run platform migration —it is exactly the method used to move from one tool to another without stopping the service— with one difference: here you are not only changing tool, you are changing who owns the knowledge. And that part does not import with a JSON.
One honest note to close on: bringing things in house is not always the answer. Moving the flows home means somebody on your team takes on the pager, the API updates and the ongoing upkeep, which is real work with a real cost. The right question is not "in house or outside?", it is "do I own this either way?". When the answer is yes, staying with a vendor is a calm economic decision. When it is no, you are not buying a service: you are renting your own process. If you want that check run by someone from outside —account inventory, proven export, business rule rebuilt and an overlap plan—, that is exactly what we do in operations automation.