Zapier next-gen Zaps migration: audit + governance checklist
Zapier next-gen Zaps migration checklist: audit existing Zaps, map connection and API dependencies, and add governance controls before you migrate.
Airtable + Fillout → Supabase + Next.js migration playbook
Airtable + Fillout to Supabase + Next.js migration playbook: map schema and record IDs to UUIDs, rebuild form logic, retire Zaps, and cut over safely.
TABLE OF CONTENTS
If you’re replacing Airtable + Fillout with Supabase + Next.js, you’re running two migrations at once: (1) your data model and automations, and (2) your intake UX (forms, prefill, conditional logic, and follow-up actions). The fastest safe path is a parallel run. Keep Airtable/Fillout alive while you rebuild the workflow end-to-end against Supabase, then cut over once you can prove every “hidden feature” still works.
Why this migration is trickier than it looks
Teams rarely use Airtable + Fillout as “just a database + a form.” Take a consulting team’s post-session feedback form, where consultants log each client booking, flag no-shows, tag the apps involved, and trigger the right follow-up email. Over time, a form like that accumulates edge-case logic that users rely on every day:
- Required-field cues and validation rules
- Conditional fields (“if no show/no access, ask these follow-ups…”)
- Prefill links that carry context from upstream automation
- Multi-select fields that quietly depend on a separate “apps” table (plus “add new option” hacks)
- Downstream actions (send the right booking link, mark a booking complete, update a deal, etc.)
When you move to Supabase (Postgres) + a custom Next.js UI, you’re no longer selecting fields from a form builder’s Airtable integration. You’re rebuilding the “glue” explicitly: the queries, joins, and write paths.
The migration playbook (Airtable + Fillout → Supabase + Next.js)
1) Inventory the workflow, not just the tables
Start by writing down the workflow as a series of user-visible outcomes (not implementation details):
- What does the consultant see at the moment they open the form?
- What gets prefilled automatically, and from where?
- Which fields are required, and how is that signaled?
- What changes when a checkbox/radio option is selected?
- What must happen after submit (emails, Slack alerts, status changes, booking completion, etc.)?
This is your acceptance criteria list. If you don’t write it down, you’ll “finish” the migration and still miss the feature everyone cared about.
2) Map schema + IDs (the ID→UUID gotcha)
Most Airtable-centric automations implicitly rely on Airtable record IDs being present everywhere.
In Supabase, you’ll typically use UUID primary keys. That’s good, but it creates a common migration trap:
- Your legacy system still references Airtable record IDs
- Your new system wants UUIDs
- During the transition, you need to translate between them
Practical fix: add a dedicated
airtable_record_id column (TEXT) on migrated tables and make it unique. Use that as your “join key” during the parallel run, while your Next.js app uses UUIDs internally.3) Rebuild “form behavior” as product requirements
A custom Next.js form buys you freedom, but only if you explicitly rebuild what the form builder was doing for you.
At minimum, design for:
- Required field indicators: don’t rely on browser defaults; clearly label required fields and show validation messages.
- Dynamic / conditional fields: keep the rules close to the UI layer, but store the “why” in the database (e.g.,
no_show_reason,no_access_reason, etc.) so reporting isn’t fragile. - Multi-select that pulls from a real table: if you have an “involved apps” field, model it as a first-class relationship, not a brittle list of strings.
4) “Involved apps” multi-select: avoid the old workaround
A common Airtable + Fillout workaround is:
- User types a new app name
- A Zap creates a new row in an Apps table
- Another automation syncs it back so it can show up in the dropdown later
In Supabase + Next.js, you can handle this cleanly:
- The dropdown query loads options from
apps - The UI supports “create new option” if the app doesn’t exist yet
- Submitting the form creates the
appsrow if needed, then creates a row in the join table (e.g.,feedback_apps) linking the feedback record ↔ app record
This tends to remove multiple automations immediately.
5) Sequential bookings: preserve the “daily driver” features
If your team relies on “sequential bookings” (e.g., show the client’s bookings that don’t yet have feedback), rebuild it as a first-class UI component:
- Query bookings for that client
- Filter to bookings missing feedback
- Limit to a short list (e.g., “this week” or “next 10”) so it’s usable
This is one of those features that looks optional until someone loses it. Then everything feels broken.
6) Booking-link logic: encode the decision tree once
If you send different links depending on the situation (bulk hours purchase vs. next session booking vs. show remaining balance), don’t leave that logic scattered across Zaps.
Create a single “decision function” (server-side) that takes the feedback submission + client state and returns:
- Which email template to use
- Which link(s) to include
- What internal statuses to update
Then everything else (email send, Slack notification, CRM update) calls that one function.
7) Parallel run strategy (the only sane way to cut over)
A clean cutover usually looks like:
- Dual-write critical events for a short period (or mirror writes via a script)
- Run a scorecard that compares key counts and edge cases (Airtable vs. Supabase)
- Have power users test each milestone as you ship it
- Switch the “entry point” link (the prefilled feedback-form link) only after the new flow is “as good or better”
If you can’t confidently validate both systems, you’ll either delay forever or cut over blindly.
What to build first (minimum viable replacement)
If you need a fast replacement that doesn’t break the team:
- Prefilled form link works reliably
- Required fields + validation are correct
- Involved apps multi-select works (including create-new)
- Conditional “no show / no access” logic works
- Sequential bookings list exists and is usable
- Follow-up email sends correctly with the correct booking/bulk link logic
Everything else (polish, layout, extra data fields) can come after the workflow is stable.
The bigger win: you stop paying for workarounds
The hidden upside of Supabase + Next.js isn’t just “cheaper than Airtable + Fillout.”
It’s that you stop building your business logic out of platform constraints.
Once your workflow runs on your own data model + code, you can:
- iterate faster
- add UI that matches how your team actually works
- keep the “special cases” without turning your stack into a maze of brittle automations
Get help planning your migration
Migrations like this usually stall at the parallel run, when nobody can prove the new Supabase flow handles every edge case the old Fillout form did. If you’re planning the move, book a ZoomFlow session and one of our consultants will map your schema, rebuild plan, and cutover checklist with you live.
Related Posts
Salesforce to Airtable migration: CRM + production tracking playbook
A practical Salesforce to Airtable migration plan for CRM and production tracking: object audit, table mapping, status logs, dashboards, and permissions.
Move a Dental Clinic From Trello to a Notion Content Calendar
How to move a dental clinic from Trello to a Notion content calendar — with the right permissions, database setup, and a clean 2-person pilot rollout.
