How to Migrate from Airtable Without Breaking Your Automations

A practical field guide from Automation Ace.

How to Migrate from Airtable Without Breaking Your Automations

Every Airtable migration post-mortem sounds the same: the data came across fine, and then things started failing quietly for two weeks. A Zap that had run daily for a year stopped firing and nobody noticed. Attachment links in a client-facing view went dead. A script that looked up records by ID started returning nothing. None of that is a data problem — it is a dependency problem, and the dependencies are invisible until they break. This guide covers how to find them first and sequence the move so failures surface immediately instead of silently.

Inventory Everything That Touches the Base First

This is the step teams skip, and skipping it is what produces the two weeks of silent failures. Before moving a single record, build a complete list of everything that reads from or writes to the base. In practice that means checking five places:

1. Your automation platform. Every Zap, Make scenario, or n8n workflow with an Airtable step — trigger or action. Search by connected app rather than trusting your memory of what exists.
2. Airtable's own automations. Base-level automations that fire on record changes, including ones sending webhooks out to other systems.
3. Scripts. Scripting extension scripts, script actions inside automations, and any external code hitting the Airtable API.
4. Direct integrations. Tools connected to Airtable natively rather than through an automation platform — form tools, portal builders, reporting dashboards, sync tools.
5. Shared links and embeds. Public view share links, embedded forms on your website, and prefilled form URLs living in email templates or documentation.

That last category is the one that bites hardest, because those links live outside every system you would think to check. A form embedded on a marketing page or a share link pasted into a client onboarding email keeps working right up until the base is gone.

Record the inventory somewhere durable, with what each item does and which tables and fields it depends on. If you already keep automation documentation, this is exactly what it is for — see automation documentation and handoff for the format worth using.

The Four Things That Actually Break

Data migrates cleanly. These four do not:

• Record IDs. Airtable record IDs (rec...) do not come with you. Anything that stores an Airtable record ID as a foreign key in another system — a CRM field holding recXXXXXXXX, a script that looks up by ID, a webhook payload keyed on it — breaks the moment the destination assigns new IDs. Plan to either carry the old ID across as a plain text column for reference, or run a mapping table during cutover.
• Field names and IDs. Automations reference fields by name or by field ID. Renaming a field during migration because the new tool has different conventions will break every reference to it. Migrate field names unchanged first; rename later as a separate, deliberate change.
• Linked records. Relationships are the hardest part of any migration. Linked record fields become plain text or need re-linking on the other side, and the order you import tables in determines whether links can resolve at all. Import parent tables before child tables, and expect to run a second pass to rebuild relationships.
• Attachment URLs. Airtable attachment URLs are not permanent public file links, and they will not survive the base going away. Anything storing an Airtable attachment URL in another system is storing a link with an expiry date on it. Attachments have to be downloaded as actual files and re-hosted, not copied as URLs — this is covered in depth in how to back up Airtable bases, attachments, and automations.

Rebuild Automations Before You Move Data

The instinct is to migrate the data, then repoint the automations. Reverse it. Build the new automations against the new system while the old ones are still running against Airtable, with the new automations either disabled or writing to a test destination. This gives you working replacements ready to switch on, rather than a gap between "data has moved" and "automations work again."

While rebuilding, expect trigger behavior to differ. Airtable's instant triggers via webhook behave differently from polling triggers, and the destination tool may only offer one or the other — see polling triggers vs. instant triggers in Zapier for what changes when you switch between them. A workflow that assumed near-instant firing can behave quite differently on a fifteen-minute poll, and that difference matters for anything customer-facing.

Run Both Systems in Parallel

For a defined window — a week is usually enough — write to both the old base and the new system. Every new record lands in both places, and the old automations keep running as the source of truth while the new ones run alongside producing output you can compare.

Parallel running is what turns "we think it works" into "we have evidence it works." Compare outputs daily during the window: same records created, same notifications sent, same values calculated. Discrepancies during parallel running are cheap to fix. The same discrepancies discovered after cutover are incidents.

It costs double work for a week. That is the correct price for not discovering a broken lookup in front of a client.

Plan the Cutover Window Around In-Flight Records

The riskiest records in any migration are the ones mid-process at the moment you cut over — an order that has been placed but not fulfilled, an application submitted but not reviewed, a deal that is halfway through a pipeline. These have state in the old system and expect to continue in the new one.

1. Pick a low-volume window. For most businesses that means outside business hours or over a weekend.
2. Pause the automations writing into the base, so the record set stops moving while you take the final export.
3. Take the final data export and import it, including any records created since your last test import.
4. Re-link relationships and verify counts table by table — record counts matching is the fastest smoke test there is.
5. Switch the new automations on and turn the old ones off. Do not leave both running against live data; duplicate writes are worse than downtime.
6. Manually walk one record of each type through its full workflow end to end before declaring the cutover done.

Verify the Things That Fail Quietly

Loud failures announce themselves. Watch for the quiet ones in the first week after cutover:

• Scheduled automations that only run weekly or monthly — they will not prove themselves until their next scheduled run, so trigger them manually rather than waiting.
• Conditional branches that only execute for uncommon record types. A path that fires for two percent of records may not run at all during your verification window.
• Error-handling paths, which by definition only run when something goes wrong. Deliberately push a bad record through to confirm the failure path still works — the patterns in the Zapier error handling playbook apply equally to the rebuilt versions.
• Anything writing to an external system. Confirm the record actually arrived on the far side rather than trusting a green checkmark in the automation log.

Add monitoring for the first month rather than assuming success — a simple alert on "this automation has not run in 48 hours" catches the majority of silent failures. See automation maintenance and monitoring for what that looks like in practice.

Keep the Old Base Read-Only, Not Deleted

When cutover is complete, set the Airtable base to read-only rather than deleting it, and keep the subscription active long enough to be sure — a full billing cycle at minimum, longer if you have monthly or quarterly processes that have not run yet since the move. The cost of one extra month of a plan you were leaving anyway is trivial next to discovering in week six that a quarterly report depended on a table nobody inventoried.

Take a full export before downgrading or cancelling, because Airtable enforces record limits on lower plans and a downgrade can put data out of reach. The Airtable exit plan and portability checklist covers what to capture before the plan changes.

Know When Not to Migrate

Migration is expensive in ways that do not appear in a pricing comparison, and a meaningful share of migrations solve a problem that could have been solved in place. If the driver is API rate limits, that is frequently an automation design issue rather than a hard ceiling — see Airtable API rate limit 429 errors. If it is seat cost for people who only need to view or submit, an app layer over the existing base is cheaper and faster than moving. And if the base is structurally messy, that mess migrates with you unless you fix the model first.

When the move genuinely is warranted, choosing the destination well matters more than moving quickly — Airtable alternatives for automation and how to choose an Airtable alternative by use case cover that decision. If the destination is an app-building platform because seat economics drove the move, Zite is here.

For help inventorying dependencies, rebuilding automations against a new platform, or running the cutover without downtime, talk to Automation Ace.

The data is the part everyone plans for and the part that almost never causes problems. The failures come from the dozen small dependencies nobody wrote down — a share link in an email template, a record ID stored in a CRM field, a script that runs on the first of the month. Find those before you move, not after.