The Great Migration: A Technical Deep Dive into Moving from Cloudflare to Vercel

Cloudflare is a titan of the edge, but let’s be real: as a developer, you want to spend your time building features, not fighting with wrangler.toml or debugging obscure edge-case routing logic in Workers. Vercel has pioneered the "Frontend Cloud," and for teams that prioritize developer experience (DX), seamless Next.js integration, and a "it just works" deployment pipeline, the move to Vercel is often a natural evolution.

In this guide, I’m going to walk you through the architectural shift. We aren't just moving files; we are shifting a mindset from "Infrastructure-as-Code" to "Framework-as-Infrastructure."

1. The Pre-Migration Audit: Inventorying Your Assets

Before we touch a single DNS record, we need to map out what you’re actually running on Cloudflare. Typically, this falls into three buckets:

1. Static Assets/Sites: Currently in Cloudflare Pages.
2. Serverless Logic: Currently in Cloudflare Workers.
3. Storage: KV (Key-Value), Durable Objects, or D1 (SQL).
4. Networking: DNS, Page Rules, and WAF settings.

Pro Tip: Run wrangler types and inspect your wrangler.toml. This file is your blueprint. Note every environment variable, secret, and binding. You’ll need to recreate these in the Vercel Dashboard or via the Vercel CLI.

2. Transitioning from Workers to Edge Functions

The biggest hurdle is the code logic. Cloudflare Workers and Vercel Edge Functions both run on the V8 engine, but their APIs and execution models differ slightly.

The Cloudflare Way (Service Worker Syntax)

javascriptCopy
1// Cloudflare Worker
2addEventListener('fetch', event => {
3  event.respondWith(handleRequest(event.request))
4})
5
6async function handleRequest(request) {
7  return new Response('Hello from the Edge!', {
8    headers: { 'content-type': 'text/plain' },
9  })
10}

The Vercel Way (Middleware/Functions)

On Vercel, if you are using Next.js, your "Workers" become "Middleware" or "Edge API Routes."

typescriptCopy
1// middleware.ts (Vercel/Next.js)
2import { NextResponse } from 'next/server'
3import type { NextRequest } from 'next/server'
4
5export function middleware(request: NextRequest) {
6  return new NextResponse('Hello from Vercel Edge!', {
7    headers: { 'content-type': 'text/plain' },
8  })
9}
10
11export const config = {
12  matcher: '/api/:path*',
13}

Key Difference: Vercel’s routing is file-system based. You don’t need to write complex switch statements inside a single Worker to handle different endpoints. You simply create files in the /api directory.

3. Handling the Data Layer: Beyond KV and D1

Cloudflare KV and D1 are proprietary to their ecosystem. When you move to Vercel, you have two primary paths:

Option A: Vercel Native Storage

Vercel offers Vercel KV (powered by Upstash), Vercel Postgres (powered by Neon), and Vercel Blob. These are optimized for the Vercel platform and offer a similar "serverless" billing model.

Option B: The Agnostic Path

If you want to keep your data layer independent, I recommend moving KV data to Upstash Redis and D1 data to Neon (Postgres) or PlanetScale (MySQL).

Pro Tip: If you are migrating a large KV store, write a simple migration script using the Cloudflare API to fetch all keys and the Upstash REST API to SET them in your new instance. Don't do this manually; the edge cases in pagination will haunt you.

4. Environment Variables and Secrets

Vercel handles environment variables with much more grace than Cloudflare. Instead of manually uploading secrets via a CLI for every environment, Vercel allows you to manage them via the UI or the vc env command.

When migrating, create a .env.production file locally (and ensure it's in your .gitignore!) to stage your variables, then push them:

bashCopy
1vercel env add MY_SECRET_API_KEY

5. The DNS Cutover: Zero Downtime Strategy

This is where most developers get nervous. If Cloudflare is currently your DNS provider and registrar, you have two choices:

1. Keep Cloudflare as DNS: Move your CNAME records to point to cname.vercel-dns.com. You must disable the "Orange Cloud" (Proxy) for the specific record initially to allow Vercel to verify the SSL certificate.
2. Move DNS to Vercel: This is my preferred method for maximum performance. Vercel’s Anycast network is elite, and having your DNS and hosting in one place simplifies everything.

The "Safe" Cutover Workflow:

1. Deploy to a Vercel Preview URL: Ensure the site looks and acts correctly.
2. Add the Custom Domain to Vercel: Vercel will give you a CNAME or A record value.
3. Lower TTL: On Cloudflare, lower the TTL of your existing records to 300 seconds (5 minutes) at least 24 hours before the move.
4. Update Records: Change the DNS records in Cloudflare.
5. Verify SSL: Vercel will automatically provision a Let's Encrypt certificate once the DNS propagates.

6. Replacing Page Rules with vercel.json

Cloudflare Page Rules are often used for redirects, header manipulation, and caching tweaks. On Vercel, this logic lives in your vercel.json or your framework config (like next.config.js).

Example: Redirecting non-www to www and setting custom headers.

jsonCopy
1{
2  "redirects": [
3    {
4      "source": "/old-blog/:path*",
5      "destination": "/blog/:path*",
6      "permanent": true
7    }
8  ],
9  "headers": [
10    {
11      "source": "/(.*)",
12      "headers": [
13        {
14          "key": "X-Content-Type-Options",
15          "value": "nosniff"
16        }
17      ]
18    }
19  ]
20}

7. Performance Optimization: ISR and Image Optimization

Once you are on Vercel, don't just run your old code. Leverage the platform.

• Incremental Static Regeneration (ISR): If you were using Cloudflare Workers to fetch and cache HTML, switch to ISR. It allows you to update static content after you've built your site, without needing a full redeploy.
• Vercel Image Optimization: Stop resizing images manually or using Cloudflare Polish. Use the Next.js <Image /> component, which Vercel optimizes on the fly at the edge.

Final Thoughts

The migration from Cloudflare to Vercel is more than a hosting change; it’s an upgrade to your development workflow. You’re trading manual configuration and "plumbing" for a high-level abstraction that lets you ship faster.

In my experience, the initial "friction" of rewriting a few Workers into Next.js Middleware pays for itself within the first week of deployments. The preview deployments alone—where every git branch gets its own URL—will change the way your team reviews code.

Welcome to the Frontend Cloud. Now go build something incredible.