Migrating From Spreadsheets to Airtable

Don't Copy the Spreadsheet

The instinct is to import the sheet, get one table that looks the same, and call it migrated. That produces Airtable behaving as an expensive spreadsheet, and every automation you build on top fights the structure.

Spreadsheets encode relationships by repeating data. The same client's name and phone number appear on forty rows because each row is a job. That repetition is the workaround for a flat file having no other way to express "these jobs belong to this client".

Airtable can express it properly, so the migration is a restructuring rather than a copy. Do that first and the automation afterwards becomes straightforward. Skip it and you carry every spreadsheet problem into a new tool.

Find Your Real Entities

Read your sheet and ask what things it's actually about. Usually three or four.

A jobs sheet is typically about clients, jobs, and sometimes staff and invoices. Each becomes a table. Each client exists once, each job once, and jobs link to clients rather than repeating their details.

The test: if you changed a client's phone number, how many places would you edit? One, if the structure is right. Forty, if you copied the sheet.

Do this on paper before touching Airtable. It takes half an hour and it's the whole migration.

Clean Before You Import, Not After

Every spreadsheet has the same problems and they're much easier to fix before the data is spread across linked tables.

The same client under three spellings. Phone numbers in four formats. Dates as text in some rows. Blank rows and a summary row at the bottom that will import as a record. Trailing spaces everywhere.

Normalise all of it in the sheet first: trim whitespace, standardise phones and dates, and pick one canonical spelling per client. Then deduplicate, because importing duplicates means creating duplicate links afterwards, and untangling that is genuinely painful. Why your spreadsheet sync keeps creating duplicates covers picking a key that holds.

The Import Order That Works

Import the entity tables first, then the tables that link to them.

Clients before jobs. Staff before assignments. Products before orders. You cannot link a job to a client who doesn't exist yet, and doing it the other way round means a second pass to fix every link.

Keep your original spreadsheet row identifier as a field during migration. It gives you something to match on when you import the linked tables, and something to verify against afterwards. Delete it once you've confirmed everything landed.

Then link records by matching on your key field, not on names, for the reasons in Airtable linked records in automations.

Set Field Types Deliberately

Airtable guesses types on import and guesses wrong often enough to matter.

Dates imported as text sort alphabetically, which means March comes before May and also before February. Numbers imported as text break every calculation. Single-select fields created from messy data give you forty options where you wanted five.

Go through each field after import and set the type explicitly. Fix the select options at the same time, because a status field with "Complete", "complete" and "Completed" as separate options makes every filter unreliable, and your automations will read those filters.

Verify Before You Trust It

Count records per table against the source. Pick twenty records at random and check every field against the spreadsheet by eye. Check that linked records resolve to the right parent, particularly for clients with similar names.

Then run in parallel for a fortnight. Keep the spreadsheet updated alongside Airtable and compare. Tedious, and it's what catches the field that imported into the wrong column, which is the error that costs weeks if you find it after building automations on top.

Only Then Automate

Build nothing until the structure is right and the data is verified. Automation on a bad structure encodes the bad structure, and rebuilding it later is worse than waiting.

Once it's clean, start with views as your logic layer, which keeps conditions visible to the team rather than buried in a workflow. That's the pattern in Airtable views as automation logic.

When Not to Migrate At All

Worth asking honestly.

If your sheet is genuinely flat, one row per thing with no relationships, and under a few thousand rows, Airtable adds a subscription and a learning curve for benefits you won't use. A well-built Sheets automation is fine and Google Sheets automation without Apps Script covers it.

Migrate when your data has real relationships, when several automations write to the same sheet, or when lookups have started timing out. Airtable vs Google Sheets for automation covers where that line sits, and connecting Airtable to Google Sheets and Gmail covers keeping both if some people will never leave the spreadsheet.

Book a free 60-minute call and we'll map your sheet to the tables it should actually be, clean the data, and get it in without carrying the mess across.