Switch Hosts

You can move an app from Cloudflare to Vercel or Azure without moving its data at the same time. Both hosts can use the same D1 database and R2 bucket while you validate the new deployment.

This guide assumes you already have a working deployment. Pin the database provider before changing deploy.target: the default is Turso on Vercel and D1 on Cloudflare and Azure. Copying data to a different database or bucket is a separate migration.

1. Keep the Data Configuration

For an existing D1 database, set the provider explicitly:

db: {
  remote: { provider: 'd1' },
},

For Turso, use provider: 'turso' and keep TURSO_DATABASE_URL and TURSO_AUTH_TOKEN. Existing explicit provider: 'libsql' configurations also retain their database and credential names on every host.

Keep wrangler.jsonc, its D1 database ID, and the existing migrations. Prepare the D1 and R2 credentials required outside Cloudflare. An expiring Wrangler login is not a runtime credential for another host.

Current Nuxt projects use the configured database automatically. For an older standalone or Next.js mount that explicitly calls sqliteFile() or d1(), update the mount first.

2. Change the Application Host

For example, change the host to Vercel in your existing config:

deploy: {
  target: 'vercel',
}

Complete the account setup for Vercel or Azure, then deploy:

pnpm exec cloudconfig deploy

You do not need to initialize the project again. Deployment leaves the previous host running and preserves the configured database and file storage.

Nuxt agent hosts use each destination's native durable runtime. Drain or retain existing executions and recreate schedules before moving traffic; changing the host does not copy execution history. See Deploy Agents. Cloudflare Workflow classes remain specific to Cloudflare. Azure-native application database and upload adapters are separate from the Storage account used by Azure Durable Functions.

3. Verify the Same Data

Before changing DNS:

1. Open the new URL and confirm existing records and files are present.
2. Create a test record on the new host and read it through the previous host.
3. Test sign-in, private data access, and file uploads if your app uses them.

These checks verify runtime credentials as well as the uploaded application.

4. Move Traffic

Set the production origin and OAuth callbacks, then move your domain. Keep Turnstile's allowed domains current if you use it; Turnstile remains a Cloudflare service on every host.

Retain the previous deployment while validating production traffic. Remove old hosting resources after completing the cutover.

Return to the Previous Host

Change deploy.target back and deploy again. This rebuilds the application for that host, but does not reverse SQL migrations.

Keep schema changes compatible with both application versions during the transition. An older application may not work against an incompatible new schema.

When you are ready to move the data too, provision the destination, export and import records and files, verify their contents, and plan any write freeze or synchronization. Changing db.remote or storage.provider never copies data for you.