nextjs-webflow-to-vercel

Migrate Next.js from Webflow Cloud to Vercel

What this skill does

Moving a Next.js app from Webflow Cloud to Vercel mostly means removing the deployment layer that adapted the app to the Cloudflare Workers runtime. On Webflow Cloud the app runs as a Cloudflare Worker through the @opennextjs/cloudflare adapter, served from a mount path inside a Webflow site. On Vercel the same app runs natively on Vercel Functions with Fluid compute on by default, in a full Node.js runtime, served from the root, so it scales with traffic on its own and supports the framework's full feature set.

Unlike a framework that needs a platform adapter, Next.js runs natively on Vercel, so no adapter replaces OpenNext — you just take it out. The app code (pages, components, Route Handlers) mostly stays the same. The work sits in a few places: the OpenNext adapter and its dev hook in next.config.ts, the Webflow Cloud and Wrangler config files that get deleted, the base path the app mounted under, the Edge runtime directive on routes and middleware, and any server code that read storage bindings through getCloudflareContext().env.

The Vercel Plugin

The user will have installed the Vercel Plugin already, which among other things includes a number of helpful skills that can assist you and the user with this migration. Prefer those skills for current, detailed product guidance, and let this skill drive the order of work. The ones that line up with these steps:

• vercel-storage and marketplace: step 5 (Blob, Edge Config, Neon, Upstash, and Marketplace provisioning).
• env-vars: steps 5 and 6 (vercel env, .env files, OIDC tokens).
• vercel-cli and deployments-cicd: steps 6 and 7 (env vars and deploy).
• vercel-functions: step 5 (Route Handlers on Vercel Functions) and the Best practices section (maxDuration, regions, ISR).

There are other skills included that may assist with the migration.

Steps the user completes manually

You handle most of the migration directly by editing files and running commands. A few actions need the Vercel dashboard, a Vercel account, or secret values, so the user has to do those:

• Creating the Vercel account (see Before you start).
• Creating and connecting the backing stores in step 5.
• Adding environment variables in step 6.
• Deploying in step 7.

Guide the user through each of these. Give clear, specific instructions, then wait for them to confirm before moving on. Do not report any of them as done while the user still has to do it.

If you are unsure about a dashboard flow or whether a detail is still current, use an applicable Vercel skill when one is available (see "The Vercel Plugin" above), and check the latest with a web search scoped to the vercel.com domain (for example, site:vercel.com vercel blob oidc token).

Service mapping (quick reference)

Before you start

Check the repo for these, and ask the user to confirm anything the repo cannot show:

• A working Next.js app deployed on Webflow Cloud. Look for next in package.json and the @opennextjs/cloudflare adapter (in package.json, next.config.ts, or open-next.config.ts) to confirm the framework and platform before changing anything.
• Node.js 20 or later.
• A Vercel account (the user confirms this; you cannot create one).
• The Vercel CLI, for the env and deploy steps: npm i -g vercel.

Do not use this skill for a different framework, a brand-new app (set it up for Vercel directly instead), or a move in the other direction (Vercel to Webflow Cloud).

Steps

Work through these in order. Step 0 tells you which of steps 3 and 5 apply, so you can skip what the app does not use.

Step 0: Audit the current Webflow Cloud setup

Run the audit script from the project root:

bash scripts/audit.sh /path/to/project

It reports the Webflow Cloud and Wrangler config files, the @opennextjs/cloudflare adapter and its initOpenNextCloudflareForDev() dev hook, the base path (basePath and assetPrefix) and likely manual prefixing, any export const runtime = 'edge' directives on routes and middleware, every getCloudflareContext() access, and which storage bindings are declared in wrangler.json (Object Storage, Key Value Store, SQLite). Use the output to pick which later steps apply, then show the user a short checklist. Skipping this leads to missed bindings and runtime errors.

Step 1: Remove the OpenNext Cloudflare adapter

Vercel runs Next.js natively, so there is no adapter to install — you just remove OpenNext. Uninstall the adapter and Wrangler:

npm uninstall @opennextjs/cloudflare wrangler

Then remove the OpenNext dev hook from next.config.ts. The create-cloudflare setup adds these lines so getCloudflareContext() works in next dev, and they no longer apply on Vercel:

// Remove these lines
import { initOpenNextCloudflareForDev } from "@opennextjs/cloudflare";
initOpenNextCloudflareForDev();

Step 2: Remove the Webflow Cloud configuration files

Delete the Cloudflare- and Webflow-specific files that no longer apply on Vercel:

• webflow.json, which told Webflow Cloud your framework. Vercel detects Next.js automatically.
• wrangler.json, including its compatibility_date, nodejs_compat flag, assets binding, and storage bindings. Vercel Functions run on Node.js, so the compatibility flags have no equivalent.
• open-next.config.ts, the adapter configuration.
• cloudflare-env.d.ts (sometimes cloudflare.env.ts), the generated binding types.

Your storage bindings live in wrangler.json. Before deleting the file, note which bindings the app uses (Object Storage, Key Value Store, or SQLite) so you can recreate them on Vercel in step 5.

Step 3: Remove the base path and Edge runtime settings

On Webflow Cloud the app is served from a mount path such as /app, so basePath and assetPrefix are set in next.config.ts to match. On Vercel the app is served from the root, so remove both options unless you intend to keep serving the app under a subpath:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  // Remove basePath and assetPrefix when serving from the root
  // basePath: "/app",
  // assetPrefix: "/app",
};

export default nextConfig;

Because the base path is gone, remove the manual prefixing Webflow Cloud required in client-side fetch calls and asset references. Change fetch(${basePath}/api/users) back to fetch("/api/users"), and drop the asset prefix from plain <img> tags.

Webflow Cloud also runs API routes and middleware on the Edge runtime. On Vercel, remove the export const runtime = 'edge' directive from your Route Handlers and middleware.ts so they run on the default Node.js runtime. Migrating from the Edge runtime to Node.js is recommended for performance and reliability, both runtimes run on Fluid compute with Active CPU pricing, and Node.js gives your routes the full Node.js API surface and access to npm packages that depend on Node.js built-ins.

Step 4: Update your build scripts

Replace the Webflow Cloud preview script in package.json with the standard Next.js commands. Vercel runs the build for you, so you no longer need the opennextjs-cloudflare preview command:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Vercel auto-detects Next.js on import and sets the build command and output directory, so these scripts mainly support local development.

Step 5: Replace Webflow Cloud bindings with Vercel storage

This is the main code change. On Webflow Cloud you read storage through bindings on the Cloudflare env, accessed in a Route Handler with getCloudflareContext(). On Vercel you read connection details from process.env and talk to each store through its SDK or client. Remove every getCloudflareContext() call and replace the binding operations. Read references/service-mapping.md for the before and after code for each binding, then install the SDK you need, for example:

npm i @vercel/blob

Have the user create and connect the backing stores. This is what adds the env vars the code reads, so it has to be done before the app will run:

• Object Storage to Blob: create a Blob store on the Storage page, then connect it to the project from the store's Projects tab. Vercel adds the store's environment variables, including a short-lived VERCEL_OIDC_TOKEN that it rotates, and the SDK uses them automatically, so put() needs no token in code. This OIDC approach is recommended over the long-lived BLOB_READ_WRITE_TOKEN, which is only for code that runs outside Vercel.
• Key Value Store to Redis: add a Redis integration such as Upstash Redis for caching and session data, or use Edge Config for small, read-heavy config.
• SQLite to Postgres: add a Postgres database such as Neon from the Marketplace.

Provisioning a store from the Marketplace adds its connection string and credentials as env vars, which the code reads from process.env.

Step 6: Move environment variables and secrets

Recreate your Webflow Cloud environment variables as Vercel environment variables. Webflow Cloud stores these per environment in your app's settings and injects them at runtime only. Vercel stores them per environment (production, preview, and development) in project settings and makes them available at both build time and runtime.

Never handle the user's secrets. Do not ask the user for secret values, and do not accept secrets pasted into the chat. Do not offer to save, enter, or store environment variables or secrets for the user, and refuse if asked to do so. Setting the actual values is the user's job, done in the dashboard or in their own terminal. Your part is to prepare the list of variable names and the exact commands.

You can list every variable and secret to recreate and write out the exact commands, but you cannot supply secret values or sign the CLI in, and you must not make up values.

The user adds each variable, either on the project's Environment Variables page or with the CLI after vercel login:

vercel env add DATABASE_URL production

Once the user has signed in, you can link the project and pull the values into a local .env:

vercel link
vercel env pull

A variable added to production is not available in preview or development unless it is added there too. Because Vercel exposes environment variables during the build, you can re-enable any build-time validation you had to disable on Webflow Cloud, where variables aren't available at build time.

Step 7: Deploy

You cannot import a project, confirm the framework preset, sign in, or select Deploy, so walk the user through one of these paths. Both run the app on Vercel Functions.

Deploy with Git (recommended):

1. Push the project to GitHub, GitLab, or Bitbucket.
2. In the Vercel dashboard, select Add New > Project, then import the repo.
3. Vercel detects Next.js and sets the build command and output directory. Confirm the framework preset, add the environment variables from step 6, and select Deploy.

After the first import, every push to the production branch creates a production deploy, and every pull request gets its own preview URL.

Deploy with the CLI: after vercel login, run vercel for a preview or vercel --prod for production.

If the vercel-deploy skill is available, you can use it to create a preview deploy and a claim URL without the user signing in first, which is a good way to check the build before wiring up a connected project.

After the move: check these

You can grep for the code issues; ask the user to check anything in the dashboard. See references/troubleshooting.md for fixes.

• No @opennextjs/cloudflare import or initOpenNextCloudflareForDev() call remains in next.config.ts or anywhere else.
• No getCloudflareContext() access remains anywhere in server code.
• No leftover base path: basePath and assetPrefix are gone from next.config.ts, and client-side fetch calls and <img> tags no longer prefix a base path.
• No export const runtime = 'edge' remains on Route Handlers or in middleware.ts.
• Each env var exists in the right environment, not only production.

Tune after migrating (optional)

• Tune function resources per route: set export const maxDuration = 60 in a route's segment config for routes that need more time, or configure memory and regions in vercel.json.
• Put functions near the data: set the function region close to the Marketplace database to cut latency.
• Take advantage of features that were limited on Webflow Cloud: Incremental Static Regeneration, on-demand and tag-based revalidation, the use cache directive, and Node.js middleware all work on Vercel without extra configuration. For scheduled and background work Webflow Cloud didn't offer, look at Cron Jobs, Queues, and Workflows.

References

• service-mapping: Before and after code for replacing each Webflow Cloud binding (Object Storage to Blob, Key Value Store to Redis or Edge Config, SQLite to Postgres), plus the store setup notes. Read before step 5.
• troubleshooting: The common errors after the move and how to fix them.