This guide is for agencies and teams that built their CRM, lead tracker, content calendar or AI agent inside Airtable and have hit the wall: record caps, slow UI at scale, fragmented customer communication, or AI assistants that cannot hold conversation context. It walks through what to move, what to keep, and how to migrate without losing data or downtime.
Important upfront: this is not a "rip out Airtable" pitch. Most teams that complete this migration keep Airtable for operational data (project tracking, content calendars, internal SOPs) and move only the customer-facing pieces. The end state is Airtable + Inflowave running side by side, each owning what they are best at.
1. Why teams move (and when not to)
The five recurring reasons teams migrate parts of their workflow from Airtable to Inflowave:
- Lead volume hit record caps. Airtable Team tier maxes at 50,000 records per base. At 30-40k an agency starts feeling the slowdown; at 50k they are forced to upgrade to Business ($54/seat) or split into multiple bases (operational pain).
- Conversation context cannot live in a row. A lead tracker row with 15 columns cannot hold a 50-message DM conversation history with full context. Teams using Airtable for IG DM tracking end up with brittle systems where context fragments live in screenshots and Slack threads.
- No native Instagram DM, SMS or voice. Sending and receiving messages from Airtable requires third-party integrations (Twilio + custom script) that break when APIs change.
- AI agent ambitions outgrew Airtable AI fields. Airtable's AI is great for "categorize this row" or "summarize this content." It is not built for multi-turn customer conversations with memory and tool use.
- Per-client isolation for agencies is manual. Running 10 client accounts means 10 separate Airtable bases that the agency has to manually keep in sync structurally. Inflowave's sub-account model handles this natively.
When NOT to migrate: if your Airtable use is primarily content calendars, project management, internal SOPs, deliverables tracking, product catalogs or anything that is not a customer conversation, Airtable is great and you should keep it. Add Inflowave for the conversation layer, do not replace Airtable.
2. What to move, what to keep in Airtable
The mental model: customer-facing stuff goes to Inflowave; operational stuff stays in Airtable. Here is the breakdown for an agency:
| Data type | Move to Inflowave | Keep in Airtable |
|---|---|---|
| Lead records | Yes, all of them | Mirror via webhook for reporting |
| DM conversation history | Native, with full context | No |
| Pipeline stages + deals | Yes (native CRM) | Optional read-only mirror |
| AI agent rules + prompts | Yes | No |
| Email + SMS sequences | Yes | No |
| Client roster | Sub-accounts | Master CRM record |
| Content calendar | Scheduling only | Plan + approve here |
| Deliverables tracker | No | Native Airtable Interface |
| Product catalog | Read via API only | Master source |
| Internal SOPs + team rosters | No | Stay in Airtable |
The pattern: anything where a customer is on the other end of the interaction goes to Inflowave. Anything internal to the team stays in Airtable. The two layers connect via webhooks + API.
3. Pre-migration audit
Before exporting anything, run this audit. It surfaces hidden dependencies that will break otherwise.
Inventory every Airtable Automation
In each base, open Automations. List every trigger and every action. Each one represents a workflow your team relies on. Decide for each: is the underlying workflow moving to Inflowave (where it becomes a native workflow), or is it staying in Airtable (where it continues to operate)?
Inventory every Airtable Interface
Interfaces are how stakeholders interact with the base. Each one represents a UX someone depends on. For deliverables and reporting dashboards, plan to rebuild them as Inflowave dashboards or per-client report templates. For internal team interfaces, leave them in Airtable.
Document every linked-record relationship
Airtable's linked records create implicit dependencies. A "Leads" base linked to a "Clients" base linked to a "Deliverables" base has data that loses meaning if you migrate one without the others. Sketch the relationships before exporting so the import side knows which Inflowave entities to create in which order.
Quantify the conversation history loss
If your Airtable Leads base has a "Last Note" or "Notes" long-text field with conversation summaries, those CAN migrate. If your actual DM history lives ONLY in screenshots attached to records, that history is effectively unmigrate-able. Decide whether to backfill from Instagram (via Meta API export) or accept the loss of historical context.
Check seat counts and per-base record counts
Drives expectations. A 5-seat agency moving 30k leads, 12 clients and 6 months of content calendar history is a different scope than a 1-seat solo operator moving 800 leads.
4. Data mapping: Airtable schema to Inflowave
The high-level mapping most agencies follow:
| Airtable concept | Inflowave equivalent | Notes |
|---|---|---|
| Leads base, single row | Lead in CRM | 1-to-1 mapping |
| Status field (single select) | Pipeline stage | Map values to stages |
| Tags field (multi-select) | Lead tags | 1-to-1 mapping |
| Custom fields (any type) | Custom fields on lead | Create matching schema first |
| Linked Client record | Sub-account membership | Create sub-accounts first |
| Last Note long-text | Lead activity log entry | Import as note |
| IG Handle field | Instagram identity on lead | Reconcile to IG user ID |
| Email field | Lead email + email channel | Validates against email service |
| Phone field | Lead phone + SMS channel | E.164 format required |
| Deal Value (currency) | Opportunity amount | Create matching pipeline |
Build the Inflowave schema FIRST. Create the pipelines, the sub-accounts, the custom fields and the tags before exporting anything from Airtable. The import then becomes a clean CSV upload to a target that already understands the shape.
5. Step-by-step migration
A 4-week template, scoped for a 5-person agency with 10k leads and 8 clients. Adjust based on your scale.
Week 1: setup + parallel run begins
- Day 1: Provision the Inflowave account. Create the sub-account hierarchy (one per client). Connect Instagram accounts. Connect email + SMS sending.
- Day 2: Build the pipeline structure (stages, custom fields, tags). Mirror your Airtable Leads base schema.
- Day 3: Configure Inflowave webhooks to push new lead + status-change events into Airtable. The legacy team continues to use Airtable; the new system mirrors data outbound.
- Day 4-5: Train 1-2 team members on the new Inflowave UI. Run side-by-side workflows for one small client account to validate.
Week 2: bulk lead import + AI agent setup
- Day 6: Export Airtable Leads base as CSV. Clean up (remove duplicates, validate email format, normalize phone numbers).
- Day 7: Upload via Inflowave's CSV import. Map each Airtable column to the corresponding Inflowave field. Spot-check 20 imported records against Airtable originals.
- Day 8: Build the AI agent for one client (low-risk one). Train it on real conversation history exported from Inflowave's new mirror data plus any usable Airtable notes.
- Day 9-10: Run the AI agent in ghost mode (it generates draft replies but a human approves before sending). Calibrate.
Week 3: cutover communication channels
- Day 11-12: Switch the first client's Instagram DM workflow from your old Airtable + Twilio rig to Inflowave native. Watch closely for 48 hours.
- Day 13-14: Switch email automation. Existing sequences get rebuilt as Inflowave email workflows.
- Day 15: Switch SMS. Same pattern.
Week 4: roll out remaining clients + retire workflows
- Day 16-18: Roll out the remaining 7 clients to the new system, batch of 2 per day. Each client gets a 48h validation period before considering them cut over.
- Day 19: Retire the legacy Airtable Automations that handled customer-facing workflows. The Airtable base now becomes a reporting + reference mirror only.
- Day 20: Final reconciliation. Compare lead counts, deal values, conversation counts between systems for the previous 30 days. Any deltas get investigated.
6. The parallel-run period
Migration risk drops dramatically when you run both systems in parallel for 2-4 weeks before cutting over. During the parallel period:
- Inflowave is read-write for the migrated workflows: new leads, new conversations, new pipeline movements.
- Airtable is read-only mirror: every Inflowave change webhooks into Airtable so the legacy reporting + team familiarity keeps working.
- Team operates in Inflowave, references Airtable for historical context as needed.
- Daily reconciliation check: lead count delta, pipeline stage distribution delta, conversation count delta. Any drift above 1% gets investigated same day.
Most issues surface in the first 5-7 days of parallel run. By day 14 the team has natural confidence in the new system. Pushing past day 21 usually means stalling, not de-risking.
7. Cutover + Airtable shutdown decisions
At cutover, you have three options for the customer-facing Airtable assets:
Option A: keep Airtable as a read-only mirror
Most common choice. Inflowave webhooks keep populating Airtable so legacy reporting + Interfaces continue to work. Read-only means no one writes to Airtable for customer-facing data anymore. Saves the operational pain of fully migrating reporting on day one.
Option B: archive Airtable, rebuild reporting in Inflowave
Cleaner long term but requires upfront work rebuilding dashboards in Inflowave (or your BI tool reading from Inflowave's API). Choose this if your Airtable Interfaces were minimal or your team is small.
Option C: shrink Airtable scope
Most pragmatic. The customer-facing Airtable bases shut down. The operational Airtable bases (content calendars, project trackers, deliverables) continue running, fed by Inflowave webhooks where they need customer data. You go from 8 Airtable bases to 3-4, drop a seat or two, save $50-100/mo.
8. Gotchas we have seen
CSV exports lose linked-record relationships
Airtable's CSV export flattens linked records to text (the linked record's primary field). On import, those become orphaned strings unless your import logic re-resolves them. Solution: export the linked tables in dependency order and re-link via Inflowave API rather than CSV.
Date formats fight you
Airtable exports dates in the user's locale format by default. ISO-8601 is what Inflowave wants. Solution: format date fields explicitly in Airtable BEFORE export, or post-process the CSV before import.
Phone numbers without country codes
Airtable accepts whatever phone format you typed in. Inflowave wants E.164 (+15555555555). Solution: bulk-format with a script during cleanup, or accept that some SMS recipients will fail validation and need manual fixing post-import.
Attachments do not migrate via CSV
Attachments in Airtable (images, PDFs, screenshots) export as URLs that expire when the base is later cleaned up. For any attachment you want to preserve, download it and re-upload to Inflowave (or to S3 / Cloudflare R2 with permanent URLs that Inflowave can reference).
Automations triggered by Inflowave webhooks can loop
If an Airtable Automation triggered by an Inflowave webhook then writes back to Inflowave (e.g., to update the lead based on enrichment), and Inflowave fires another webhook, you can create an infinite loop. Solution: use a "source" field on updates so Airtable Automations skip records where source="inflowave" and Inflowave skips updates where source="airtable".
Team muscle memory fights you for 2-4 weeks
Even after parallel-run training, expect team members to instinctively open Airtable first for a week or two. This is normal. Operating in Inflowave needs to become the default through repetition. Disable write access to the customer-facing Airtable bases at cutover so the muscle memory does not actually corrupt data.
FAQ
How long does a typical migration take?
Solo operators with one base: 1-2 weeks. Small agency (5-seat, 10k leads, 8 clients): 4 weeks following the template above. Large agency (10+ seats, 100k leads, 20+ clients): 8-12 weeks with phased cutover by client batch.
Can we migrate without downtime?
Yes. The parallel-run period IS the no-downtime strategy. Both systems are live and synced; cutover is a flip of who is read-write vs read-only. Customers never see a gap.
What happens to our Airtable Interfaces?
If they show customer-facing data and you want to keep them, the mirror webhook keeps them working post-cutover (Inflowave writes to the Airtable base, Interface reads from it). If you want to retire them, rebuild equivalent reports inside Inflowave or your BI tool.
Will our AI agent know about historical conversations?
For conversations that already happened in Instagram DM, yes if you reconnect the IG account and let Inflowave fetch the conversation history through the Meta API. For conversations that only lived as notes in Airtable rows, you can import them as lead activity log entries so the AI agent has them as context.
What if we want to roll back?
During parallel run, rollback is free (just keep operating in Airtable, drop the new system). Post-cutover, rollback means importing the Inflowave state back into Airtable via API + spending a week revalidating. Most teams who follow the parallel-run template do not roll back, but the option exists if Inflowave does not work out.
More on running both systems together
See our Inflowave + Airtable integration guide for the patterns and stack designs we see most often.
Bottom line
Migrating from Airtable to Inflowave is a 2-12 week project depending on scale, executed via parallel-run rather than big-bang cutover. The end state is rarely "Airtable is gone." The end state is "Airtable holds operational data, Inflowave handles customer conversations + CRM, the two are wired together via webhooks + API, and the team uses each one for what it is best at."
If you are at the point where Airtable's record caps, communication fragmentation, or AI agent limits are slowing your team down, this guide is your migration template. Start with a single small client during week 1, validate the parallel-run flow, then phase the rest of the agency through over the following 3-8 weeks.