Platform migrations rarely fail because the new platform cannot serve your code. They fail because the current platform was quietly handling more than the team wrote down. Custom domains, preview behavior, redirects, feed paths, image assumptions, and logging habits are usually the real migration surface.

Use the deployment and hosting unit page as the index for narrower platform guides. If you need the baseline first, start with the rules you should fix first. If your decision is still at the platform-comparison stage, continue with Cloudflare Pages vs Vercel.

1. Lock public surfaces before you compare features

Your domain behavior matters more than the platform feature list. List the current live assumptions first: custom domains, HTTPS enforcement, trailing slash policy, robots.txt, sitemap URL, RSS URL, public asset paths, and any redirect rules that users already depend on.

If the target platform changes even one of those by accident, the migration is already carrying more risk than the team thinks.

2. Separate build assumptions from runtime assumptions

Many teams say “the build works” and stop too early. That only covers one layer. You still need to list which assumptions belong to build output and which belong to runtime behavior.

• Build layer: output directory, asset path rules, image optimization, static export assumptions
• Runtime layer: environment variables, serverless behavior, rewrites, redirects, preview auth, log access

If those two layers are mixed in one vague checklist, the migration will be harder to debug when something breaks after cutover.

3. Do not move domains before you verify the generated output

A safe sequence is boring on purpose. First verify the generated build. Then verify the public output on a temporary URL. Only after that should the main domain move.

That means checking the real public behavior of pages, feeds, sitemap, redirects, and assets on the target platform before you cut over DNS.

4. Environment variables should be rewritten as a dependency list

Do not copy environment variables blindly. Rewrite them as a dependency list instead: which feature needs which variable, what breaks when it is missing, and whether the variable belongs to build time or runtime.

That simple rewrite catches the common mistakes: missing analytics keys, broken auth callbacks, wrong origin URLs, stale webhook endpoints, or secrets copied into the wrong environment.

5. Write the rollback before the cutover

If rollback is still “we will switch back if needed,” then rollback does not exist yet. Write the exact rollback boundary: which domain record changes back, which deployment remains available, which environment variables stay untouched, and how long you will observe the new platform before calling the move complete.

A good rollback plan should let one person revert the public surface quickly without having to rediscover the old settings under pressure.

What to do first

Open a blank checklist and write six groups only: domains, environment variables, build output, redirects, logs, and rollback. Fill those groups using your current live system before you compare platform features. If you cannot fill that sheet clearly, the migration decision is still early.