Migrate from Airtable to Slab5 in a weekend

Airtable is a great prototype. It is a terrible production CRM. The moment your operational data needs scopes, audit, webhooks, and an agent-friendly API, Airtable's editorial-first design starts working against you.

This is the migration we have done several times. Two days, three scripts, no downtime.

Decide what each base becomes

Not every Airtable base maps to the same Slab5 module. A useful triage:

• Customers, leads, deals → CRM. Map columns to typed CRM fields. Anything that doesn't fit goes into custom_fields.
• Content calendar, blog drafts, copy → CMS. Each Airtable view becomes a collection. Markdown columns become markdown fields.
• Tickets, requests → Support. Tickets, messages, priorities, assignees — all first-class in Slab5 Support.
• Internal tasks → Tasks. With references back to the parent record.
• Anything custom that doesn't fit a module → CMS collection with `custom_fields`. Slab5 CMS collections are typed JSON — perfect for domain-specific tables.

The migration script

The whole thing fits in about 60 lines of TypeScript per base. Pseudocode:

``ts const records = await airtable(base, table).list(); for (const r of records) { await slab5.crm.contacts.create({ email: r.fields.Email, name: r.fields.Name, custom_fields: pickRest(r.fields), idempotency_key: airtable:${r.id}, }); } ``

Use Airtable's record IDs as idempotency_key values. If you re-run the script, Slab5 will not create duplicates.

Verify with the audit log

After every migration pass, query the audit log filtered to your migration credential and confirm record counts match. The audit log is what makes this safe to rerun.

What you give up

• The grid-spreadsheet editorial UI. If your team lives in that UI, plan for a transition period.
• Inline forms. Use a real form on your site that posts to POST /v1/leads.
• Roll-ups and per-cell formulas. Use the BI module for aggregates instead of computing them inside rows.

What you gain

• A real REST API.
• MCP access for agents.
• Scoped credentials per integration.
• A workspace audit log.
• Webhook fan-out instead of Zapier polling.
• Typed schemas with validation.

For most teams that have outgrown Airtable, the move to Slab5 is not "another spreadsheet." It is the first time their operational data has been a programmable backend instead of a shared document.

A migration agent with read access to Airtable (via your own loader) and crm:write, cms:write, tasks:write can do the move incrementally. Use idempotency_key so retries are safe.

Loop through Airtable records. For each, call the appropriate Slab5 create endpoint with the Airtable record ID as the idempotency key. Verify counts via the audit log.