How to Migrate Airtable Automations

To migrate Airtable automations to PostgreSQL, read each one’s trigger, conditions and steps, rebuild them on top of the new database in Make, n8n or AT Migrator’s own interface, run them next to Airtable’s to compare results, and then switch Airtable’s off. They have to be rebuilt because Airtable automations run on Airtable’s servers, against Airtable’s records. Move your data to PostgreSQL and they have nothing left to react to: the emails stop going out, the statuses stop updating, the Monday digest never arrives.

Why automations stop when the data moves

An Airtable automation is a rule attached to a base: when this happens to a record, do these steps. The trigger watches Airtable’s own record changes, the actions read and write Airtable’s own tables, and the whole thing executes on Airtable’s infrastructure. None of that travels when you copy the data out.

After a migration there are two ways this goes wrong:

• Airtable stops receiving changes. Your team now edits records in PostgreSQL (or in an app on top of it). Airtable sees nothing, so no trigger fires.
• Airtable keeps running next to the new system. The automations still fire, but on stale records, and they email people about invoices that were already settled in the new database.

So a migration plan for automations has two halves: rebuild them on the new database, and switch the Airtable ones off at cutover. Not weeks before, and not weeks after.

Can you export Airtable automations?

Not directly. There is no export button, and Airtable’s public API covers records, tables, fields and webhooks but not automations. Duplicating a base copies its automations, but only inside Airtable. That leaves two routes: open each automation and copy it by hand, or read its definition through Airtable’s MCP server, the interface Airtable built for AI tools. We use the second.

Whichever way you do the rebuild, this is what you need to capture for every automation:

• The trigger: its type, its table, any watched fields, and its conditions.
• Every step in order, with the table and fields it touches and the text of any email it sends.
• The groups: which steps sit inside a conditional or repeating group, and each branch’s condition.
• Whether the automation is on, and its recent runs, including failures.
• Connected accounts (Slack, Gmail, Outlook and so on) and any script.

We read all of this through Airtable’s MCP server with a read-only token, so nothing is copied by hand. Two limits apply. Scripts are code, so they are manual work. And run history is not kept forever: Airtable keeps it for about two weeks on Free, six months on Team, a year on Business and three years on Enterprise Scale. If you are about to downgrade or cancel, record your run counts first.

What an Airtable automation is made of

Every automation is one trigger followed by an ordered list of steps. Some steps are groups that contain other steps: a conditional group (if / else-if / else) or a repeating group (for each record). Here is what each piece becomes once the data is in PostgreSQL.

Triggers

Steps and logic

Make, n8n or AT Migrator: where should they run?

The choice depends on what your team already uses and who will edit the automations afterwards.

Mixing is fine. A reasonable split is the simple record-change automations in the same service as everything else, and the one scheduled report that already lives in Make staying in Make.

How we migrate automations

1. Read. With a read-only token, we read each automation’s definition and run history through Airtable’s MCP server. Nothing in your base is changed.
2. Classify. Each automation is sorted by what it needs: plain database work, an email or webhook service, or manual work (scripts, forms, buttons). You see the sort before anything is built.
3. Rebuild. We build the flows in the tool you picked, wired to your migrated tables and calculated views.
4. Test on a copy. Each one runs against the migrated database with test records, with emails redirected to an internal address.
5. Compare. For a few days the new automations run in shadow mode next to Airtable’s, and we compare what each did against Airtable’s run history.
6. Cut over. Airtable’s automations are switched off, the new ones send to real recipients, and the base stays read-only for a while in case something was missed.

A checklist before any migration

Even if you do the rebuild yourself, do this first:

• List every automation: name, trigger, steps, whether it is on, and when it last ran.
• Mark the ones that email or message customers. They carry the most risk.
• Find any that run a script, and who wrote it.
• Find any whose condition reads a formula, rollup or lookup.
• Note every connected account: Slack, Gmail, Outlook, Jira, Google.
• Pull monthly run counts, so you can size Make operations or a server.
• Decide the sender address and domain for email.
• Decide what replaces links back to Airtable records.
• Pick a cutover day and name the person who switches Airtable’s automations off.

Related guides

If you are still weighing whether to move at all, start with seven signs you have outgrown Airtable. If you have decided, the step-by-step migration guide covers the data itself, and the comparison of migration options covers the tools.

If you want to see what your automations would need before committing, bring the list to a call. We will tell you plainly which ones are simple, which need decisions, and which need a person.