Clients
Kevin, Los Angeles · “the flexibility in their expertise was really key to make things work”Dominik, Australia · “a clean, scalable backend that now powers our real estate enquiry responder”Pascal, Austria · “superb knowledge of both Weweb and Xano”Operations lead, Australia · “one of the first holidays EVER where no groups have turned up at the wrong cinema”Kevin, Los Angeles · “the flexibility in their expertise was really key to make things work”Dominik, Australia · “a clean, scalable backend that now powers our real estate enquiry responder”Pascal, Austria · “superb knowledge of both Weweb and Xano”Operations lead, Australia · “one of the first holidays EVER where no groups have turned up at the wrong cinema”
Book a call
Migrations · Airtable

To move off Airtable, you rebuild the operation as an app with its own database one module at a time, keep Airtable running for everything that hasn't moved yet, and switch each module only once the team is already working in the new one.

Airtable works well for a lot of teams, and its interfaces can already limit what each person sees. It can stop fitting when a base becomes the system the whole operation runs on: more records than the plan allows, access rules more specific than you can set up there, and outside tools that all share one base's API limit.

Book a 15-minute call Take the 2-minute test

When it makes sense

  • You're close to your plan's record limit, or archiving data to stay under it
  • You need access rules by location, team or module that you can't set up in Airtable the way the team works
  • Automations between Airtable and your other tools fail and nobody notices for days
  • Most of the team needs to work in it, and an editor seat for each person doesn't add up

When it doesn't

  • A few people use it and it does the job
  • The data fits in a base and the permissions you need already exist
  • What hurts is one automation: fix that, not the whole system
  • 50,000 records per base on the Team plan and 125,000 on Business.
  • 5 API requests per second per base, shared by every outside tool (Make, n8n, Zapier, scripts) that reads or writes it.
Source: Airtable's plans and API documentation, October 2026.

01

We map the bases, the automations that touch them and who uses each view.

02

We build the module that hurts most first, with its own permissions.

03

Automations are pointed at the new app one at a time, writing to both sides before anything is cut.

04

Each module moves once the team already works in it. Airtable goes when the last one has moved.

Rules hidden in names: a location treated as backup stock because of the letter it starts with, when many of those locations are used every day.

Linked records and lookups, which have to be rebuilt as tables and relationships in the new database.

Automations in Make, n8n or Zapier that nobody listed: every one that reads or writes the base has to be found and repointed before the switch.

Attachments, comments and history: they need their own plan, or they get left behind.

From our work

A warehouse system moving off Airtable, module by module.

An online retailer with more than 50 employees ran its operation on an Airtable Enterprise plan for 10-15 users, with automations around it. Giving the whole team access would have meant about 50 licenses. It was also running into record limits, and couldn't give access as fine-grained as the team needed. We're moving it to its own app one module at a time: the task board went live first, receiving has run on the new app since October 2026, and the rest moves in November 2026, when the Airtable plan stops being paid. The task board holds more than 100,000 records and was tested with a million without lag.

Warehouse system
WAREHOUSE
TasksProcurementReceiving
+ Create Task
128,585Total
211Active
38In Progress
9Needs Review
2Blocked
126,324Done
TaskTypeTitle / SKUStatus
REP-1004ReplenishmentDesk lamp – oakSKU-LMP-0412Completed
CC-0142Cycle CountWater bottle 1LSKU-BTL-0098Completed
PUT-0031PutawayNotebook setSKU-NB-1207Completed
PICK-0207PickingGift box MSKU-GB-0031In Progress
TSK-0098CustomRestock front shelfBN-17-3Completed

What happens to our data in Airtable?

It moves table by table into a database in your name. Each table is copied, checked against the original and kept in step while both are in use, until the module that uses it has moved.

Can the team keep using Airtable while we migrate?

Yes, that's the point. Everything that hasn't moved stays in Airtable, and nobody has to stop working for a switch.

What about our automations?

Simple ones are pointed at the new app instead of rebuilt. Complex ones become part of it. Before anything is cut, they write to both sides for a while.

Will it cost less than Airtable?

Not always. A custom app has its own costs: hosting, maintenance and changes. We compare both with your numbers on the call, and if Airtable comes out ahead, we'll say so.

Who owns the code?

You do. The repository, the hosting and the third-party accounts are in your name from the start or move there before we finish.

Other migrations

Fifteen minutes on a call. If it's not a fit, we'll say so and point you somewhere better if we can.

Book a 15-minute call
SectionHome
Book a call