How to migrate from Airtable to Baserow without losing base structure
If your renewal, a pricing change or a residency requirement has pushed Airtable onto your agenda, the short answer is this: Baserow's Airtable importer copies tables, records, attachments, relationships and grid views from a base, one base at a time, using a public share link. Formula, lookup and rollup fields, collaborator fields, automations, interfaces, comments and revision history are not carried over, so those must be rebuilt by hand. Plan the migration around that split from the start, because the data moves quickly while the logic takes most of the time.
In most organizations the work falls to the internal platform or IT team that already owns the Airtable relationship, usually a small group with one or two people who know which bases matter and who depends on them. Some teams bring in an implementation partner for the rebuild of automations and interfaces, or for hosting and single sign-on, but the business owners of each base still need to sign off on what the new version must do. Before you start, inventory every base and mark which fields are formulas, lookups or rollups, which automations send email or call external systems, and which interfaces external users rely on. That inventory determines the effort far more than record count does.
Effort and risk are manageable when you treat each base as a small project. Run the importer on a copy, check record counts, attachment handling and linked records table by table, then rebuild the calculated fields and automations against a written list of expected outputs. Confirm with Baserow's import documentation and your own test base exactly which field types and view settings come across in the version you deploy, since the importer scope can change between releases. Keep the Airtable base untouched until the rebuilt Baserow version has run in parallel for an agreed period, and ask any quote to name who performs each of these steps and what the cutover acceptance test is.
Which Airtable capabilities map to Baserow and which need rework
This table compares each Airtable capability in a base with its Baserow counterpart after the public share link importer runs. Read each row as clean (carried over by the importer), needs rework (carried over in part or rebuilt by hand), or gap (not carried over and not available in the same form). Confirm current feature coverage in Baserow's import documentation before cutover.
| Airtable capability | Baserow after import | Status | What to do |
|---|---|---|---|
| Tables and records | Tables and rows copied from the base | Clean | Check row counts per table against the source after import |
| Attachments | Files copied with the records | Clean | Spot-check that files open and link to the right rows |
| Relationships (linked records) | Link-to-table fields recreated | Clean | Confirm both sides of each link resolve to the intended rows |
| Field types and grid views | Field types, grid views with filters and sorts | Clean | Review each view, since sort and filter behavior should be verified against the original |
| Formula, lookup and rollup fields | Not imported | Needs rework | Rebuild with Baserow formula fields or lookups, then compare results on sample rows |
| Collaborator fields | Not imported | Needs rework | Replace with a user or text field and map values to Baserow accounts |
| Automations | Not imported; Baserow automations are built by hand | Needs rework | Rebuild each trigger and action, then test on a copy of the table |
| Interfaces | Not imported; Baserow application builder pages are built by hand | Gap | Plan dashboards and portals as new Baserow application pages |
| Comments and revision history | Not imported | Gap | Export or archive the Airtable history if an audit needs it |
What data and integrations to move, and by which export path
Baserow's Airtable importer carries the data and view structure of a base across in one pass, but formulas, automations, interfaces and every connected system stay behind. The cards below separate what the importer moves, what you must export by hand, and what you rebuild on the Baserow side before cutover.
Importer from a public share link
Baserow's importer copies one base at a time from a public share link. It carries tables, records, attachments, field types, relationships, and grid views with their filters and sorts. Run it against a pilot base first, then compare record counts, linked-record counts and attachment counts table by table. Note that the share link must be public while the import runs, so decide how long it stays open and who can see it.
Attachments and file handling
The importer copies attachments, but attachment behavior is the first thing to verify on a pilot base. Check file counts, file names, sizes and that files open correctly after import, especially in tables where a single record holds many files. Confirm how your Baserow instance stores uploaded files before you rely on it for records that carry contracts or identity documents.
CSV-per-view export route
Airtable does not export a full base as one file. Each table is downloaded as its own CSV from a view, so a complete copy means one export per table, with hidden fields and filtered rows handled deliberately. Use this route when the importer cannot read a base, or when you need a flat copy for a second system. CSV loses field types, links and attachments, so treat it as a fallback rather than the main path.
Other import formats
Baserow also imports CSV, Excel, XML and JSON, which covers tables exported from other systems or from the CSV route above. These formats carry values but not Airtable's relationship and attachment structure, so relink linked records and re-upload files manually. Map each column to a field type before import so dates, numbers and single-select options do not arrive as plain text.
Rebuild API integrations and webhooks
Scripts, syncs and webhooks that call the Airtable API do not move with the base. List every integration and its endpoints, then point each one at the Baserow REST API with tokens created for that purpose. Expect to rewrite field references, since Baserow identifies fields differently, and test each integration against the pilot base before cutover.
Recreate user accounts and permissions
Collaborator fields, base sharing and user accounts are not carried by the importer. Rebuild workspace membership, roles and access rules on the Baserow side, and decide which people need accounts on your own instance rather than a shared link. Collaborator and assignee fields need manual replacement, so document which user each record belonged to before the export.
The migration sequence from inventory to decommission
This sequence moves Airtable bases to self-hosted Baserow one base at a time, with each step ending in a written output that the next step depends on. It ends with an archived export and a closed Airtable access path, so the organization can prove what moved and what was rebuilt.
Inventory bases, views and integrations
List every base in scope, its tables, the views each table uses, and every formula, lookup, rollup, automation, interface, form and API integration attached to it. Record who owns each base and which teams depend on it. Mark which fields are native Baserow field types and which are not, because lookup, rollup, formula and collaborator fields are not carried across by the importer. The output is a base inventory list with one row per base, which becomes the master checklist for every later step.
Import a pilot base from a share link
Choose one low-risk base with a mix of field types, attachments and relationships. Create a public share link for the base in Airtable, then run Baserow's Airtable importer against that link on a non-production Baserow instance. Confirm the importer documentation for the current steps and any limits on the share link before you start. Check which tables, grid views, filters and sorts arrived. The output is a pilot report that lists what came across and what did not, field by field.
Reconcile records and attachments in parallel
Run Airtable and the imported Baserow base side by side for a period agreed with the business owner. Compare record counts per table, spot-check relationship links, and open a sample of attachments in both systems to confirm they open and match. Ask a few named users to check their usual views against the source. Record each discrepancy and its resolution. The output is a reconciliation sign-off signed by the base owner, which states the record counts and the known gaps accepted for cutover.
Rebuild formulas, automations and interfaces
Recreate the calculated and linked logic the importer skipped. Rebuild lookup, rollup and formula fields as Baserow fields or formulas, and replace collaborator fields with user or text fields where needed. Recreate each Airtable automation as a Baserow automation or an external workflow, and rebuild each Airtable interface with Baserow's application builder. Test each trigger with sample records and confirm the expected outputs. The output is a rebuild log that maps every removed Airtable item to its replacement or to a decision to retire it.
Cut over one base at a time
For each base, set a cutover date with its owners, freeze edits in Airtable, run a final import or delta copy, and point users, API clients and integrations at the Baserow base. Confirm access rules, invitations and single sign-on work for each group of users. Keep the Airtable base available in read-only form until the next step. The output is a cutover checklist per base, signed off by the owner, that records the final record count and the time the Airtable base was made read-only.
Archive Airtable data before decommissioning
Before any Airtable access is removed, export each table as CSV from a view, because Airtable does not export a full base as a single file. Download attachments while links are valid, store them with the export, and keep a copy of the rebuild log and reconciliation sign-offs alongside them. Store the archive in the organization's own storage with a documented retention period set by its records policy. The output is an archived export index listing every file, its source base and table, and its checksum.
Decommission Airtable access
Remove Airtable users, revoke personal access tokens and integration credentials, and disable any public share links still in use. Cancel or downgrade the Airtable plan only after the finance and procurement teams confirm the contract terms. Update the asset register, runbooks and access reviews to show that Airtable is no longer a system of record. The output is a decommission record showing the date access ended and the archive index it relies on.
How the Baserow stack is deployed and what the license choice changes
The baserow/baserow Docker image runs every Baserow service in one container, with an internal PostgreSQL and Redis by default. That is fine for a pilot or a proof of concept that you will migrate later, but Baserow highly recommends an external PostgreSQL for production, so plan for a managed or separately operated database from the start. Ask your platform team who will own backups, point-in-time recovery and patching for that database, because a single-container install keeps the Airtable data, attachments and user accounts in one place that is hard to back up independently. The Baserow Docker installation documentation documents Docker Compose with separate backend and web-frontend images, and Kubernetes with Helm for horizontally scaled deployments. Choose Compose for a single host serving one migrated team, and Helm if the import will be followed by several bases, many users and attachment volumes that must scale independently.
The MIT-licensed core of Baserow is free to self-host for commercial and private use, but it does not include every feature. Self-hosted Baserow offers Premium, Advanced and Enterprise licenses, and an instance can run only one license type. Single sign-on through SAML, OAuth 2.0 providers and generic OpenID Connect requires the Advanced or Enterprise license with an activated license key, so an organization that expects to replace Airtable's corporate login must budget for that choice before cutover. Role-based permissions and audit logs are also listed under Advanced on Baserow's cloud pricing page, which is a separate price list from the self-hosted licenses. Confirm in the Baserow self-hosted license types documentation which features each license covers at the version you will deploy, and do not rely on the cloud pricing page to answer that question.
Before cutover, write a short decision record that names the license type, the features it must provide (single sign-on, permissions, audit logs, seat model) and the person who approved the choice. Confirm the license scope with Baserow in writing, and test single sign-on and access rules on a staging instance with a copy of one imported base. Note that the seat model differs by license: Premium assigns seats manually, while Advanced grants paid access to users on the instance, so the expected user count changes the cost of each option. Ask for the license and support terms as part of the quote, and check whether license keys must be activated again after upgrades, since version changes drive the upgrade work that DeployOpen can take on under a retainer.
How the migration differs by starting point
A small team with one base and a handful of tables usually has the shortest path. The Airtable importer copies tables, records, attachments, field types, relationships and grid views with their filters and sorts from a public share link, so a base whose day-to-day use is grid views and plain data fields can often be running in Baserow after one import and a short check. The work that remains is mostly verification and user onboarding.
- Data fields: Text, number, date, single select and attachment fields are the ones most likely to arrive intact. Compare row counts and a sample of attachments against the source.
- Views: Grid views with filters and sorts come across. Check that each view still shows the rows your team expects.
- Relationships: Linked record fields between tables in the same base are carried over, so confirm that links resolve correctly after import.
- Lost fields: Formula, lookup and rollup fields are not imported. Recreate them in Baserow before retiring the Airtable base.
- Users: Invite people to the instance and decide whether the free tier or a paid license fits the number of users.
Before cutover, confirm which fields your team actually uses each week and whether any of them are calculated fields that will need manual rebuilding.
A workspace with several bases that point at each other needs more planning. The importer works one base at a time from a public share link, so links that cross base boundaries cannot be recreated automatically. Decide first which base is the source of truth for each entity, then import in an order that lets you rebuild cross-base references by hand or through a documented mapping.
- Import order: Start with the base that other bases reference, so you can record the new row identifiers for later linking.
- Cross-base links: Expect to re-create these as linked fields or text identifiers, and test a few records end to end.
- Share links: Each base needs its own public share link during import. Revoke links after the import completes.
- Permissions: Map Airtable workspace roles to Baserow workspace and database permissions before inviting users.
- Verification: Compare row counts per table and spot-check cross-base lookups against Airtable.
Check with your team which cross-base relationships are used in reports, because those are the ones most likely to break silently after cutover.
Bases where most of the logic lives in formula, lookup, rollup and automation fields need the most rebuild work. The importer does not carry formula, lookup or rollup fields, and it does not carry automations or interfaces. The data arrives, but much of the business logic does not, so the migration is closer to a rebuild than a copy for these bases.
- Inventory: List every formula, lookup, rollup and automation, with its trigger, inputs and downstream use, before importing.
- Formulas: Baserow has its own formula language. Rewrite each Airtable formula and test it against sample rows, since function names and behavior do not map one to one.
- Automations: Rebuild triggers and actions in Baserow automations or an external workflow tool, and test each one with real edge cases.
- Interfaces: Dashboards and forms built on Airtable interfaces need to be rebuilt in Baserow's application builder.
- Cutover: Run old and new logic in parallel for a defined period and compare outputs.
Scope this work before committing to a date, because the rebuild effort is driven by the number of calculated fields and automations, not by the record count.
Regulated teams usually need single sign-on, role-based access and audit records before any data moves. In Baserow, single sign-on through SAML, OAuth 2.0 providers or generic OpenID Connect is available on the Advanced and Enterprise plans with an activated license, and self-hosted instances can use only one license type. Licensing is therefore part of the design, not a later purchase.
- License planning: Decide between Premium, Advanced and Enterprise before go-live, since an instance cannot mix license types. Ask Baserow to confirm current terms for your user count.
- Single sign-on: Plan the identity provider integration and test provisioning and deprovisioning with a pilot group.
- Audit controls: Confirm which audit events your chosen plan records and how you export them to your log platform.
- Data location: Because the instance runs in your own infrastructure, define the region, backup location and administrator access model in writing.
- Evidence: Keep records of the import, the rebuilt logic and the access review for your assessor.
Ask your Baserow contact and your compliance lead to confirm the license scope and audit features in writing before you schedule the import.
What drives the cost and duration of an Airtable to Baserow move
This table breaks down who is paid for each part of an Airtable to Baserow move, which costs recur, and which inputs push effort up. Use it to shape a written, fixed-scope quote and to decide where to cut scope before work starts. The main takeaway is that rebuild work for formulas, automations and interfaces usually outweighs the import itself.
| Driver or cost component | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Internal staff time | Base owners must inventory views, confirm field mappings, validate imported records and sign off each base before cutover | Name one owner per base and agree acceptance checks before the import starts |
| Number of bases | Each base needs its own share link, import run, validation pass and cutover window, so effort grows with base count | Retire unused bases first and migrate in waves grouped by team |
| Attachment volume | The importer copies attachments from a public share link, so large attachment sets lengthen runs and raise storage needs on your servers | Archive old attachments, confirm object storage capacity, and check that share links stay valid for the full run |
| Formula, lookup and rollup fields | The importer does not carry these fields across, so each one is rebuilt by hand in Baserow and its results compared with Airtable | Document each formula's purpose, remove unused fields, and simplify chains before rebuilding |
| Automations and interfaces | Airtable Automations and Interfaces are not imported, so triggers, actions and pages must be redesigned and tested | Rank automations by business value and drop those nobody uses; ask for a test plan per workflow |
| SSO requirement | Baserow single sign-on needs an activated Advanced or Enterprise license, plus identity provider configuration and user testing | Confirm the identity provider and user count early, and price the license as a separate line item |
| Residency and hosting | Self-hosting in your own or an EU data center means provisioning servers, external PostgreSQL, backups and patching | Reuse existing hosting standards and agree the backup and restore test scope in writing |
| Paid Baserow license | Premium, Advanced and Enterprise are per-instance licenses that recur, and an instance can use only one license type | Choose the license type from the features you need, and ask the vendor for current terms |
| Testing and training | Users need checks on filters, sorts, permissions and imported attachments, plus training on new views and forms | Use a short acceptance script per base and record a walkthrough for each team |
| Support retainers | Post-cutover fixes, upgrades and monitoring are ongoing services, separate from the one-time migration work | Decide during scoping whether support is needed, and set a defined handover date |
What usually goes wrong and how to prevent it
Most Airtable-to-Baserow problems come from what the importer does not carry over, not from the copy itself. The cards below cover the failure points we see most often, each with a check you can run before users depend on the new base.
Missed formula and rollup rebuilds
The Baserow importer does not copy formula, lookup or rollup fields, so those columns arrive empty or absent. Inventory every computed field in each base before import, then rebuild each one in Baserow and compare outputs against Airtable for a sample of rows. Keep a test matrix that covers blank inputs, date boundaries, and rows linked to several records. Until the matrix passes, report-driven decisions should stay on the Airtable base.
Attachments that fail or lose linkage
Attachments are copied from the public share link, but a copy can fail silently or land on a record without its original file name. Compare attachment counts per field against Airtable, and open a sample of files from each table to confirm they render. Check that files referenced in other tools, such as links in tickets or emails, still resolve to the new record. Plan for the Airtable attachment links expiring, so the copy is run while the source base is still reachable.
Broken links between tables
Linked-record fields are rebuilt during import, but relationships that depend on lookups or on rows that were filtered out can point to the wrong row or to nothing. Run a reconciliation of record counts per table and a check that each link field has the same number of linked pairs as the source. Spot-check parent and child records in both directions, especially where a table links to itself or to a table that was imported later.
Users losing access after cutover
Airtable collaborators, interface viewers and shared-view permissions do not transfer as Baserow roles, so people who used to see a base may find it empty or locked. Before cutover, export a list of every collaborator and their access level from Airtable, then recreate workspace membership and table-level permissions in Baserow and test each role with a real account. Confirm which role-based permissions your license tier includes, since these are listed for the Advanced cloud plan and self-hosted license types differ.
Automations that stop without notice
Airtable automations are not imported, so scheduled reminders, status-change notifications and sync jobs simply stop once the Airtable base is retired or edited. Build an inventory of every automation with its trigger, action and owner, and assign each one a Baserow automation, a webhook or an external workflow. Run each replacement against test records and confirm it fires before the old automation is switched off, so no one discovers the gap from a missed deadline.
Shared links left open after the move
Public share links used for the import, and any public Airtable share links used by teams, remain valid after the data has moved, which keeps a second copy of the data reachable. Revoke the Airtable share links and personal access tokens used for the import, and confirm the Baserow instance itself is not exposed through public links to tables that should be private. Also freeze edits in Airtable during the final sync so no changes land in the old base after the copy is taken.
Questions teams ask before moving from Airtable to Baserow
How much does moving from Airtable to Baserow cost?
Most of the cost is labor, plus the hosting and license choices you make. Baserow's non-premium features are under the MIT License, so the software has no license fee for the community features. Recurring costs include the servers or cloud accounts that run Baserow, backups, upgrades, monitoring, and any paid Baserow license you need for features such as single sign-on. One-time costs include planning, importing, rebuilding formulas, automations and interfaces, and testing. For comparison, the Airtable pricing page lists Team at $20 and Business at $45 per user per month billed annually. Ask any provider for a fixed quote tied to a written scope that lists your bases, formula fields, automations and interfaces.
How long does an Airtable to Baserow migration take?
The duration depends on how many bases you have, how many formula, lookup and rollup fields they contain, and how many automations and interfaces depend on them. The Baserow importer works one base at a time from a public share link, so the number of bases sets the number of import runs. The import itself is usually the quickest step. Rebuilding the calculated fields, automations and interfaces, then checking every view against the Airtable original, takes most of the time. Start with one pilot base to measure the effort, and ask for a timeline in the written scope before work begins.
What does our internal team need to run the migration?
You need four skills. First, someone who knows the Airtable bases well enough to document their formulas, linked records and views. Second, a platform administrator who can deploy Baserow with Docker Compose or Kubernetes with Helm, as the installation documentation describes. Third, a database administrator, because the baserow/baserow image runs an internal PostgreSQL and Redis by default, while Baserow highly recommends an external PostgreSQL for production. Fourth, an identity administrator if you plan to use single sign-on. A business owner should also sign off on each migrated base before the old one is retired.
Can our own team migrate from Airtable to Baserow without help?
A capable team can handle a small migration alone. If your bases hold a few tables, few formulas and no automations, an administrator can run the importer and check the results. The work gets harder when bases contain many lookups and rollups, depend on interfaces or automations, hold regulated data, or need hardening, backups and documented evidence for an assessment. The importer needs a public share link, so treat that link as exposed data. Keep it open only for the import window, then revoke it and confirm the data is no longer reachable from outside.
What does the Baserow Airtable importer leave behind?
The importer copies tables, records, attachments, field types, relationships, and grid views with their filters and sorts. It does not copy formula, lookup, rollup or collaborator fields, automations, interfaces, comments or revision history. Plan for these items before cutover. Recreate each formula and lookup in Baserow's formula syntax, rebuild collaborator fields as user or text fields, and rebuild automations and interfaces as Baserow automations and application builder pages. Export comments and revision history from Airtable separately if your records or audit needs depend on them. Check each rebuilt field against sample records from the original base.
Does Baserow single sign-on require a paid license?
Yes. Baserow's single sign-on, which covers SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect, is available on the Advanced and Enterprise plans with an activated license. Self-hosted Baserow offers three paid license types: Premium, Advanced and Enterprise. An instance can run only one license type, so check which type fits your user count and access model before you plan the rollout. Current terms can change, so confirm them on Baserow's self-hosted license page and pricing page before you commit to a plan.
How does self-hosting Baserow handle data residency compared with Airtable?
Airtable offers data residency in Europe or Australia only on its Enterprise Scale plan, and base and workspace metadata, user and authentication data stay in US data centers regardless of region. On self-hosted Baserow, you choose the data center, and base data, metadata and user accounts stay on systems you operate. Confirm the parts that can still leave your jurisdiction: backup targets, email relays, log shipping, and any external services you connect. Your compliance lead should record where each component runs. DeployOpen prepares these controls and evidence, but independent auditors issue any assessment report.
When should we bring in an implementation partner for an Airtable to Baserow move?
Bring in a partner when the migration has many bases, deep formula and automation dependencies, regulated data, or a deadline that your team cannot absorb alongside daily work. A partner can also help when you need hardening, backups, upgrades and documentation after cutover. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure. For this migration, we agree the base-by-base scope in writing first, then run the Baserow import, rebuild the parts the importer does not carry over, and hand the instance to your team with documentation.
How we scope
- Inventory every Airtable base, table, view and attachment to decide which bases move first.
- List formula, lookup, rollup, automation and interface fields that must be rebuilt by hand.
- Agree the target Baserow deployment, license type and single sign-on approach in the written scope.
- Confirm which users, external collaborators and integrations need access after cutover.
How we build
- Stand up Baserow in your own cloud account, data center or air-gapped network with external PostgreSQL.
- Run the Airtable importer from public share links, one base at a time, and check row and attachment counts.
- Recreate formula, lookup and rollup logic in Baserow fields and test results against the Airtable originals.
- Rebuild automations and interfaces, then test triggers and permissions before users switch over.
How we hand over
- Document the import steps, field mappings, known gaps and rebuilt logic for each migrated base.
- Walk your administrators through backups, user management and upgrades on the running instance.
- Provide a cutover checklist covering retired share links, revoked Airtable access and attachment checks.
- Deliver the written record your compliance reviewers can use when assessing the new system.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any provider for written scope, named deliverables and the exact effort for each rebuilt feature.
- Confirm with Baserow which features need a Premium, Advanced or Enterprise license when self-hosted.
- Plan how upgrades to new Baserow releases will be tested against your rebuilt bases.
