Why did my Zap stop working after I migrated, with no error email?

Because a stopped Zap and a broken Zap are different things. An instant trigger is a webhook subscription that Zapier's platform documentation says is created when a user activates a Zap and removed when the Zap is deactivated or deleted. If the subscription still points at your old account, the old account simply stops producing events, so nothing fails. There is no error to email you about. Zapier's automatic shut-off only fires on errors, and it has a floor underneath it: the help page on a Zap that is not running says Zapier turns a Zap off if it errors 95 percent of the time it runs and has run more than 20 times in the past 7 days. A Zap receiving nothing has an error rate of zero and a run count of zero, so it satisfies neither condition and never will.

Can an automation keep running against the system I just left?

Yes, and this is the expensive version. The connection holds an authorisation token for the old account, and that token stays valid until it expires or you revoke it. Anything left writing through it keeps writing to a system nobody reads. Zapier's app connections page is also explicit that reconnecting is not per-Zap: the app account is reconnected for all Zap workflows, agents and other Zapier products that use it. So one reconnect can repoint automations you were not thinking about at the time.

Why did my customers get a wave of old notifications after the switch?

Look at the polling trigger's cursor. Zapier's deduplication documentation says that when a Zap is first turned on, Zapier makes an initial call to your API, caches and stores each id field, and that when the Zap is turned off, that list is cleared. New tool means new record IDs, so nothing in that history matches. On Make, a polling trigger checks for new data since the last scenario run, and the Choose where to start setting includes an All option that Make documents as sending the date 1970-01-01. Nothing says All is preselected, but it is the option that sounds thorough the morning after an import. Choose it on a rebuilt trigger and the imported back catalogue runs through the scenario as if it happened this morning.

What should I turn off first, before cutover day?

Not the customer-facing ones. Those go last, and getting that backwards is the common mistake. Start with everything attached to the new tool — automations, webhooks, notification rules — and have it switched off before you import a single record, because the import is the event that fires it. Next, a few days out, pause the internal syncs on the old side, which nobody outside the company notices. Anything that emails, texts or charges a customer keeps running until the freeze the evening before cutover, because your customers need those confirmations right up to the moment you stop trading on the old system. Turn each one off at both ends, in the automation platform and in the old tool's own integrations screen. And leave the old subscription itself alone until the end: deleting the old account first means the platform never gets the chance to send its unsubscribe call, and the record of what was connected disappears with it.

Zapier Zap Not Working After a Migration: Why

Nine days after cutover, a client replied to a booking confirmation. Polite, slightly confused, asking whether the appointment had moved. The confirmation had been sent by the system we had stopped using on the first of the month, from a template nobody had opened in a year, triggered by a record that had been created in the new tool and pushed backwards into the old one by an automation that was still, by every dashboard we looked at, working perfectly.

Nothing had errored. That was the problem. The migration report was green, the record counts matched, and the automation platform showed a healthy run history — it was just running against a dead system.

Automations are the part of a switch that fails without failing. A missing attachment announces itself the moment somebody clicks it. A Zap that is receiving no events looks exactly like a Zap on a quiet week, and a Zap that is writing into an abandoned account looks exactly like a Zap that is working.

Three states, and only one of them is loud

After a cutover, every automation you own is in one of three conditions.

Broken. The connection is refused, runs pile up as errors, you get an email. This is the good outcome. Someone noticed.

Silent. The trigger never fires again. The subscription is attached to an account nobody writes to now, so there is nothing to send. No error rate, no alert, no entry in the run history at all — and an empty history is indistinguishable from a slow week until you go looking for the last successful run and find it was on cutover day.

Still running. The worst one. The token is valid, the old account is still inside its grace period, and the automation is diligently doing what you built it to do in a place that no longer matters. Or it is doing it in the new place, against field keys and record IDs that the import replaced. What a given app does with a mapping that no longer resolves is not something I found written down on any vendor page, which is exactly why it belongs on the list of things to try once, on one record, rather than assume will fail loudly.

Zapier's own safety net only catches the first category, and its two conditions are the reason. Zapier's page on a Zap that is not running says the platform will automatically turn a Zap off if it "Errors 95% of the time it runs" and "Has run more than 20 times in the past 7 days" (Zapier help, checked 17 August 2026). Read that second condition against a silent Zap. Twenty runs is the floor, and a trigger that has stopped firing produces none — so the safety net is not slow to notice a silent Zap, it is structurally unable to. The first condition disposes of the third category just as neatly: an automation writing cheerfully into the old account is succeeding every time.

The same page adds a plan wrinkle worth knowing before you lean on the warning email. Team accounts get a 24-hour grace period before deactivation and Enterprise accounts 72 hours, and a Zap with error ratio override switched on "will never enter a grace period". Useful to know, and none of it reaches the two failures on this page, because neither of them errors.

Sorting your own automations into those three states is a run-history job, and the history has a shelf life. Zapier's page on managing Zap history says the platform "can only guarantee a maximum of 60 days of Zap run data in your Zap history and will display up to 10,000 runs", and recommends exporting the history if you need a longer record (Zapier help, checked 18 August 2026). The same page sorts statuses into finished and unfinished — filtered, held, stopped or success on one side, playing or waiting on the other — which is the wrong axis for this particular question. Nothing in that split separates silent from still running. The field that does is the timestamp on the most recent run, and whether it falls before or after cutover.

A valid connection is not a correct connection

The mental model most people carry is that an automation is joined to an app. It is not. It is joined to an authorisation you granted once, on a particular account, in a particular workspace, and that authorisation does not know you have moved.

This matters most on the reconnect. Zapier's page on managing app connections gives the blast radius in a single line: reconnect an app account and "The app account will be reconnected for all Zap workflows, agents, and other Zapier products that use it" (Zapier help, checked 17 August 2026). One credential, many workflows. If you reconnect during a migration to point one Zap at the new workspace, everything sharing that connection follows it, including the two automations you had forgotten and the one somebody in operations built last year.

The reverse is just as true and less obvious: a connection you leave alone keeps working. It does not expire because you cancelled a plan, or because you exported your data, or because you told everyone in the company to stop using the tool. It expires when the token expires or when you revoke it.

So build the inventory before you touch anything. Not a mental list — an actual list, from four places:

The connections page of every automation platform in use, sorted by app rather than by workflow.
The old tool's own integrations or connected-apps screen. It usually knows about connections the automation platform has never heard of, because somebody authorised them from this side.
Webhook settings in the old tool, which is where anything wired up by hand ends up.
Finally, the API keys and personal access tokens page. A script on somebody's laptop is an automation too, and that page is the only place it leaves a trace.

Instant triggers are subscriptions, and the subscription stays where you made it

Instant triggers are the ones that go quiet, and the mechanism is worth knowing precisely.

Zapier's documentation describes instant triggers as apps that "automatically send new data as each trigger event occurs, using webhooks" (Zapier help, checked 17 August 2026). For that to happen, something has to be registered on the app's side first. Zapier's platform documentation for REST Hook triggers says the subscribe request "is performed when a user activates a Zap that starts with this REST Hook trigger", and that the unsubscribe request "is how Zapier notifies your API when it is no longer listening for trigger events, when the Zap is deactivated or deleted" (Zapier platform docs, checked 17 August 2026).

Read those two together and the failure mode falls out. The subscription is a row in the old system's database, pointing at a callback URL. Turn off the old tool and the row survives — it simply has nothing to report. Delete the old account without deactivating the Zaps first and the unsubscribe never happens either, so on the platform's side the Zap still believes it is listening.

The other side of this is the webhook registered straight against a vendor's own API, which does not merely go quiet — it gets deleted out from under you. Shopify's webhook troubleshooting page, which is written for app developers but describes the platform behaviour either way, states that Shopify "retries failed webhook calls up to eight times in a four-hour period", and that "After multiple failures in a 24-hour period, the webhook subscription is removed" (Shopify developer docs, checked 17 August 2026). Point a webhook at an endpoint that went away during the switch and, within a day, the subscription is not failing any more. It is gone. Restoring the endpoint will not bring it back, and if you were using webhooks to keep two systems in step, the gap is however long it took someone to notice.

Polling triggers have a cursor, and the cursor is the thing that resets

Polling triggers fail in the opposite direction. They do not stop. They start again from the beginning.

Zapier deduplicates by ID: the Zap "will check if there's new data by comparing each piece of data's unique ID to IDs the Zap has received before". The platform documentation explains where that history comes from — "When a Zap is first turned on, Zapier makes an initial call to your API to retrieve existing data, and caches and stores each id field in our database" — and, critically, "When the Zap is turned off, that list is cleared" (Zapier platform docs, checked 17 August 2026).

Now put a migration through that. The new tool issues its own record IDs, so every record in the imported database is an ID the Zap has never seen. The cached list from the old tool is not merely stale, it is meaningless — none of it will ever match again. What stops your entire back catalogue from pouring through the workflow is one thing only: the single initial call made at turn-on, plus Zapier's rule that Zaps "will not trigger for old data, including data that was created in your app before the Zap was turned on" (Zapier help, checked 17 August 2026).

That protection is thinner than it sounds, for two reasons. The initial call returns one call's worth of records, not your whole history, and the same page tells integration builders that Zapier polling triggers "don't automatically fetch additional pages" — so how far back that first call reaches is set by your API's page size, and I have not found a Zapier page that puts a number on it. The second reason is worse. A bulk import is, from the API's point of view, a pile of records created today — so "old data" in the vendor's sense is not old data in yours. If your trigger is a new-or-updated variety, any tidy-up pass after the import (a mass tag, a bulk owner reassignment, a script fixing phone number formats) touches the modified timestamp on thousands of rows and each one looks like fresh news.

Make exposes the same cursor more visibly, which is helpful right up until someone chooses the wrong option. Make's developer documentation says a polling trigger "checks for new data in a service account since the last scenario run", and that the Epoch tab defines the Choose where to start setting "so a user can select a point in the past from where the trigger should start to process data". The options include From now on, Since specific date, Choose manually — and All, which sends the date 1970-01-01 (Make developer docs, checked 17 August 2026). Nothing in Make's documentation says All is preselected, so this is not a trap the platform sets for you. It is one you walk into, because All is the option that sounds thorough on the morning after an import and the tooltip does not mention 1970. Pick it on a rebuilt trigger and the scenario will happily process the whole imported archive from the beginning of Unix time. If the next module is an email send, your customers find out before you do.

How far that gets before anything stops it is usually decided by the sending account rather than by the automation platform. Google's Workspace sending limits put a user at 2,000 messages a day and 500 on a trial account, and say that someone who exceeds the limit "can't send new messages for up to 24 hours" while still receiving mail normally (Google Workspace admin help, checked 18 August 2026). Read that as the ceiling on a bad morning rather than as a safeguard. Two thousand messages is more than most small companies have customers, and the block lands after the sends rather than instead of them.

Turn things off in this order, days before cutover

The instinct is to migrate first and fix automations afterwards. That gets the order backwards: the damage happens in the window between the import and the moment somebody checks.

The order below is not simply "most dangerous first", which is the version that reads well and does not survive contact with a working week. It splits on which side each automation sits. Anything attached to the new tool has to be dead before the first record lands there, because the import is the event that fires it. Anything attached to the old tool has to stay alive as long as the old tool is the one doing your business — which is why the row your customers would notice is late in the list rather than first.

When	Do	Why here and not earlier
T-7	Inventory from the four places above and mark each automation old-side, new-side or both	Nothing can be sequenced before this exists, and it is the one row with no cost to doing early
T-7	Switch off every automation, webhook and notification rule on the new tool, before you import a single record	The import is what fires them. If the new tool ships with a welcome sequence enabled, your imported contact list is what sets it off
T-3	Pause old-side internal syncs between the tool you are leaving and anything else	Nobody outside the company sees these stop, and they are what quietly produces the duplicates reconciliation finds in six weeks
T-1	Screenshot or export every automation's trigger, connection name and field mapping	The mapping is the part that exists nowhere else once the connection is replaced
Freeze, the evening before cutover	Only now pause what emails, texts or charges a customer — in the platform and in the old tool's own integrations screen	Customers need their confirmations until the moment you stop trading on the old system. Pausing this a week out is not caution, it is the outage arriving early and lasting longer
Cutover	Leave read-only reporting jobs running through the switch	They cannot write anything, and their run history is the cleanest signal of when the old source actually went quiet
Cutover +1	Rebuild triggers against the new account one at a time, with the destination step replaced by a do-nothing action for the first live run	Turns the mass re-fire from an incident into a log entry

Two rules hold the table together. Turn each automation off at both ends, because the platform and the old tool's own integrations screen can each keep an event flowing without the other. And do not cancel the old subscription while any of this is unresolved — the cancellation belongs at the end of the sequence, for the same reason it does in the 30-day switch runbook, which sets out where the irreversible steps sit relative to everything else.

The archive question nobody asks until later

One more thing lands in this category, and it is easy to miss because it does not look like an automation.

Plenty of small companies use an automation to write a copy of something into a second system: form submissions into a spreadsheet, support conversations into a CRM note, receipts into a Drive folder. Those workflows are the only reason some of that data exists in a readable place at all. Switch off the automation, cancel the source, and the copy stops without anything appearing to break — which is how a records trail quietly ends on a Tuesday. The same trap applies to anything you assumed was being archived by a tool rather than by you; what a vendor's own export contains is usually narrower than people expect, as the breakdown of Slack exports by plan shows.

Before you pause a workflow, ask what it was the sole writer of. If the answer is anything at all, that copy needs a home before the automation goes off, not after.

Then ask where that copy has been living, because the answer can expire on its own. If the workflow writes into a Drive folder owned by one person's account, the account is now part of your records chain: Google's admin documentation says data owned solely by a user and not transferred before deletion "is permanently deleted", that a deleted account can be restored "for up to 20 days", and that files in shared drives belong to the organisation rather than to the user (Google Workspace admin help, checked 18 August 2026). Twenty days is shorter than most people would guess, and the clock starts when somebody in HR closes the account, not when you go looking.

The one habit that would have caught my booking confirmation nine days earlier costs about ten minutes. On the Monday after cutover, open every automation's run history and look at the timestamp of the last successful run rather than at the status badge. Green means the platform is content. The timestamp is the only field that tells you whether anything has actually happened since you moved.

Checked against Zapier, Make and Shopify documentation on 17 August 2026, and against Zapier's Zap history page and two Google Workspace admin pages on 18 August 2026. Each quotation is copied out of the page linked beside it. Tools are named here because the mechanisms are documented in their own words, not because I am ranking them; there is no product recommendation anywhere above and there will not be one.

Two of those pages repay opening yourself instead of trusting the excerpt. The shut-off thresholds in the first section arrive with a 24 or 72-hour grace period on two tiers and an override that cancels it, and Zapier's polling interval is a plan setting rather than a fixed number, so the behaviour described above is your account's only if your plan matches. Make's Epoch material is written for people building custom apps, which means the four start options it lists are what a developer may choose to expose — the connector in front of you can offer fewer.

Settings get renamed and trigger behaviour changes, usually without anyone being told. When a sentence in quotation marks here stops matching the page it came from, send it to me: the claim gets re-read against the source and this note gets re-dated, which is the only job its date has. Who is writing, and what that is and is not worth, is on the about page.