Moving an AI pilot to production takes five things: a trigger that starts without a human, a route for failures, a named owner, a number you watch, and somewhere to make changes without touching the running system. Miss one and you have a demo that happens to run every day.
This is for the person responsible for operations in a company of 5 to 50 people with a proof of concept that works. A proof of concept is a test rig: built to show that something is possible, not to carry real work.
Why do AI projects stall at the pilot stage?
Because a pilot is judged on whether it works and production on whether it keeps working. Those are different questions. In a pilot someone starts the run, watches it, and fixes whatever breaks. That person is the error handling, and the role appears in no document.
There is a second reason. Pilots get tested on the easy cases. The exceptions, the empty fields, the customer with two addresses: those arrive once the thing runs daily. The causes behind failed programmes are covered in why SMEs fail at AI more often than large corporates. This article is about the handover itself.
When is a pilot ready for production?
When these seven items are done. The mechanisms come from the n8n documentation, the platform WeAdapt builds on most often. Make and Zapier address the same points in their own way.
- A trigger that starts without a human. Every production workflow needs at least one trigger node, the node that decides when the workflow runs [S-030]. As long as someone has to press something, it is not production.
- A route for failures. In the workflow settings, select a workflow to trigger if the current workflow fails [S-037]. That error workflow receives the details of the failed run and the errors [S-031] and puts them where somebody looks.
- Saved executions. Decide whether failed and successful production executions are saved [S-037]. Without them, tomorrow morning nobody can reconstruct what happened.
- A limit on run time. Set after how long an execution is cancelled [S-037]. A workflow that hangs is worse than one that fails, because it raises no alarm.
- An owner and an approval step. Write down who may change what. With more than one editor, have a specific version approved before publication, by the assigned reviewer or an admin [S-034].
- Somewhere to make changes. An environment is an instance plus a Git branch, and separate environments for development and production is the common pattern [S-036]. Note that credentials and variable values do not sync with Git and have to be set up per environment [S-036].
- A number you watch. Agree on the metric: total production executions and the failure rate among them [S-035]. Without one, nobody notices a workflow that quietly stopped.
The list is deliberately short. If it takes more than half a day, something is being built that the pilot did not need yet.
What happens when a workflow fails?
Without an error workflow, nothing visible. The run stops, the day carries on, and the gap surfaces later as missing data that someone repairs by hand. That is the expensive version, because the cost lands downstream from where it was caused.
With one, the route is fixed. The Error Trigger node gets the details of the failed workflow and the errors, and runs the error workflow [S-031]. What happens inside it is your choice: a message in the channel the team already watches, a line in a log, a task in the system where the work lives. One error workflow shared across your automations is enough to start with.
Where do you change a system that is already running?
Not in the running system, once real work depends on it. An environment is an instance plus a branch, and the split between development and production exists precisely for the moment you want to change something without stopping the work [S-036].
For a small business with a handful of workflows this does not have to be heavy. Two things usually cover it: a copy to test in, and an agreement that a change only ships after someone else has looked at it [S-034]. The part you do have to arrange explicitly is credentials, which do not sync and have to be configured per environment [S-036]. That is the mistake everyone makes once.
Who owns it and what do you measure?
One named person and two numbers. The owner receives the alerts and decides whether a change ships. Without that name, maintenance stays with whoever built it last, and that is rarely a deliberate choice.
The two numbers are total production executions and the failure rate among them. Both sit in the n8n Insights view, alongside average run time and the time saved as configured per workflow [S-035]. Read them monthly. A workflow suddenly running half as often has usually stalled on a source that changed a field name.
What the numbers will not tell you is whether the output is still right. The people using it will. A report that gets reworked by hand every week counts as a successful execution and is still unfinished. What the finished version looks like is described in automate management reports.
How long does the transition take?
Shorter than most programmes suggest, as long as the scope stays small. WeAdapt works from discovery call to live in four weeks, including process mapping, building, review and training. That is the lead time for a first working workflow, not for a programme that touches the whole company.
The pilot to production step itself is usually days rather than weeks, once the seven items are clear. Most of the delay is not technical. It is the decision about who becomes the owner.
Frequently asked questions
What is the difference between a pilot and production? A pilot proves something is possible, with a human watching. Production means work depends on it and nobody watches by default. That is why production needs a trigger, a failure route, an owner and a metric, and a pilot does not.
Does every automation need to reach production? No. A pilot that shows the gain is smaller than expected has done its job. Pushing on because time has already been spent is the most expensive reason to put something live.
What if the pilot was built in a different tool? Then the move is a rebuild, not a migration. Ask what the pilot was for. If it only had to prove the logic, rebuilding in the platform that will own it afterwards is often faster than hardening the test rig.
How many people do you need to maintain it? One owner and one backup. Not because the work is heavy, but because people go on holiday. The workload follows the number of connections, not the number of workflows.
The route from test rig to production runs through consultancy for the order of work, then workflow automation for what actually ends up running.
Want to know which of your test rigs is ready for production? Book a call. What ends up running is shown in the cases.