How to Migrate Your App From Vercel to Edge Hosting (2026)

You have decided to move. Maybe the pricing crossed a threshold. Maybe bandwidth charges on image-heavy pages are growing faster than revenue. Maybe you need native WebSocket support or serverless functions that understand your organisation. Whatever the trigger, the question is no longer "should we?" but "how?"

The good news: modern frontend architecture makes migration straightforward. Your apps are stateless. Your data lives in external databases. Your authentication runs through a third-party provider. The only thing your hosting platform actually holds is your code, your environment variables, and your build configuration.

Estimated effort: 1-2 weeks of engineering time for a typical portfolio of 3-5 apps. No downtime required. No data migration. One app at a time.

This guide walks through the process step by step.

Before You Start: The Pre-Migration Checklist

Migration fails when teams skip preparation. Run through this checklist before touching a single configuration file.

Inventory Your Apps

List every project deployed on Vercel. For each one, document:

Framework and version (Next.js 14, React 18, static HTML, etc.)
Build command and output directory
Environment variables (count them, do not copy them yet)
Custom domains and DNS configuration
Serverless functions (API routes, middleware, edge functions)
Vercel-specific features in use (ISR, image optimization, analytics, speed insights, edge middleware)
Third-party integrations triggered by Vercel (webhooks on deploy, preview URL notifications, etc.)

This inventory is your migration map. It tells you which apps are simple (static sites, basic React) and which need attention (heavy ISR usage, Vercel-specific APIs).

Identify Vercel-Specific Dependencies

Search your codebase for these imports and usages:

@vercel/analytics -- Vercel Analytics SDK
@vercel/speed-insights -- Vercel Speed Insights
@vercel/og -- Vercel OG image generation
@vercel/edge -- Vercel Edge Runtime helpers
@vercel/postgres, @vercel/kv, @vercel/blob -- Vercel storage services
next/image with Vercel's image optimization loader
revalidatePath / revalidateTag used with ISR

Each dependency needs a replacement or removal. Most have straightforward alternatives. A few require architectural adjustments.

Check Your DNS Configuration

If your domains point to Vercel via CNAME records, you will need to update them. Document every domain, subdomain, and redirect rule. DNS changes propagate globally in minutes to hours, so plan your cutover timing accordingly.

Set Up Your Target Platform

Create your account on the target platform before migrating anything. Verify that:

Your team members have access
Git integration is connected to the same repositories
Build settings match your requirements
Custom domain setup is available and tested with a non-production domain

The Migration Order: Simple First, Complex Last

Do not migrate everything at once. Start with the app that carries the least risk and teaches you the most about the new platform.

Step 1: Start With Your Simplest App

The ideal first migration candidate is:

A marketing site or documentation site (static or mostly static)
No authentication complexity
No serverless API routes
Minimal or no Vercel-specific features
Low traffic consequences if something goes wrong during cutover

This first migration is as much about learning the new platform as it is about moving code. You will discover build configuration differences, environment variable handling, and deployment workflow changes. Better to discover them on a low-stakes app.

What to do:

Connect your repository to the new platform
Configure the build command and output directory
Set environment variables (copy from Vercel project settings)
Trigger a build and verify the output
Test the preview deployment thoroughly -- every page, every link, every form
When satisfied, update DNS to point the production domain to the new platform
Keep the Vercel project active for 48 hours as a rollback option

Step 2: Migrate Static and Client-Side Apps

After your first app is running successfully, move through your remaining static sites, SPAs (single-page applications), and client-rendered apps. These are typically straightforward because they have no server-side dependencies on the hosting platform.

Common adjustments:

Build output format: Some platforms expect output in dist/ rather than .next/ or out/. Check your build configuration.
Redirects and headers: Vercel uses vercel.json for redirects. Other platforms use _redirects files, wrangler.toml, or platform-specific configuration. Port your redirect rules.
Environment variables: Verify that all NEXT_PUBLIC_* or VITE_* variables are set. A missing environment variable is the most common cause of post-migration bugs.

Step 3: Migrate Server-Rendered Apps (Next.js)

This is where the migration requires the most attention. Next.js apps that use server-side rendering, API routes, or middleware need specific consideration.

Next.js on non-Vercel platforms -- what works:

Server-side rendering (SSR) -- works on all major platforms
API routes -- work but may run in V8 isolates instead of Node.js
Server components -- work with minor edge cases
Static generation (SSG) -- works everywhere
Middleware -- works but behaviour may differ slightly from Vercel's implementation
Dynamic routes -- work as expected

Next.js on non-Vercel platforms -- what changes:

Incremental Static Regeneration (ISR): This is Vercel's headline feature, and it does not work the same way on other platforms. Pages are either fully static or fully dynamic. If you rely heavily on ISR, you will need to restructure those pages to use either full static generation with on-demand revalidation, or server-side rendering with caching headers. For most applications, this means adding Cache-Control headers rather than relying on ISR's revalidate timer.
V8 isolates vs Node.js runtime: Edge platforms run JavaScript in V8 isolates rather than Node.js. This means npm packages that depend on Node.js-specific APIs (fs, child_process, net, crypto in some forms) will not work. In practice, this affects a small percentage of packages, but check your API routes for Node.js dependencies.
Middleware execution model: Vercel runs middleware before every request, including static assets. Other platforms may run middleware only for dynamic routes. Test your middleware thoroughly, especially authentication checks and redirect logic.
Image optimization: If you use next/image with Vercel's built-in optimizer, you will need an alternative. Options include Cloudflare Images, Imgix, or self-hosted sharp with caching. This is a configuration change, not a code rewrite.

What to do:

Install the platform's Next.js adapter (e.g., @cloudflare/next-on-pages or OpenNext)
Run a local build with the adapter to catch compatibility issues early
Address any Node.js API dependencies in API routes
Replace ISR with appropriate caching strategies
Test middleware behaviour on the new platform
Deploy to a preview URL and test every dynamic route
Run Lighthouse and compare Core Web Vitals with your Vercel deployment
Update DNS when satisfied

Step 4: Migrate Your Most Complex App Last

Your most complex application -- the one with the most API routes, the most middleware logic, the most integrations -- migrates last. By this point, you understand the new platform's behaviour, you have solved the common issues on simpler apps, and you have a tested process.

Additional considerations for complex apps:

Serverless function configuration: Timeout limits, memory allocation, and concurrency models differ between platforms. Verify that your functions operate within the new platform's limits.
Database connections: If your functions connect to external databases, ensure connection pooling is configured. Edge platforms benefit from managed connection poolers that reduce the overhead of establishing connections from globally distributed functions.
Webhook endpoints: Any external service that sends webhooks to your Vercel URLs needs updating. Document every webhook sender and update them after DNS cutover.
CI/CD integration: If your deployment pipeline references Vercel-specific APIs or CLI commands, update them.

The Rollback Plan

Every migration step should be reversible. Here is how:

Before DNS cutover:

Both platforms are running simultaneously
The Vercel deployment is still live and serving traffic
You can test the new deployment on preview URLs without affecting production

During DNS cutover:

Set DNS TTL to 60 seconds before making changes (do this 24 hours in advance)
Update DNS records to point to the new platform
Monitor error rates, response times, and Core Web Vitals for 2-4 hours

If something goes wrong:

Revert DNS records to point back to Vercel
With a 60-second TTL, traffic returns to Vercel within minutes
Diagnose the issue on the new platform using preview URLs
Retry the cutover when the issue is resolved

After successful cutover:

Keep the Vercel project active for 1-2 weeks
Monitor the new platform for edge cases that only appear under production traffic patterns
Once confident, delete the Vercel project and cancel unused plans

Environment Variables: The Migration That Matters Most

Environment variables deserve their own section because they are the most common source of post-migration failures.

Export from Vercel: Vercel stores environment variables per-project with environment scoping (production, preview, development). Export all production variables for each project. Vercel's dashboard allows you to view them, but there is no bulk export -- copy them carefully.

Import to the new platform: Set each variable in the new platform's project settings. Double-check:

No trailing whitespace (a common copy-paste error that causes auth failures)
Correct scoping (production vs preview)
API keys and secrets are current (some may have rotated since you last checked)
URLs reference the correct endpoints (some may contain Vercel-specific URLs)

Variables that reference Vercel: Search for environment variables that contain vercel.app, vercel.com, or Vercel-specific values. These need updating:

NEXT_PUBLIC_SITE_URL or similar -- update to your production domain
Webhook URLs registered with third-party services
OAuth redirect URIs in your auth provider (Clerk, Auth0, etc.)

What You Are Not Migrating

This is important: you are not migrating data. Modern frontend architecture is stateless. Your hosting platform stores code, build artifacts, and environment variables. Your data lives elsewhere:

Database: Supabase, PlanetScale, Neon, or wherever your data lives. It does not move.
Authentication: Clerk, Auth0, or your auth provider. It does not move.
File storage: S3, R2, or your object store. It does not move.
Third-party APIs: Stripe, SendGrid, Twilio. They do not move.

The only thing that moves is where your frontend code runs and where your serverless functions execute. This is why the estimated effort is 1-2 weeks, not 1-2 months. You are changing where code deploys, not where data lives.

Post-Migration Verification

After each app migrates, verify:

The Timeline

For a team with 3-5 apps on Vercel:

Phase	Duration	What Happens
Preparation	1-2 days	Inventory, checklist, platform setup
First app (simple)	1 day	Learn the platform, validate process
Static/client apps	1-2 days	Batch migration of simple apps
Server-rendered apps	2-3 days	Next.js compatibility, ISR alternatives
Complex app	2-3 days	Full testing, webhook updates
Monitoring	1 week	Watch production traffic on new platform
Total	1-2 weeks	Plus 1 week monitoring

This timeline assumes one engineer working through the migration. With two engineers, the middle phases can run in parallel.

When to Stay on Vercel

Migration has a cost. Here is when that cost is not worth paying:

Your team is small and your bill is under $100/month. The savings do not justify the engineering time. Revisit when spending crosses $300-500/month.

You are mid-launch. Do not migrate during a critical shipping period. Platform migrations are maintenance work. Ship first, migrate when things are calm.

You depend heavily on ISR and cannot restructure. If your application's architecture fundamentally relies on Incremental Static Regeneration for hundreds of pages, the migration effort increases significantly. It is still possible, but the cost-benefit analysis needs to account for the refactoring time.

Your entire team is deeply invested in Vercel's ecosystem. If you use Vercel Postgres, Vercel KV, Vercel Blob, and Vercel Analytics, you have more to migrate than just hosting. Each storage service needs an alternative, which extends the timeline.

Why Teams Make the Move

Teams migrate from Vercel for predictable, measurable reasons:

Bandwidth costs that grow faster than revenue, especially for image-heavy or media-rich applications
Global performance needs that require more than 20 server regions
Real-time features that should not require a $200-500/month third-party service
Platform capabilities beyond deployment, including business context in serverless functions, managed connection pooling, and integrated AI
Cost predictability, moving from metered billing to flat or predictable pricing

The migration itself is the easy part. The harder part is deciding when to do it. If you are reading this guide, you have probably already decided. Follow the steps, migrate one app at a time, keep your rollback plan ready, and test thoroughly.

Your code is portable. Your data does not move. The only question is where your frontend runs, and that is the simplest thing to change in your entire stack.

Considering a move? WaymakerOS Host provides zero-bandwidth hosting, native WebSocket support, and serverless functions with built-in business context. Explore Host or read the full platform comparison.

Related reading: Use the decision framework for when to switch, understand real costs at scale, or see why your hosting bill doubles when your product succeeds.