The Softr to custom app migration checklist

Before you touch any data

A rebuild pays off once you are hitting user limits and building workarounds for features the blocks cannot express. Start by writing down what the Softr app really does, because none of it exports.

• List every page and which user groups can reach it

• List every block, with the filters and conditions set on it

• List every form, what it writes and where

• List every Softr workflow and what triggers it

• List every outside automation in Zapier, Make or Airtable that touches the same data

• Note which pages each group actually uses, and mark the rest to drop

• Write the permission rules for each user group in plain words: which records they can see, create, edit and delete

• Get the business owner to sign off those rules

• Decide what not to rebuild on day one

Data and users

Where your data lives decides how much work this is. Softr is a front end over a data source, so the records are usually already yours.

If Softr reads from Airtable or Google Sheets

• Confirm the base or sheet is in a business account, not someone's personal login

• Build the new app against the same base through its API, behind one layer of server code

• Map each table to Postgres, replacing linked records with foreign keys

• Keep each Airtable record ID in a legacy column

• Script the import into Postgres and rehearse it until counts and links match

If Softr reads from a SQL database or Softr Databases

• For PostgreSQL, MySQL, SQL Server, MariaDB, Supabase or Xano, leave the database where it is and point the new app at it

• For Softr Databases, read the records through the Softr Database API into Postgres

• Check whether a direct CSV export is available in your workspace, as this has been changing

• Keep each Softr record ID in a legacy column

Users

• Download the user list as a CSV from Softr's Users area

• Map each Softr user group to a role in the new app

• Import accounts without passwords, because they don't export

• Set up a magic link or set-password email for first sign-in

• Send it from your own domain, with email authentication in place

Cutover

Run both apps in parallel first, then switch in one short window. While the new app reads the same Airtable base or sheet as Softr, nothing needs syncing, which makes the overlap easy.

• Invite a small group of users to the new app while Softr serves everyone else

• Test as each user group, signed in as an ordinary user, not as an admin

• Email all users a few days ahead so the sign-in email is expected

• Pause outside automations that write to the old data source

• Run the final data import into Postgres and compare counts

• Repoint those automations at the new app, or rebuild them as server jobs

• Point your custom domain at the new app

• Add redirects from old Softr page paths, which still sit in client emails and documents

• Switch Softr to read-only rather than deleting it

After launch

Give it a few weeks before you close anything. Softr stays as your reference while you watch for gaps.

• Check error tracking daily for the first week

• Resend sign-in links to anyone who hasn't logged in

• Re-run the permission tests against live data

• Confirm every workflow and email that Softr used to send is now firing

• Make sure nothing still writes to Airtable or Sheets after the data has moved

• Cancel the Softr plan once nobody has needed it for a couple of weeks

• Archive the old base or sheet, read-only, for your records

Not every Softr app needs this. A portal or internal tool that does its job within comfortable plan limits is often better left alone, because non-developers can change it in minutes. Rebuild when the app is your core product, when permissions have become risky to manage by configuration, or when seat and record limits are shaping your pricing.