Migrate

Migrate from Vercel and Supabase

Moving from Vercel and Supabase to Stackap means copying the database and files, recreating the environment variables, deploying the code, importing the cron jobs, and then changing one DNS record.

Who this is for

This is written from the first real move: a Next.js site with a 43-table Postgres database of about 25,000 rows and 93 stored files was copied to a staging project on Stackap and compared page by page with the live original. Its domain now points at the Stackap server.

It is an operator-assisted process today, not a self-serve button. The copy tooling exists and is run for you, and the steps below are what is done and checked. If you are not already running an app that fits, read the gaps first.

Take inventory first

Every environment variable the live app uses. Pull the production values, and note which are public (NEXT_PUBLIC_*) and which are secret.
Every table, and every database function, trigger, view and enum. Tables and rows are copied for you. The rest are not.
Every stored file, and every database column that holds a URL to one.
Every scheduled job. A vercel.json with cron entries can be imported directly.
Whether the app uses the hosted sign-in service. If it does, stop here.
The domain, who controls its DNS, and the record that currently points at the old host.

What does not move automatically

Sign-in: Stackap has no sign-in service. An app that depends on one cannot move until it brings its own.
Database functions, triggers and views: The migrator copies tables and rows only. In the inventory of the founder's larger CRM, 82 of 96 database functions existed only in the live database and in no file in the repository, so extract and apply them yourself before cutover.
Storage URLs: Rows that point at files must be rewritten to the new storage host. This was done with a script for 60 URLs in the first move.
Vercel-only settings: Anything set only in Vercel, such as certain environment variables, headers, or redirects defined outside the repository, must be recreated by hand.
Preview deployments and edge features: There is no equivalent.

How to know it worked

Row counts match table by table after the final copy.
Every stored file loads from its new URL.
A sample of real pages is identical to the old site.
A real request exercises each integration the app uses, such as email or payments, in a safe mode.
Cron jobs fire once, not twice, on the first scheduled day.

Going back

Do not delete anything from the old host until the new one has served real traffic for a while. Going back is a DNS edit pointing the record at the old address, so keep the old project running until you are sure.

Run the old and new sites with their schedules and any outbound messaging switched so that only one is live. Two copies of an app that both send email will send it twice.

Steps

Create the project. Create a project on Stackap and give it its own database.
Copy the data. Run the migrator to copy tables and rows from the old database into the new one. It can be run again, so a final copy at cutover is cheap. Then apply the functions, triggers and views.
Copy the files. Download every stored object, upload it to the new storage, verify checksums, and rewrite the URLs in the database.
Recreate the environment. Set each variable with stackap env set. Public values are baked into the build, so set them before deploying.
Deploy and compare. Deploy to a staging hostname and compare it with the live site page by page. In the first move, 26 pages and 64 sampled sitemap URLs were identical.
Import cron jobs. Run stackap cron import with your vercel.json.
Cut over. Do a final data copy, attach the real hostname, and edit the single DNS record at your DNS provider so it points at the Stackap server.
Stop the old schedules. Disable the cron jobs on the old host, or they will run twice.

Early-access scope

The process is operator-assisted. No customer has used it, and the one real move so far is the founder's own site.
Anything that depends on sign-in, realtime or serverless functions cannot move.
A DNS edit is a manual step, and Stackap will not change DNS for you.
Database functions and triggers need separate handling, and an app that relies heavily on them needs the most care.

Questions

How long does a move take?

We have no timing to publish. The one real move was done across several working sessions, and most of the effort went into inventory and checking. Expect it to scale with the number of database functions, files and integrations rather than with the number of pages.

Will my site go down?

It should not need to. You run both side by side, compare them, and then change one DNS record, which propagates over minutes to hours. Lowering the record's cache lifetime a day beforehand makes the change land faster.

Stackap is in early access. Tell us what you run and we will reply with a straight answer about whether it fits.

Ask for an invitation

Last updated 2026-10-03.