Migrating from Notion, Monday, or Smartsheet to Airtable: A Mapping Playbook

Most Airtable migration guides assume you are coming from a spreadsheet. Plenty of teams are not. They are coming from Notion, Monday.com, Smartsheet, ClickUp, or Asana — tools that already have a concept of items, relations, statuses, and views, and that therefore break in more interesting ways when you move them. This tutorial is a mapping playbook: how to read the structure you already have, what translates cleanly into Airtable, what has no equivalent, and the order of operations that keeps the team working while you switch.

If your source really is a spreadsheet, start with our field-by-field Google Sheets migration tutorial instead and come back here for the rollout section.

Step 0: decide what you are migrating, and what you are leaving behind

Every migration has three buckets. Sort the source into them before touching Airtable.

1. Live operational data. Open projects, active clients, current inventory. This must arrive complete and correct.
2. Reference data. Clients, staff, products, categories. Usually small, usually the thing that becomes your linked-record tables.
3. History and noise. Closed items from three years ago, abandoned boards, "test" databases, duplicated personal copies.

The single biggest cause of migrations that stall is treating bucket 3 like bucket 1. Export history to CSV, park it in cold storage or a read-only archive base, and migrate the live set. You can always import the archive later; you cannot get back the six weeks spent reconciling records nobody will ever open.

Step 1: map the source's structure to Airtable's

The vocabulary differs by tool, but the concepts line up more than they appear to.

Source concept	Airtable equivalent	Watch out for
Notion database	Table	Notion pages carry rich body content; Airtable long text is markdown-ish, not a page tree
Notion relation / rollup	Linked record / rollup	Notion relations may be one-way; Airtable links are always symmetrical
Notion sub-pages inside a row	Attachment, long text, or a child table	There is no nested-page equivalent — decide per property
Monday board	Table	One board per table, but boards used as "groups of projects" often collapse into one table plus a select field
Monday group	Single select or view grouping	Groups are presentation in Airtable, not structure
Monday subitem	Child table linked to the parent	Subitems have their own columns; they need their own table
Monday connect-boards column	Linked record	Mirror columns become lookups
Smartsheet sheet	Table	Hierarchical parent/child rows need an explicit self-link or a parent table
Smartsheet cell-level formula	Field formula	Airtable formulas are per-field, not per-cell — the one-off overrides must become data
ClickUp / Asana task	Record	Custom fields map cleanly; task dependencies do not
Assignee (people field)	Collaborator field or linked People table	Collaborator fields require a base seat per person
Status column	Single select	Normalise wording now; you will never have a better chance
Comments / activity feed	Not migratable in practice	Export to CSV and attach, or accept the loss and say so out loud
Automations / recipes	Airtable automations	Rebuild, do not translate — see below

Write this table out for your own source before you build anything. Two columns: "source thing", "Airtable thing". Any row where the second column says "nothing" is a decision that needs a human, and it is cheaper to make it on paper.

Step 2: build the schema first, import second

Importing a CSV into a fresh table and then fixing types is how you end up with eleven single-line-text fields holding dates. Create the tables and fields deliberately:

1. Reference tables first. Clients, People, Products. Give each a meaningful primary field — a name or code, never an auto-number, because the primary field is what every linked record displays.
2. Then the operational table. Projects or Tasks, with correct field types: date for dates, single select for statuses, number with the right precision for amounts, currency where relevant.
3. Links last. Add linked-record fields once both sides exist.

Keep a temporary Legacy ID single-line-text field on every table. Fill it with the source system's row ID or URL. It is how you rebuild relationships after import, how you re-run a partial import without duplicating, and how you answer "where did this come from?" three months later. Hide it from views when you are done; do not delete it until the source system is switched off.

Step 3: export, clean, import

Export as CSV per table (Notion: export the database as CSV; Monday: export board to Excel then save as CSV; Smartsheet and ClickUp both export per sheet/list). Then clean the file before import:

• Split multi-value columns. Notion multi-selects and Monday tags export as comma-separated strings. Airtable will import them into a multiple-select field if the field already exists as multiple select, so create the field first.
• Normalise dates to ISO. 2026-03-14 imports predictably; 14/03/2026 depends on locale and will silently produce March or November.
• Strip currency symbols and thousands separators from anything destined for a number field.
• Collapse status synonyms. In progress, In Progress, WIP, and Doing are four select options unless you fix them in the CSV.
• Decide on blank vs zero. Empty is not the same as 0 in rollups and formulas.

Import with Airtable's CSV import extension or paste into an existing table with matching columns, mapping each CSV column to an existing field rather than letting the importer create new ones.

Step 4: rebuild relationships from Legacy IDs

Links do not come across in a CSV; you get a text column containing the related item's name or ID. Two reliable ways to convert it:

• Paste-and-match. If the text column holds the exact primary-field value of the target table, copy it into the linked-record field. Airtable matches existing records by primary field and links them. Anything unmatched creates a new record, so check for typos and trailing spaces first, and work on a duplicated base if you are nervous.
• Script it. For anything with ambiguity, an automation script or a one-off script extension that builds a map of Legacy ID → record ID and then patches the link fields in batches of 50 is safer and re-runnable. Our Airtable scripting guide covers the batching pattern.

Verify with counts, not vibes: number of records where the link is empty should match the number you expected to be empty. Build a temporary grid view filtered to "link is empty" and read it.

Step 5: rebuild automations as automations, not as translations

Resist porting recipes one-for-one. Source automations accumulate — half of them fire into a Slack channel nobody reads, and several exist only to patch a structural problem your new schema no longer has. Instead:

1. List every automation in the source with its trigger, its action, and its actual business purpose.
2. Delete the ones whose purpose is "make up for a missing field" or "nobody ever read this".
3. Rebuild the survivors natively, one at a time, testing each with a real record.
4. Make them observable from the start — see automations that fail silently for run logs and failure alerts.

Same logic for views: rebuild the four views people actually open, and build the rest on request. Migrating 60 views is how you discover that 50 of them were somebody's abandoned filter.

Step 6: interfaces replace the source's UI

This is the step teams forget to budget for, and it is the one that decides whether anyone adopts the new base. In Notion or Monday, the database is the interface. In Airtable, the base is the back end and Interface Designer is the front end. Before go-live, build:

• One interface per role (delivery, sales, leadership), not one per table.
• A record-detail layout that shows the fields that role edits, and hides the rest.
• A list or calendar of "my work", filtered to the current collaborator.

Do this and the migration feels like an upgrade. Skip it and people will say Airtable is "just a spreadsheet" and drift back to the old tool.

Step 7: cut over without a data fork

The dangerous window is when both systems are writable. Keep it short and explicit:

1. Freeze. Announce a cutover time. Set the source to read-only if the tool allows it; if not, rename boards to ARCHIVE – do not edit.
2. Final delta import. Re-export only records changed since your test import and import them, matched on Legacy ID so nothing duplicates.
3. Reconcile. Compare record counts per table and total value of any money column. Two numbers, five minutes, enormous peace of mind.
4. Switch. Move permissions, send the interface links, and post a short "here is where things live now" note.
5. Keep the source readable for 30 days, then export a final archive and cancel the seats. Cancelling early is how you find out what you missed the hard way.

Step 8: the week after

Run a 30-minute session per team on the interfaces, not on the base. Set up a feedback table — an Airtable form linked to a Migration feedback table — so complaints arrive as records instead of as messages to whoever is nearest. Expect a fortnight of small fixes: a missing select option, a view sorted the wrong way, one formula that rounds differently from the old tool. Fix them fast; early responsiveness is most of what adoption is made of.

A short pre-flight checklist

• Mapping table written, with "nothing" rows resolved
• Reference tables built with sensible primary fields
• Legacy ID on every table
• CSVs cleaned: ISO dates, split multi-values, normalised statuses
• Links rebuilt and empty-link counts verified
• Only the automations that matter, rebuilt and monitored
• One interface per role, tested by someone from that role
• Seat and permission plan costed — see the cost audit playbook
• Cutover time announced, delta import and reconciliation rehearsed on a copy
• Source kept read-only for 30 days, then archived

When to bring in help

Migrations go wrong at the joins: subitems with their own fields, hierarchies that are really trees, six boards that should be one table with a select, or a source database whose formulas encode business rules nobody wrote down. If the mapping table has more than a few "nothing" rows, that is a design job before it is an import job.

BaseBrainers runs exactly these projects as data migration to Airtable engagements, and picks up stalled ones through our Airtable project rescue service. Send us your mapping table and we will tell you where it will hurt — get in touch.