Inventory beyond the frontend
List the Vercel Functions, cron jobs, and every marketplace product attached to the project — database, storage, queues. That list, not the pages directory, is the real migration scope.
Declare the backend in stack.json
Write tables for the marketplace database records, buckets for blob or file storage, nodejs workers for the serverless functions, and workflows for cron jobs. Review the kernstack plan before deploying anything.
Export data, re-enter secrets
Export records from the attached databases as JSON or CSV and load them into the declared tables; copy files into buckets. Re-enter environment variables as project secrets.
Move the interface and retire Vercel
Serve the built frontend from a gateway prefix route, rehearse on a preview target, then cut the domain. Keep the Vercel project alive until analytics show no traffic, then close it and the vendor accounts.
What moves from Vercel — and what the marketplace was hiding
The visible part is the frontend: a Next.js, SvelteKit, or static build that Vercel serves. On KERNSTACK the same built interface is served by a gateway prefix route in the project, so preview and production keep the same shape you reviewed. If the frontend is the only thing you run, be honest with yourself: Vercel is excellent at exactly that, and this migration earns its keep when the backend behind the interface has outgrown add-ons.
The backend is where the mapping matters. Vercel Functions are JavaScript or TypeScript, and KERNSTACK functions are Go WebAssembly — so Node handlers do not become functions, they become container workers with the nodejs runtime. Cron jobs become workflows. And every marketplace addition — the Postgres, the blob storage, the queue — becomes a first-class resource: tables for records, buckets for files, declared in the same stack.json as the code that uses them.
- Environment variables move by re-entering them as project secrets; they are never exported from Vercel for you.
- Edge Middleware logic becomes gateway routing decisions and worker code — it does not translate automatically.
- Marketplace databases stay reachable during the move; export when the new tables are ready, not before.
Backend first: the order that never breaks the live site
Move the invisible parts first. Stand up tables, buckets, and workers on KERNSTACK while the Vercel frontend keeps deploying exactly as today, calling the new backend over HTTPS. Each vendor you empty can be cancelled while the site never changes address.
Move the frontend last, when it is the only thing left. The built interface lands on a gateway prefix route, preview targets rehearse the cutover, and the Vercel project retires once traffic reads zero. Teams that follow this order usually discover the frontend move is the easy part — the architecture already changed underneath it.
Resource-by-Resource Mapping from Vercel
- Hosted frontend (Next.js, SvelteKit, static) →
gateway prefix route: The built interface is served from the project itself; add cdn_enabled to the route where cached delivery matters. - Vercel Functions (Node.js) →
workers (nodejs): JavaScript and TypeScript handlers run as container workers. KERNSTACK functions are Go WebAssembly, so Node code never becomes a function. - Cron Jobs →
workflows: Scheduled triggers become declared workflows whose steps call functions and workers — visible in the same plan as the code. - Marketplace Postgres or KV →
tables: Records export as JSON or CSV and load into key-value tables. Genuinely relational queries are the exception: keep that database external and call it over the network. - Blob storage and uploads →
buckets: Files copy over HTTPS; browsers upload with presigned URLs issued by your workers. - Environment variables →
secrets: Values are re-entered as project secrets and injected into functions and workers; nothing is exported from Vercel automatically. - Edge Middleware →
gateway routes + workers: Rewrite request-shaping logic as route configuration and worker code. There is no edge-isolate runtime to translate to.
Frequently asked questions
Yes, and it is the recommended first step. Tables, buckets, workers, and workflows run on KERNSTACK while your Vercel deployment calls them over HTTPS. Many teams stop there for a release cycle; the frontend moves later, when having one project graph is worth more than the familiar deploy button.
No — KERNSTACK functions are Go WebAssembly handlers. TypeScript and JavaScript handlers become container workers with the nodejs runtime, which is also where longer-running work belongs. Only Go handlers map to functions. Any migration guide that hides that distinction is setting you up for a surprise.
Project settings, deployment history, Edge Middleware semantics, and marketplace vendor dashboards. The code, the data, and the domain move; the platform configuration is re-declared in stack.json. Analytics history stays in Vercel — export reports before you close the project.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.