Migrate from Airtable to Grist

How to migrate from Airtable to Grist without losing base logic

A renewal, a residency requirement or a lock-in concern usually starts the move off Airtable, and the short answer for Grist is this: its Airtable import brings across records and schema, authenticated either with a personal access token or with an OAuth2 integration that your administrator registers with Airtable using read scopes for records and schema. Formulas, views, forms and automations do not come across as working logic, so they need deliberate rebuilding. Platform or IT teams usually own this work because they control the self-hosted Grist instance, the Docker deployment and the identity setup, and many bring in an implementation partner to scope the inventory of bases and to test the rebuilt logic before cutover. Effort and risk rise with the number of formula fields, linked tables and automations per base, so start with an inventory rather than the import itself.

Airtable does not offer a whole-base file export, so the extraction path is not a single download. Each table is exported as its own CSV from a view, which means views with filters or hidden fields can silently drop rows or columns if they are used as the source. Decide up front whether the import through the API is the authoritative extract, and use CSV exports only as a cross-check of row counts and attachment handling. Confirm with your own test base how attachments, linked records and multi-select values arrive, because the import behavior for these fields determines how much cleanup follows. Keep the original Airtable bases read-only during the test period so you have a reference to compare against.

Before cutover, write down every formula, lookup and rollup field and map it to a Python formula in Grist, testing each one against known values from the Airtable original. Grist formulas support full Python syntax with the standard library and many Excel functions, which covers most arithmetic and text logic, but any Airtable behavior that depends on Airtable-specific functions needs a manual equivalent. Rebuild views and forms from the inventory, and check who can edit which pages, since Grist access rules are set per document and must be tested with real user accounts. Ask your partner or internal team to document each rebuilt automation with its trigger, expected output and failure path, and sign off the test results before any user is moved over.

Which Airtable capabilities map to Grist and which need rework

This table maps each Airtable capability a base relies on to its closest Grist equivalent and marks it as clean, needs rework or gap. Read the rows against your own bases, since formula-heavy and permission-heavy bases will need the most planning. The main takeaway is that data and formulas move well, while automations, interfaces and single sign-on need separate decisions.

Airtable capability	Grist equivalent	Status	What to confirm in a test document
Tables and records	Tables in a Grist document, imported with the Airtable importer	Clean	Record counts and field types match after import
Attachments	Attachment column type stored in the document	Needs rework	Check that every file opens and that links to old Airtable URLs are replaced
Linked records	Reference columns between tables	Clean	Two-way references and multi-link fields resolve to the right rows
Grid views	Grid views with sorting, filters and hidden columns	Clean	Filters and sort order reproduce the same rows
Formula fields	Column formulas written in Python, with many Excel functions	Needs rework	Each formula returns the same value on sample records
Lookups and rollups	Formula columns that read referenced tables	Needs rework	Totals and lookups match Airtable output on a sample of records
Forms	Grist forms or a rebuilt input page	Needs rework	Submissions land in the correct table with the right types
Interfaces	No direct equivalent; rebuild with Grist pages and widgets	Gap	Each dashboard or portal from the Airtable base is listed and assigned a rebuild plan
Automations	Automations are part of Grist's full edition, not grist-core	Gap	Confirm your license covers automations before planning cutover
User access and single sign-on	Document sharing; OIDC or SAML needs an activation key in the full edition	Needs rework	Map each Airtable role to a Grist access level and test with real accounts

What data and integrations to extract and rebuild

Airtable data reaches Grist through three different routes, and each one carries a different share of the base. Records, schema and attachments can come across through the importer, while automations, API consumers and webhooks have to be rebuilt against Grist's own interfaces. Treat each card below as a separate checkpoint in the cutover plan.

Airtable importer with access tokens

Grist's Airtable import works with an Airtable personal access token without extra configuration. The alternative is an OAuth2 integration that your administrator registers with Airtable using read scopes for records and schema. Pick the route based on who owns the token and whether the import must run under a service identity. Confirm in a test base which tables, views and attachments arrive before you run the full import.

Per-table CSV export as fallback

Airtable has no whole-base file export, so each table is downloaded as its own CSV from a view. Use this path for tables the importer skips or misreads, and for a second copy kept for verification. Export from a view that shows every field you need, because the CSV only carries what the view displays. Attachment links in CSV exports are not a durable archive, so download attachments separately if you must keep them.

Grist REST API for ongoing sync

Grist offers a REST API with an interactive API console, which is the target-side route for scripted loads, reconciliation and any sync that must continue after cutover. Build the load scripts against a staging document first, then point them at production. Ask your team to document which service account holds write access and how its token is rotated.

Excel and CSV import into Grist

Grist imports and exports Excel and CSV files, which suits one-off table loads, corrections and handoffs to people who work in spreadsheets. Map column types by hand during import, since Airtable single select, linked record and date fields do not always translate to the same Grist column types. Check reference columns after each import, because broken links are easy to miss in a large table.

Webhooks and API consumers to rebuild

Airtable webhooks and integrations that call the Airtable API do not point at Grist after migration. Each consumer must be rewritten against the Grist REST API, with its own authentication, field names and document identifiers. Inventory every external system that reads or writes the base, including reporting jobs, and assign an owner to each before cutover.

Automations and scripts to recreate

Airtable Automations are not carried over by the importer, so each trigger and action needs to be rebuilt. Grist automations sit in its full edition, so confirm that your license covers them before you plan the rebuild. Test every rebuilt automation against copies of real records, and record which ones run on a schedule so no job is silently dropped at cutover.

Migration sequence from inventory to decommission

This sequence moves Airtable bases into a self-hosted Grist instance in controlled stages, so each base is proven against its original data before users depend on it. Each step closes with a written artifact that the next step relies on, and decommissioning only happens after the retained exports are verified.

Inventory bases, tables and formulas
List every base in the workspace, then record each table, view, field type, link between tables, lookup, rollup and formula, along with the automations, interfaces, forms and API integrations that read or write each base. Name an owner for every base and note which users and external collaborators have access. The output is a field-mapping sheet that pairs each Airtable field with its planned Grist column or Python formula, and marks which formulas must be rewritten in Python. The step is done when the business owner of each base has reviewed and signed the sheet.
Pilot import into a test Grist instance
Stand up a separate test Grist instance from the gristlabs/grist Docker image, with a persistent volume for data, and import one low-risk base using the Airtable integration. Authenticate with a personal access token for a simple case, or with an OAuth2 integration that the administrator registers with Airtable using read scopes for records and schema if the team needs a shared connection. Compare record counts, attachments, linked records and formula results against the source, then rewrite formulas in Python and rebuild the views and forms the team uses. The output is a signed-off pilot checklist listing every mismatch found and how it was resolved.
Rehearse the full migration and fix gaps
Repeat the import on a copy of each remaining base in the test instance, working from the field-mapping sheet and the pilot checklist. Record which Airtable features do not carry over, such as automations and interfaces, and decide whether each is rebuilt in Grist, moved to an external workflow tool, or retired. Confirm that user roles and document-level access match the inventory. The output is a rehearsed import log per base and a list of open rebuild items with owners.
Run both systems in parallel
Load the production Grist instance with the bases in the order agreed in the inventory, then keep Airtable live while named users enter work in both systems for a period the project team sets. Compare outputs such as reports, totals and exported files each working day, and log every discrepancy with its root cause. Treat any formula difference as a defect in the Python rewrite until it is shown otherwise. The output is a parallel-run reconciliation log with a sign-off from each base owner.
Cut over with a frozen Airtable base
Announce the cutover window, then make each Airtable base read-only for editors, revoke write-capable integrations and API tokens, and take a final import into Grist so the two systems agree on the last record. Switch users, links and any scheduled integrations to the Grist document, and confirm that the pre-cutover exports completed. The output is a cutover runbook with timestamps, the name of the person who executed each action, and a rollback path that stays documented until the sign-off in the next step.
Verify production and retain exports
After users have worked in Grist for the agreed observation period, check that record counts, attachments and access rules in production match the reconciliation log. Export each table as CSV from its view, since Airtable does not offer a single-file base export, and collect attachments from their links before they expire. Store these exports and the runbook in the organization's own archive, alongside the Grist backups configured by the platform team. The output is a verified archive index that the compliance lead can review.
Decommission the Airtable bases
Once the archive index is accepted, remove remaining Airtable integrations, revoke personal access tokens and OAuth connections that were issued for the migration, and downgrade or cancel the Airtable seats no longer in use. Confirm with Airtable the billing end date for the plan, and ask the vendor how long deleted base data remains recoverable. The output is a decommission record that lists each base, the date it was retired, the location of its archive and the owner who approved the closure.

What drives cost and duration in an Airtable to Grist move

This table lists the cost components of moving Airtable bases into self-hosted Grist, who is paid for each, and whether it is one-time or recurring. Use it to see which parts of a quote scale with your base count and formula complexity, and which are fixed by your identity and licensing decisions.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Inventory of bases, tables, views and formulas	Internal staff or implementation partner	One-time	Number of bases, count of formula and lookup fields, and how many automations and interfaces depend on them
Import through personal access token or OAuth2 integration	Internal admin, possibly the partner	One-time	Whether a personal access token is enough or an OAuth2 integration must be registered with Airtable using read scopes for records and schema
Rebuilding formulas in Python	Developer or analyst time	One-time	Formula complexity and how many Airtable functions have no direct Grist equivalent, so each needs a rewrite and test
Rebuilding views, forms and filters	Business owners and builders	One-time	Number of grid, form and kanban views and how many users rely on them daily
Testing and reconciliation of record counts and attachments	Internal staff or QA, optional partner	One-time	Record volume, attachment count, and how many linked-record relationships must be checked by hand
Identity and single sign-on decisions	Identity team, licensing contact at Grist Labs	One-time setup, possibly recurring license	Forwarded-header authentication and Sign in with getgrist.com are included in all editions, but direct OIDC or SAML needs an activation key from the full edition
Full edition licensing	Grist Labs, if your organization exceeds the limit	Recurring if applicable	Grist's full edition is free for individuals and small organizations with less than US $1 million in total annual funding (Grist self-hosting page), and a 30-day trial is available from the Admin Panel
Hosting, backup and upgrades	Your infrastructure team or hosting provider	Recurring	Server size, persistence volume backup frequency, and how often you apply new Grist releases
Training and change management	Internal trainers or partner	One-time, with ongoing onboarding	Number of editors, how much formula logic must be explained, and whether users move from Airtable interfaces to Grist pages
Support and retainers	Implementation partner or internal team	Recurring if chosen	Scope of ongoing upgrades, monitoring and testing agreed in writing

How the move differs by base size and starting point

A few bases owned by one team, with light formulas and no automations that other teams depend on, are the simplest case. The importer does most of the work, and the rework is mostly confirming that views, field types and linked records came across as expected. Because the owners are few and close to the data, the review can happen in one pass before the old base is retired.

Fewer owners to coordinate: one or two people can check record counts and sample rows against the source base.
Light rebuild scope: simple formulas and lookups are usually recreated quickly, while views and filters need a quick visual check.
Short cutover window: the team can agree on a freeze date for edits in Airtable and run the import once.
Clear rollback: keep the Airtable base read-only for a set period so the team can compare results.
Access carried over by hand: share the new Grist document with the same people and confirm edit rights.

Before starting, confirm with the team which views they actually use, since unused views are the easiest part to drop.

What usually goes wrong and how to prevent it

Most failed Airtable to Grist migrations do not fail on the import itself. They fail on formulas that behave differently after rebuilding, attachments that break, extraction limits that cut records short, permissions that never reached the new instance, and automations nobody listed. Each risk below has a check you can run before cutover.

Formulas that recalculate differently

Airtable formula fields do not carry over as working Grist formulas, so each one must be rewritten in Python or Excel-style functions. Differences in null handling, date arithmetic, text comparison and rounding can produce silently different totals. Build a test table with known inputs, compare Airtable's computed values against the Grist results row by row, and sign off each formula before users rely on it.

Lost or re-linked attachments

Attachment links in Airtable are temporary, so an import that runs after the links have expired, or a token that was revoked mid-run, can leave attachment fields empty. Confirm that a sample of files opens in Grist after import, check the attachment count per table against Airtable, and keep the original files in a dated archive until users confirm they can open every one.

Extraction limits and API caps

Import and export depend on what your Airtable plan allows. Free, Team and Business plans cap records per base and API calls per workspace per month, so a large base may stop partway through an extraction. Check the record count per table and the plan caps before you start, run the import on a copy, and reconcile totals against the source before retiring it.

Broken user permissions

Airtable's base sharing, view-level restrictions and interface access do not map one to one onto Grist's document access rules. Users who had edit rights in Airtable may land as viewers, or the reverse. Build a permission map that lists every collaborator, role and restricted view, confirm each person's access in Grist with a test account, and decide whether single sign-on needs the full edition before go-live.

Forgotten automations and sync jobs

Airtable automations and scripts are not moved by the importer, so notifications, status changes and webhooks can stop without anyone noticing. Inventory every automation, its trigger, its action and its owner, then decide for each whether to rebuild it in Grist automations, move it to an external workflow tool, or retire it. Test each rebuilt trigger with sample data before cutover.

Unverified record counts

Without a reconciliation step, missing rows and duplicated rows tend to surface weeks later. Compare record counts per table, totals for key numeric fields and a set of spot-checked records, including linked records and their attachments, between the source and the Grist document. Record the results in a signed-off checklist so that cutover decisions rest on evidence.

Where the Grist instance sits and what trust boundaries change

The first decision is where the Grist server runs, because it determines which network sees the extracted Airtable data. Grist is deployed from the gristlabs/grist Docker image, which listens on port 8484 and keeps documents in a /persist volume. Put that volume on storage you already back up and encrypt, and keep the container inside your own cloud account, data center or air-gapped network. If your policy calls for open-source code only, use the gristlabs/grist-oss image instead, which contains only open-source code. Confirm with your security team whether the full edition's features, such as OIDC or SAML single sign-on, are needed before choosing the image, since those features are outside grist-core.

The Airtable extraction itself runs through the Grist import, so the data path matters more than the tool. Grist calls Airtable using either a personal access token or an OAuth2 integration that your administrator registers with Airtable with read scopes for records and schema. Whichever you choose, the token or client secret is a credential that reaches Airtable and then your Grist server, so store it in your secrets process, not in a spreadsheet or chat thread. Records and attachments move from Airtable to your Grist host over the network path you control. Airtable keeps the source base untouched until you cut over, which means you can run test imports repeatedly and keep the original as the reference copy.

Two trust boundaries change. Grist can run each document in a gVisor sandbox on Linux or with Docker, which limits what a document process can reach on the host, so enable it and confirm it works on your hosts before importing sensitive bases. Your identity boundary also moves: Airtable's access rules no longer apply, and document sharing, workspace roles and any forwarded-header or identity provider integration must be re-established in Grist and tested with real user accounts. Before cutover, verify the sandboxing setting, the restore path for the /persist volume and who holds the Airtable credential after the import finishes, then revoke it.

Questions buyers ask before moving from Airtable to Grist

How much does an Airtable to Grist migration cost?

The software side is free to start: self-hosting the Grist Community edition carries no license fee, according to the Grist self-hosting page. The larger costs are the people and infrastructure around it: servers or cloud accounts to run Grist, the time to export or import each base, rebuilding formulas and views, and administration after cutover. Costs rise with the number of bases, linked tables, attachments and custom Python formulas, and fall when the base set is small and well documented. Ask any provider for a fixed-scope quote that lists each base, the import method, the formula rebuild, the views and forms, testing, and whether a paid Grist full edition license is included. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from that written scope.

How long does moving from Airtable to Grist take?

The timeline depends on how many bases you have, how many formulas, automations and interfaces they depend on, and whether users must switch on a fixed date. Grist's Airtable import can bring over records and schema in one pass, so the rebuild work usually sets the length of the project. Start by inventorying each base, then rank them by complexity and by how much the business relies on them. Pilot one base end to end before the rest, and agree a cutover window in writing. No duration is given here because no researched figure supports one, so ask for a timeline tied to your base inventory during scoping.

What does the migration need from our team?

The work needs business owners who can confirm what each base is for, which fields matter, and who should see which records. It also needs an administrator who can register an OAuth2 integration with Airtable if you choose that route, or create a personal access token for an account with access to the bases. Engineers should own the hosting environment, identity integration and backups. Plan for someone to test formulas against known outputs, since formulas are the part most likely to behave differently after the move. Confirm these roles in the scope document before work begins.

Can our internal team migrate the bases alone?

Yes, a team with spreadsheet and database experience can attempt it, because Grist's Airtable import works with a personal access token and needs no extra configuration, according to the Grist help center. The harder parts are rebuilding formulas in Python, recreating views and forms, setting access rules and validating results. Teams with few engineers often underestimate testing and cutover. A useful check is whether someone can explain each formula's expected output and who will maintain Grist after launch. If those gaps exist, a fixed-scope engagement can cover the parts your team does not have time or skills for.

Does Grist import Airtable attachments and formulas?

Grist's Airtable import brings across records and schema, which covers the data your tables hold. Attachments and formulas need separate attention. Confirm with the Grist help center how attachment files are handled in your version before relying on them, and test a sample base with real attachments. Airtable formulas are not copied as working Grist formulas, so each one must be rewritten in Python and checked against the original results. Lookup, rollup and linked-record logic should also be verified after import. Keep the original Airtable base available until every formula has been compared.

What changes if we buy Grist's full edition?

Grist's full edition adds capabilities that are not in the open-source grist-core repository. According to the grist-core GitHub repository, these include single sign-on via OIDC or SAML, audit log streaming, Advanced Admin Controls, automations, OAuth apps, the built-in MCP server and the Grist Assistant. The Grist self-hosting page says the full edition is free for individuals and small organizations with less than US $1 million in total annual funding, and that a 30-day trial is available from the Admin Panel. Connecting Grist directly to an identity provider over OIDC or SAML needs an activation key, while forwarded-header authentication works on all editions. Decide early whether your identity model needs that key, because it affects the design of access rules.

Does the migration affect compliance evidence?

Moving to self-hosted Grist changes where records, accounts and logs live, so your compliance evidence must be rebuilt for the new environment. Document access control, backup, change history and retention, and map each to the controls your auditors use. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so confirm the evidence format with them before cutover.

How DeployOpen scopes and runs the Grist migration

DeployOpen plans and runs the move from Airtable to a self-hosted Grist instance inside your own infrastructure. Each engagement is fixed-scope, with the bases to migrate, the deliverables and the timeline agreed in writing before work starts.

How we scope

Inventory every Airtable base, table, view, form and automation to decide what migrates and what is rebuilt.
Confirm whether import uses a personal access token or an OAuth2 integration registered with Airtable.
Agree in writing which formulas, views, forms and access rules Grist must reproduce, and which are retired.

How we build

Deploy grist-core from the gristlabs/grist Docker image with a persistent /persist volume in your environment.
Run the Airtable import per base, then check record counts, attachments and linked fields against the source.
Recreate formula fields in Python and rebuild views and forms, testing each against sample records before cutover.

How we hand over

Document the instance, configuration, backup procedure and the mapping from each Airtable base to its Grist document.
Provide a test log showing imported records, rebuilt formulas and the checks performed on each table.
Walk your administrators through user access, document sharing and the upgrade steps for future Grist releases.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete.
Review Grist release notes with your team before applying version upgrades to production documents.
Confirm with your own security and compliance team which full-edition features, such as single sign-on, you need before purchase.