How to migrate from Airtable to Tallyfy

When a team decides to leave Airtable, the instinct is to start exporting. Hold off for a day. Airtable holds two different kinds of work that look the same in a grid view, and only one of them belongs in a workflow tool.

Here’s the honest version up front. A base where records flow through intake, review, and approval, and the whole thing repeats, is a workflow, and it maps onto Tallyfy cleanly. A base of products, customers, or inventory, with tables linked to each other so you can look things up, is a relational dataset, and it should stay relational. Most Airtable migrations stumble because someone tries to move the datasets too. So the real first step is telling the workflow bases apart from the database bases, and that sorting decision underpins most workflow software moves.

Why teams move off Airtable

Airtable is a genuinely clever tool, and I’ll say that plainly, because a migration guide that dismisses what you’re leaving helps nobody. Airtable gives you a real relational database with a friendly face: tables that link to each other, multiple views over the same records, forms, automations, and Interfaces you can build without code. For data that has actual relationships, that model is powerful, and it’s why teams reach for Airtable in the first place.

The friction shows up somewhere specific. It shows up when a base is asked to enforce a process.

Two reasons send teams looking elsewhere, and both trace back to that mismatch. The first is that a database records state, it doesn’t drive work forward. A record can sit in “In review” indefinitely, the next step can be skipped, and the base won’t object, because nothing in a table insists the work actually moves. The grid is happy to hold a half-finished request forever.

The second is the per-seat and per-record math. As a base grows into the thing that runs a team’s intake, every collaborator needs a seat and every request eats into record limits, so the tool that started cheap and flexible becomes the tool everyone quietly works around in spreadsheets. For work that has to run the same way every time, that’s a sign the base outgrew what a database was meant to do.

What Airtable’s export actually gives you

Start here, because the export reality sets up the whole plan. Airtable lets you export a grid view to CSV by clicking the dropdown next to the view name and choosing Download CSV, on the web and desktop apps. So the rows of any table are straightforward to get out.

Now read the limits, because they’re where a migration gets real. A CSV is flat, and Airtable’s whole value is that it isn’t. Linked records, the relationships that connect one table to another, flatten to text or record IDs on export, so the wiring is gone. Rollups, lookups, and formula fields export as their last computed value rather than the logic behind them. Attachments come across as a filename and a URL, and those URLs expire after a few hours, so a download has to happen right away.

Airtable also notes that the CSV leaves out record-level comments, field descriptions, and anything stored only in an extension. You keep the cells. You don’t keep the relationships or the conversation.

If you want a complete, structured pull, the path is the Airtable Web API, which connects your Airtable data to any external system and reads records and fields programmatically. One thing to plan for: authentication now uses a personal access token or OAuth, because the old API keys were retired in February 2024. For most migrations you don’t script against it anyway. You export the bases you’ve decided are real workflows, keep the old Airtable account read-only as your archive, and rebuild those processes fresh.

How Airtable concepts map to Tallyfy

This is the part people worry about, and the trick is that one Airtable concept, the record, maps to two different Tallyfy objects depending on what the record really is. Get that right and the rest follows.

The mental shift is from a relational grid to a sequential flow. In Airtable you connect records across tables and read them through whichever view suits you. In Tallyfy you define the process once, and each run moves through it in order. The data survives the move. The relationships between tables, and the freedom to slice the same records ten different ways, do not, and for a repeatable process that trade is worth it, because a single defined flow is what makes the work finish.

Make it concrete with vendor intake. A procurement team often runs this as an Airtable base: each record is a vendor request, with fields for the category, a single-select status moving from Requested to In review to Approved, the requester, an Airtable Form that creates the record, a linked record to a contracts table, and an automation that emails someone when the status flips. It looks like an approval workflow, but it’s a relational table with a form on the front and status changes done by hand. Migrate it the right way and each request becomes its own running process, started by a kick-off form, with a review step, an approval step that blocks until procurement signs off, and a live view of every open request. The base was holding the requests. The blueprint runs the approval.

A realistic migration timeline

There’s no honest one-weekend version of this. A real move runs about five to six weeks, and for Airtable the first week does the heavy lifting.

Week one is the sort, and it’s the most important week of the project. Go base by base and put each into one of two piles: this runs a repeating workflow, or this is a relational dataset. The test is direct. Do records in this base move through stages and then start over, or do they sit as reference data you link and look up? Only the first pile migrates. Be honest here, because forcing a genuine dataset into a workflow tool helps nobody, and Airtable stays an excellent home for the data that needs relations.

Week two, rebuild your top three workflow bases as Tallyfy blueprints. Not thirty. Three. Pick the ones that hurt most when a record stalls in the wrong status, and define them properly, with owners, order, and the approvals that matter. Week three is a parallel run: have one or two teams run the new Tallyfy process next to the old base, so you find the gaps while the old base is still there as a backstop.

Week four, move your power users over fully and set the old bases read-only. Weeks five and six, bring the rest of the team across and keep Airtable for the bases that were always datasets.

Why not just rebuild everything at once?

Because the win isn’t recreating your bases in a new tool. It’s finding the few that were always workflows pretending to be databases, and letting them run as workflows at last.

What breaks, and what Tallyfy won’t replace

Let’s be specific about what goes wrong, because every migration hits a few of these. Linked-record relationships flatten on export, so cross-table lookups have to be rebuilt as data captured in the flow or documented in a step. Rollup and lookup fields go static. Interfaces and automations don’t transfer and get rebuilt. And attachments arrive as links rather than files, with URLs that expire, so the files need pulling down before they vanish.

Now the honest part, the section most migration guides skip. There are things Airtable does that Tallyfy does not, and they matter.

Airtable is a relational database, and Tallyfy is not. The data model that links tables together, the lookups and rollups that summarize across them, and the Interfaces that present that data as a custom app have no equivalent in a sequential workflow tool. Teams that move off Airtable tend to find the cleanest split is to keep the relational data where it belongs and move only the processes. If a base is genuinely a connected dataset, a product catalog, a CRM-style table, an inventory list, keep it in Airtable. Move the intake-to-approval bases across. Running both is common and sensible: Airtable for the data that needs relationships, Tallyfy for the workflows that have to run the same way every time, and a clean client intake is often the first base worth moving.

Repeatable, automated operations, not a grid you tend by hand.

The thing teams expect to lose and don’t is the at-a-glance picture. In Airtable you build an Interface or a filtered view to see where every record sits. In Tallyfy, the live status view is built in, so every run shows up on a named step without you assembling a reporting layer. The constraint you were nervous about, losing the relational grid, is what makes the status readable, and rebuilding those automations as Tallyfy rules is usually quick once the process is clear.

Common questions about migrating from Airtable

If you’re still deciding rather than ready to move, our Airtable alternative comparison covers why teams switch, feature by feature. This guide is the how-to-move companion to it.

When you’re ready to plan the actual move, the fastest first step is a short call where we look at your current Airtable setup and tell you honestly which bases are real workflows worth migrating and which should stay as datasets.

Book a 30-minute migration walkthrough and bring your two or three busiest bases. That’s the quickest way to see whether this is a fit.