List the bindings, not the products
For each Worker, write down what it binds: D1, KV, R2, Queues, cron triggers, Vectorize. That binding list is the migration scope; products you once trialled and never bound are not.
Declare the project in stack.json
Workers become nodejs workers, Pages output becomes a gateway prefix route, KV and D1 become tables, R2 becomes buckets, and cron becomes workflows. Review the kernstack plan with the team.
Export data and rebuild indexes
Load KV pairs directly into tables, export D1 and reshape rows under declared keys, and copy R2 objects into buckets. Declare vector indexes over the loaded data and re-embed from source records.
Cut over hostname by hostname
Move one hostname or path to the KERNSTACK gateway at a time while the rest stays on Cloudflare. Retire Workers and bindings as their traffic reads zero; keep Cloudflare in front only if the edge still earns it.
Piece by piece, because there is no single Cloudflare system to export
A Cloudflare application is a set of bindings across separate products, so the migration is an unbinding. Workers code is JavaScript or TypeScript, and it becomes container workers with the nodejs runtime — KERNSTACK functions are Go WebAssembly, so Workers code never lands there. Pages sites become built interfaces served by a gateway prefix route. Work that a Worker did in short bursts but a product would rather run long also belongs in workers, free of isolate CPU limits.
Data splits by product. KV is already key-value, so it loads into tables almost mechanically. D1 is SQLite: export the tables, read them as access patterns, and reshape rows under explicit keys — the SQL does not come along. R2 is S3-compatible, so objects copy into buckets with standard tooling such as rclone. Vectorize indexes are rebuilt as vector search indexes over the new tables and buckets, re-embedded from source records.
- Durable Objects have no equivalent. Coordination logic built on them must be redesigned around tables and workflows before that code moves.
- Cron Triggers become workflows; Queues become workflow steps that call workers. The schedule lives in stack.json afterwards.
- Workers AI models map to the inference catalogue or to a custom inference endpoint you declare; model names and prices differ, so re-check quality per model.
The edge question, answered before you start
Leaving Cloudflare means your users reach one European zone instead of the nearest of hundreds of edge locations. For a European product with European data obligations that is usually the point of the move. For a global consumer product where intercontinental latency is the experience, it is a reason to stay — or to keep Cloudflare DNS and caching in front of the KERNSTACK project during and after the transition, which teams do regularly.
Cut over route by route: point one hostname or path at the new project while the rest still terminates on Workers. The old bindings retire hostname by hostname, and nothing about the move requires a flag day.
Resource-by-Resource Mapping from Cloudflare
- Workers (JavaScript, TypeScript) →
workers (nodejs): Edge isolate code becomes container workers — real processes without CPU-time shaping. Go code, if any, can become functions instead. - Pages →
gateway prefix route: The built site is served by the project. Add cdn_enabled to the route where cached delivery is needed. - KV →
tables: The natural fit: keys and values load as they are. Per-key reads and writes carry the same mental model. - D1 (SQLite) →
tables: Export rows and reshape under explicit keys. SQL queries become keyed reads or a declared search index; joins do not translate. - R2 →
buckets: R2 is S3-compatible, so standard sync tools copy objects directly. Browser uploads switch to presigned URLs from your workers. - Queues and Cron Triggers →
workflows: Queued and scheduled work becomes declared workflow steps calling workers — reviewed in the same plan as the code it runs. - Vectorize →
vector-search indexes: Declare a vector index over tables and buckets and re-embed from source. The copied vectors themselves are disposable; the source records are the asset. - Durable Objects →
no direct equivalent: Stateful coordination objects must be redesigned around tables and workflow steps. Budget design time for any Worker that leans on them.
Frequently asked questions
You leave the global edge network — that is the real cost of this move, and for some products it settles the question the other way. Gateway prefix routes can be CDN-enabled, and nothing stops you keeping Cloudflare in front of the project for delivery while the application itself consolidates onto KERNSTACK.
The parts that do not touch Durable Objects move normally. The coordination built on them needs redesign — usually into table records plus workflow steps — which is design work, not export mechanics. Read those Workers first; they set the timeline.
A Worker-plus-KV application is days. Add D1 reshaping, a Vectorize rebuild, or Durable Object redesign and it becomes weeks. The binding inventory from step one predicts the effort better than any estimate on this page.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.