Migration readiness for Cloudflare deployments

CF Ready inspects your repository for Cloudflare Workers runtime blockers and framework-specific migration paths. Migration findings account for 35% of the overall readiness score — see Scoring.

Runtime blockers

The scanner walks up to 500 source files matching **/*.{ts,tsx,js,jsx,mjs,cjs}, excluding node_modules, dist, .next, coverage, .git, build, .turbo, .vercel, and .cf-ready-cache. If your repo has more eligible files, an info finding notes that the scan was truncated.

Module	Severity	What triggers a finding	Workers alternative
`fs`	Blocker	`import`/`require` of `fs` or `node:fs`; calls to `readFile`, `writeFile`, `mkdir`, streams, etc.	R2, KV, D1, or fetch external storage
`child_process`	Blocker	Imports or `exec`/`spawn` usage	Queues, Workflows, or external compute
`net`	Blocker	TCP socket imports	`fetch`, Workers sockets, or Durable Objects
`tls`	Blocker	TLS module imports	Cloudflare terminates TLS at the edge
`cluster`	Blocker	Node cluster module	Workers scale horizontally by default
`worker_threads`	Blocker	Worker thread imports	Durable Objects or parallel `fetch`
Native modules (`.node`)	Blocker	`require('./foo.node')` or ESM import of `.node` binaries	Wasm or external service
`process.env`	Info	Direct `process.env.VAR` reads (not a blocker)	Document vars in `wrangler.toml` / dashboard bindings

Blockers zero out the migration category score. Any open blocker severity finding sets the migration category to 0 and prevents a production-ready status. Resolve or refactor before go-live.

Framework detection

Detection runs from package.json dependencies, config files, and directory layout. Supported frameworks:

Framework	Detection signals	Confidence
`nextjs`	`next` dependency, `next.config.*`, `app/` or `pages/` directories	High when `next` is a dependency
`vite`	`vite` dependency or `vite.config.*`	High / medium
`react-spa`	`react` + `react-scripts` or `react-dom`	Medium
`astro`, `remix`, `nuxt`	Matching framework dependency	High
`express`	`express` dependency	High
`nodejs`	`createServer` patterns in entry files	Medium / low
`static`	HTML files without a JS framework	High / medium
`unknown`	No confident match	Low — legacy migration hints apply

Current hosting is inferred from vercel.json, netlify.toml, wrangler.toml, and similar config files.

Next.js: vinext and OpenNext

For Next.js projects, CF Ready detects App Router vs Pages Router, middleware, and API routes, then recommends a migration path from cf-ready.config.json:

Preferred path (default vinext) — suitable when middleware, heavy API surface, or runtime blockers are absent
Fallback path (default opennext) — suggested when middleware is present, API routes exceed five, or blockers were found

Suggested manual commands (never executed by cf-ready):

npx vinext check
npx vinext init --platform=cloudflare
npm run build:vinext
npx @vinext/cloudflare deploy --dry-run

Middleware triggers a medium-severity finding because edge runtime constraints may differ on Cloudflare.

Other frameworks

Framework	Migration guidance
Vite / React SPA	Cloudflare Pages or Workers Assets static deploy
Express / Node.js	Progressive rewrite toward Hono or Workers-compatible handlers
Astro, Remix, Nuxt	Official Cloudflare adapter documentation
Static HTML	Direct Pages deploy — no runtime blockers expected

Commands

cf-ready scan              # Full scan including migration checks
cf-ready migration-plan    # Write migration-plan.md only
cf-ready inspect --json    # Framework and route detection without scoring

See Examples for Next.js, Vite, and Node.js walkthroughs using the repo test fixtures.