Deno joins Cloudflare: two support clocks and a migration job for developers

If your application runs on Deno Deploy, the Deno team's move to Cloudflare creates a migration job, not just another technology headline. The joint announcement published on 9 October sets a new direction for the team. Hosting and runtime maintenance now have different time horizons. Before choosing a destination, establish which part of Deno your service actually depends on.

• Deno says Deploy will operate for another six months before closing; its runtime has a separate year of monthly bug-fix and security releases.
• The team plans to end its own runtime development after that year, while Deno stays open source. JSR will continue, with infrastructure moving to Cloudflare.
• A Workers migration is not automatically a compatible deployment. Inventory the application, test the destination and establish a recovery plan before changing live traffic.

Separate the hosting deadline from the runtime

In Deno's own statement, the team commits to migration support for paying Deploy customers moving to Cloudflare Workers. That is an offer to seek help, not evidence that a particular application's migration is complete. Ask for the arrangements that apply to your account and service. The statement gives relative periods; PING is not substituting an invented exact shutdown appointment.

• Hosted application: identify whether it is on current Deploy, and arrange the transition within its announced operating period.
• Runtime-dependent application: record the Deno version, dependencies and maintenance owner; the team's support period is different from hosting continuity.
• JSR dependency: the registry is continuing. Still record the exact package versions and build requirements your application needs.

Make an inventory before choosing a replacement

For a small team in Lagos, Nairobi or London, the immediate consequence is engineering work that needs an owner and time in the calendar. Start with the public entrypoints, background work, stored data, environment settings, domains and connected services. Record what is actually deployed, not just what the repository's quick-start example describes. Mark each item with the person responsible for checking it.

Read document titles carefully. Deno's migration guide concerns Deploy Classic moving to the newer Deploy platform and carries an earlier July 2026 Classic shutdown notice. It is a different transition from October's announcement about current Deploy. Do not reuse the older guide's deadline or its regional descriptions as the current plan for moving to Workers.

Your inventory should separate code from service dependencies. A JavaScript handler may be straightforward to identify, while a scheduled task, stored queue or database access pattern needs its own examination. Ask which component owns each capability today and which will own it at the destination. Keep unanswered questions visible rather than marking the whole application portable because its source language is supported.

Treat the Workers example as an example

Deno already publishes a Wrangler deployment tutorial. It configures Workers runtime types, a Worker-style request handler and a custom bundle for Deno's module resolution. Those steps demonstrate a documented route for that example. They are not a promise that an existing Deploy service can move unchanged, or that every Deno runtime API exists in the destination.

Build a separate test deployment and write down the expected results before trying it. Include authentication, a data read and write, a failed external request and any background task your product requires. Check who can read logs and change configuration. Use test accounts and non-sensitive records where possible, and keep secrets out of copied troubleshooting notes. These are PING's proposed evaluation steps, not tests we have performed.

The combined self-hosting effort is a roadmap

The Cloudflare post describes combining work from celld and the open-source Workers runtime, workerd, to improve self-hosting. It also acknowledges a current limit: workerd's Durable Objects implementation supports a single instance, rather than a scalable distributed setup. The team promises further announcements. That planned improvement should not be presented as a completed, universal migration system. The post says celld and workerd can already be self-hosted; the new combined, first-class-supported effort is the part still to come.

If running infrastructure yourself is a requirement, ask what you would need to operate now, who maintains it and which capabilities have actually been demonstrated for your workload. Compare an available, supportable arrangement with another available arrangement. Do not compare a running service against a future promise as though both are ready for the same job today.

Make the cutover reversible where possible

Before directing customers to a replacement, agree on the checks that justify the switch, the person authorised to make it and the conditions for stopping. Verify that backups can be restored and decide how writes will be handled during any reversal. Returning a domain to an old endpoint is not enough if the two systems have accumulated different data. Check this with the people responsible for the application.

The practical response is a dated migration record, not panic or a rushed rewrite. Keep the hosting period, runtime maintenance and self-hosting roadmap in separate columns. PING has not migrated or benchmarked a Deno service, and no cost, latency or regional-availability advantage is established here. Follow PING's Innovation desk for the engineering consequences behind platform announcements.