Migrate your Airtable data

Bases are the top-level container in Airtable. Each base has its own API endpoint and rate limit of 5 req/s. We export bases one at a time, preserving the base name and settings. Base-level permissions and sharing links are not carried forward automatically in a migration.

Tables map directly to destination objects or flat tables. We extract the full table list from the base schema and create matching destination tables before populating records. Table-level permissions do not transfer and must be reconfigured at the destination.

Records are the core data unit. We paginate through them using Airtable's offset-based pagination (100 records per page), respecting the 5 req/s rate limit per base. Deleted or archived records require an explicit include flag since they are excluded by default.

Standard field types—text, number, currency, date, checkbox, single/multi select, URL, email, phone, rating, rollup, count, and lookup—map cleanly to their destination equivalents. We preserve field configuration including required flags and default values.

Attachment fields export as URL strings pointing to Airtable's CDN, not as files. We flag these and recommend a separate attachment bundle export. Collaborator fields export as user email/name pairs and require user provisioning at the destination. Formula fields lose their definitions on export and land as plain text values.

Views (Grid, Kanban, Calendar, Gallery, Timeline, Gantt) are Airtable's presentation layer and do not exist in most destination platforms. We export view filters, sorts, groupings, and column order as metadata notes. Users must rebuild views from scratch at the destination.

Workspaces group bases and set high-level permission boundaries. Airtable's workspace model varies by plan. We map Workspace structure to the closest organizational unit available at the destination, typically folders or projects, noting that nested workspace hierarchies flatten in most migrations.

Airtable automations (triggers and actions built inside Airtable) are not accessible via the public API. We do not migrate automations. Teams should audit their automations before migration and re-implement critical ones using the destination platform's native automation tools or an integration layer like Zapier.

Airtable Interfaces and Portals are front-end presentation layers with no exportable data through the API. These are discarded in any migration out of Airtable. Client-facing portals must be rebuilt in the destination tool or a dedicated frontend platform.

Attachment files are stored on Airtable's CDN and referenced by signed URLs. During export, we extract all attachment URLs and bundle them for download. Files must be re-uploaded to the destination's storage. We flag any attachment that exceeds 50 MB (Airtable's per-file limit) for special handling.

Linked records represent relationships between tables and export as arrays of record IDs. When the destination platform does not have a native linked-record concept, we denormalize these into stored ID fields or comma-separated text. We reconstruct foreign-key relationships in the destination where the data model supports it.

Custom fields are the norm in Airtable, not the exception. Every field beyond the standard set is user-defined. We preserve field names, types, options (for select fields), and descriptions. Cross-base custom fields require individual field-level mapping.