Migrate from Airtable to Trello

Each Airtable base maps to a Trello board (for project-management-oriented bases) or a workspace containing multiple boards (for thematic groupings). We determine the mapping during scoping: if the base has a single primary table driving a kanban workflow, it becomes one board. If the base has multiple co-equal tables, we discuss splitting into separate boards or using a single board with list-name prefixes to distinguish record types. Workspace names derive from the Airtable base name and any workspace grouping metadata.

Airtable tables map to Trello boards, with each distinct status or stage value from the table becoming a Trello list. We extract the full list of status/select field values (or group-by configurations from grid views) to build the initial list structure. If the table has no logical status field, we create default lists (To Do, In Progress, Done) and flag this for customer confirmation. Tables with fewer than 10 distinct status values are straightforward; tables with 20+ status values may require list consolidation rules documented in the scope.

Each Airtable record becomes one Trello card on the appropriate board and list. The record name field maps to the card title. We preserve the record ID in a custom field on the card (using Trello's native custom fields on Premium/Enterprise or via Butler for Standard) so that the migration is auditable and the original Airtable record is referenceable post-migration. Archived or deleted Airtable records are flagged in the scope and optionally moved to a Trello Archive board.

Standard Airtable field types map directly to Trello card attributes or custom fields. Single-line text becomes the card title (if it's the primary field) or a custom text field. Numbers, dates, URLs, and emails map to Trello custom fields of the matching type on Business and Enterprise; on Standard, these store as text in the card description with a label prefix. We preserve the original field name as the custom field name during mapping.

Airtable single-select fields map to Trello labels if the number of options is 10 or fewer (Trello labels are limited to colored badges; text is not directly visible on the card without clicking). For options above 10 or when the values are lengthy, we store the value in a checklist item with a fixed name (e.g., '[Field Name]: [value]') appended to every card. The customer chooses the strategy during scoping.

Airtable multi-select fields map to multiple Trello labels (one label per option, each stored with the option text as the label name) on Business and Enterprise. On Standard, where custom labels beyond color are limited, we use multiple checklist items or append all selected values to the card description. We flag any multi-select field with more than 20 options for consolidation discussion.

Airtable checkbox fields map to a single checklist item on the card with a fixed name matching the field label (e.g., 'Requires review: yes'). The checklist item is marked complete if the checkbox was checked in Airtable. Alternatively, if the Trello board uses label colors to represent boolean states, we create a label (e.g., 'Reviewed') and apply it to the card.

Airtable date fields map to Trello card due dates if the field name suggests a deadline or target date (e.g., 'Due Date', 'Deadline', 'Target Date'). Non-deadline dates (e.g., 'Created Date', 'Start Date') map to Trello custom date fields on Premium/Enterprise or are appended to the card description. We preserve the original timezone context as a note in the custom field.

Airtable collaborator fields map to Trello card members. We resolve the Airtable user email to the Trello member on the destination board (member must exist on the Trello board before migration; we generate a missing-member report during scoping). Multiple collaborator fields on one record result in multiple members being added to the card. Collaborator fields with more than 10 members per record are flagged for split discussion.

Airtable attachment fields do not produce file binaries through the API—only CDN URLs. We extract all attachment metadata (filename, URL, file size, MIME type) and produce a manifest CSV mapping each card to its attachment list. We do not re-upload files to Trello automatically. The customer downloads the attachment bundle separately and re-uploads files to cards manually or via a Trello Power-Up integration with a cloud storage provider (Google Drive, Dropbox, OneDrive). This is a disclosed limitation of all Airtable-to-any migrations.

Airtable rating fields (star ratings, emoji scales) map to Trello labels with color-coded intensity (e.g., 1 star = yellow, 5 stars = red) on boards using labels for this purpose. On Premium/Enterprise with custom fields, we use a custom number field. The rating scale (1-5, 1-3, emoji) is preserved in the field metadata.

Airtable formula fields are computed server-side and the API returns only the rendered result, not the formula definition. During migration, formula field values land as static text on the Trello card with no live recalculation. We flag every formula field in the scoping report, describe the formula logic (e.g., 'CONCATENATE({Name}, " - ", {Status})') so the customer's Trello admin can rebuild it as a Butler rule or custom field formula on Premium/Enterprise. Cross-table reference formulas are flagged as high-complexity.

Airtable lookup and rollup fields resolve linked-record relationships at read time. The API returns only the computed value. We denormalize these into stored text on the card (e.g., a lookup field showing the related company's name appears as plain text on the card). The original linked-record relationship is not preserved as a live link; it becomes a text annotation. We document each lookup/rollup in the scoping report for the customer to decide whether to rebuild as a Trello Power-Up integration (e.g., Unito, Plashboard) post-migration.

Linked record fields (arrays of record IDs referencing another table) have no native equivalent in Trello. We denormalize them by extracting the primary field value (record name) from the linked records and storing that text on the card. If the linked table also migrates to Trello as a separate board, we add a text note indicating the linked board and card name for manual cross-referencing. Multi-level linked record chains (A links to B links to C) are flagged for simplification discussion because Trello cannot represent this structure.

Airtable views are presentation-layer constructs with no Trello API equivalent. We extract the view list from the base schema, document the filter, sort, grouping, and column-order configuration for each view, and deliver this as a views inventory. The primary kanban view becomes the default Trello board list structure. Other view types (calendar, gallery, Gantt) cannot be reproduced natively in Trello without a Power-Up and are documented as requiring a separate tool or rebuild.

Airtable automations (trigger/action workflows built inside the product) are not accessible via the public API. We produce an automation audit document listing every active automation with its trigger, conditions, and actions in plain language. The customer uses this to rebuild equivalent logic in Trello Butler (included on Business and Enterprise; Power-Up on lower tiers) or a third-party automation tool. We do not rebuild automations as part of the migration scope.

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, custom dashboards, and branded interfaces built in Airtable Interfaces must be rebuilt from scratch in Trello or an alternative front-end tool. We document the existence of any Interfaces in the scoping report so the customer is aware of the full scope of loss.

Airtable workspaces group bases and set permission boundaries. We map workspace structure to Trello Teams (the top-level organizational unit in Trello). Workspace-level permissions map to Trello team membership levels (admin, member, observer) where feasible, though Trello's permission model is less granular than Airtable's base-level and field-level sharing. We flag any workspace with permissions that cannot be exactly replicated in Trello.