Migrate from Airtable to monday Work Management

Each Airtable Base maps to a monday.com Workspace. Workspace-level settings—member access, guest permissions, and notification preferences—require manual configuration in monday.com post-import. Airtable's Workspace-level roles (owner, editor, commenter, viewer) have no direct equivalent; monday.com Workspace roles are Admin, Member, and Guest, which we map during scoping.

Each Airtable Table maps to a monday.com Board. We create the board in monday.com during configuration, map Airtable field types to monday.com column types (text to Text, number to Numbers, date to Date, single select to Status, checkbox to Checkbox, URL to Link, email to Email), and import records as Items. Boards with multiple record types (e.g., a table containing both Projects and Tasks) may require board splitting if monday.com's single-board-group structure cannot represent the distinction cleanly.

Airtable Records migrate as monday.com Items within their target Board. We set the Item name from the Airtable primary field, and populate other columns from standard field types. Item creation order is preserved from Airtable's sort order unless a different ordering is specified during scoping. Records in Airtable's Archive are optionally migrated as archived monday.com Items based on customer preference.

Airtable's linked records represent relationships between Tables. Since monday.com Connect Boards link items at the item level without foreign-key enforcement, we denormalize linked record arrays into stored text columns (comma-separated record IDs or names) on the target Item, preserving the relationship data as readable values. If the customer requires a native monday.com linking experience, we configure Connect Board columns and document which Item IDs link to which boards for manual connection post-migration.

Airtable formula fields export as their rendered result value only—the formula definition is not accessible via API. Every formula field is flagged in the scoping report and migrated as a static text or number column with no live recalculation. For formula columns that represent business-critical calculations, we document the original formula logic in a rebuild guide so the customer's monday.com admin can re-implement them in monday.com Formula columns (Pro plan) or a separate calculation layer. Cross-table reference formulas require particular attention: we provide a schema map of all referenced tables and fields.

Airtable lookup and rollup fields pull data from linked records and compute aggregates. Neither construct has a monday.com equivalent. We migrate the last-known computed value as a static number or text column and document the lookup/rollup source fields and aggregation logic for manual rebuild in monday.com using Formula columns (Pro) or a reporting layer. This is one of the highest-effort field-type migrations because it requires reconstructing the relationship chain in plain-language documentation.

Airtable attachment fields store files on Airtable's CDN and the API returns a signed URL, not the file binary. We extract all attachment URLs and produce a manifest CSV mapping each Item to its attachment filenames and URLs. Files are not automatically re-uploaded to monday.com. The customer downloads the attachment bundle and manually uploads files to monday.com's File column, or uses a separate file transfer process. Files exceeding 50 MB (Airtable's per-file limit) are flagged separately.

Airtable collaborator fields store user email and name pairs. We map these to monday.com People columns by resolving email against the monday.com Workspace members list. Collaborators in Airtable who do not have a monday.com account are flagged and either invited as Workspace members or mapped to a text column with the original name value preserved.

Airtable Views are presentation layers with no API export. We document the view configuration for each Table—column order, filters, sorts, groupings, and view type—as a written specification. In monday.com, the equivalent is achieved through board view toggles (Board, Group, Chart, Timeline, Calendar, Map) and Saved Views. The customer's admin rebuilds the view configuration post-migration based on the documentation.

Airtable Workspaces group Bases and set top-level permission boundaries. We map Workspace structure to monday.com Workspace structure. Airtable workspace roles (owner, editor) map to monday.com Admin and Member roles. If the customer uses multiple Airtable Workspaces, we discuss whether to consolidate into a single monday.com Workspace or preserve separation.

Airtable Automations are not accessible via the public API and cannot be migrated. We produce an Automation Audit document listing every Airtable Automation with its trigger, conditions, actions, and frequency. The customer's monday.com admin uses this document to rebuild equivalent automations using monday.com's native recipe automation builder (Standard and above). Automations that involve cross-table triggers are the most complex to rebuild because monday.com's automation scope is board-level, not workspace-level.

Airtable Interfaces (the custom UI builder) and client-facing Portals have no API export path and are not migratable. We deliver an Interface Audit document describing each Interface's purpose, screens, and field layouts. The customer rebuilds Interfaces using monday.com's Dashboard builder or a separate front-end tool. Client-facing portals require a replacement solution such as monday.com's Guest access, a third-party portal tool, or a custom-built replacement.