Migrate from Airtable to Microsoft Project

Each Airtable Base becomes one Microsoft Project Plan (.mpp or Project for the Web). We extract the base name and metadata (created date, last modified) as Project properties. If multiple Bases represent phases of the same program, we discuss a multi-phase Project structure with master/subprojects during scoping. Project Plan 1 ($10/user/month) is the minimum for cloud-hosted; Project Plan 3 ($30/user/month) adds resource management and baselines required for most migrations.

Airtable Tables containing project task records map to Microsoft Project Tasks. If the Airtable base uses multiple Tables to represent different task types (e.g., one Table for Phases, one for Deliverables, one for Risks), we flatten these into a single task list within the Project Plan, preserving the parent-child hierarchy through a Summary Task grouping rather than separate Tables. We flag any Table with no date or duration fields and discuss whether its records represent tasks or supporting reference data.

Linked record relationships between Airtable Tables are the most complex migration element. We extract linked-record arrays, identify the relationship type, and map them to Microsoft Project dependency types: most cross-table predecessor-successor links become Finish-to-Start (FS) dependencies. Start-to-Start (SS) is used when two tasks begin simultaneously. We preserve the linked-record field name as the dependency's predecessor task name and flag any circular dependencies detected during export. Teams using Airtable's Timeline view for Gantt visualization receive a dependency graph that mirrors their existing linked-record structure in native Project dependencies.

Standard Airtable field types map directly to Microsoft Project task fields (Name, Start, Finish, Duration, Percent Complete, Priority, Notes) or to Project custom fields (Text1-30, Number1-20, Cost1-10, Flag1-20) using the closest equivalent type. Single-select fields map to Project's flag or text custom fields; multi-select fields map to multi-value text custom fields. We preserve field descriptions and option lists as part of the custom field definition.

Airtable formula fields compute server-side and the API returns only the rendered result. During migration, formula results land as static text or number values in Project's custom fields with no live recalculation. We flag every formula field in the scoping report, extract the formula definition (table name, field references, operators), and document it for rebuild as a Project custom field formula if the destination Project Plan supports it (Project Plan 3 and above). Cross-table lookup formulas are the highest-risk items because the lookup logic cannot be expressed in a single Project custom field.

Airtable attachment fields store files on Airtable's CDN and export as signed URLs. We collect all attachment URLs into a manifest CSV mapping each record to its attachment filenames and URLs, then attach the manifest to the Project Plan as a hyperlink custom field or deliver it alongside the migration package. Files larger than 50 MB (Airtable's per-file limit) require manual re-upload to the destination's file management system. We do not automatically re-upload files during migration.

Airtable's multiple view types are presentation-layer constructs with no exportable equivalent in Microsoft Project. We export the view filter, sort, grouping, and column order as a written configuration document. Kanban board groupings map conceptually to Project's grouping by Summary Task or Resource; Calendar view date fields map to task Start/Finish dates in Project. The customer's PM team uses the configuration document to set up equivalent views in Project.

Airtable automations are internal workflow constructs with no public API endpoint. We cannot migrate them. We deliver an automation audit document listing every active automation with its trigger, conditions, actions, and a recommended Microsoft Power Automate equivalent. Power Automate handles cross-application triggers (e.g., when a Project task reaches a certain status, update a SharePoint list or send a Teams notification). The customer's project admin rebuilds automations post-migration using the audit as a blueprint.

Airtable Interfaces and Portals are custom UI builders with no API export path. Teams using Airtable Interfaces for client-facing project status portals must rebuild these in Microsoft SharePoint, Power Apps, or a third-party project portal tool. We document every Interface's layout, field display, and filter logic in the scoping report so nothing is lost in the handoff.

Airtable workspace-level and base-level permission settings do not map to a native Microsoft Project permission model. We document the permission hierarchy (workspace > base > table > field) as a written access matrix. For Project for the Web destinations, we recommend using Microsoft 365 Groups and SharePoint permissions to replicate the closest equivalent access model. For Project desktop (Standard or Professional 2024), permissions are managed at the file level, which requires separate admin handling.