Migrate from Airtable to Asana

Airtable bases are top-level data containers. We map each base to an Asana Portfolio (for org-level visibility) or to a dedicated Workspace/Team depending on how the customer's Airtable workspace is structured. Base-level permissions map to Asana team membership and portfolio-level sharing settings. If multiple bases represent distinct business functions, they map to multiple Asana projects organized under a Portfolio or separate Teams.

Airtable tables map to Asana projects. During scoping, we evaluate whether a table functions as a flat task list (map directly to an Asana project with each record as a task) or as a relational entity (parent table becomes a project; child linked records require dependency or subtask resolution). If a table has no natural task-oriented analog (reference data, configuration tables), we document it for the admin to recreate as custom fields or drop.

Airtable records map to Asana tasks within the corresponding project. Standard fields (text, number, date, checkbox, single select, URL, email, phone) map to their Asana task field equivalents. Record names map to task names. Multi-select fields map to Asana tags. Records without a natural task assignment (lookup-only or archive records) may be imported as tasks with no assignee or as subtasks with no due date, at the customer's discretion.

Airtable linked records represent relationships between tables that have no direct Asana equivalent. We evaluate three strategies during scoping: (1) Denormalize linked record IDs into a multi-line text field on the task for admin reference, (2) Create Asana task dependencies where the linked record is also a task in the migration scope, or (3) Document the relationship as a rebuild item for Asana Rules if automation is desired. Strategy selection depends on whether the linked table is also migrated and how the relationship is used operationally.

Airtable lookup fields (pulling a value from a linked record) and rollup fields (aggregating linked record values) cannot retain their live calculation logic in Asana. We migrate the current evaluated result as a static custom field value. Cross-table rollups require documentation of the original formula and manual rebuild as Asana custom fields or reporting dimensions post-migration. We flag all lookup and rollup fields in the scoping report with their source table and field references.

Airtable formula field definitions are not accessible via the API. Only the evaluated result migrates as a static value. We flag every formula field in the scoping report with its field name, formula logic (if visible in field descriptions), and the evaluated field type so the customer can decide whether to rebuild the logic in Asana as a custom formula or accept the static value. Complex multi-field formulas with date math or conditional logic are documented as rebuild items.

Airtable stores attachments on its CDN and the API returns a signed URL, not the file binary. We collect all attachment URLs during export and generate a manifest CSV mapping record names to attachment filenames and URLs. We do not automatically re-upload files to Asana due to CDN access constraints and file-size handling. The customer's team downloads the attachment bundle and re-uploads files to the relevant tasks. Files over 50 MB require additional coordination as they may exceed Asana's per-file limit.

Airtable single-select and multi-select options migrate to Asana custom fields of type Enum or Multi-Enum. Option labels and colors are preserved where possible. If an Airtable select field uses dynamic options (synced from another table), we document the source relationship and recommend rebuilding as an Asana rule or accepting the migrated static options.

Airtable date fields map to Asana task due dates. Airtable datetime fields map to Asana due dates with the time component preserved in the task notes or a custom datetime field. Multiple date fields in a single table require mapping decisions: the primary date field becomes Due Date; secondary date fields become custom fields. Date fields used for kanban grouping require review as Asana does not have a native date-grouped board view.

Airtable collaborator fields store user email and name pairs. We extract collaborator values during export and map them to Asana task Assignee by email match against the Asana workspace. Users without a matching Asana account are flagged in the reconciliation report for the admin to provision before the assignee phase of migration runs.

Airtable workspaces group bases and set permission boundaries. We map workspace structure to Asana's organizational hierarchy: Organization at the top level, Teams as the primary grouping unit, and projects nested under teams. Workspace-level admin roles map to Asana Organization-level admin roles if the destination is an Asana organization; workspace members map to team members.

Airtable view configurations (column order, filters, sorts, groupings) do not have a direct export path. We document the view settings in the scoping report so the admin can recreate them in Asana's List, Board, Calendar, and Timeline views. Kanban views in Airtable map most directly to Asana Board view; grid views map to List view; calendar views map to Calendar view.