Deno Deploy Classic Shuts Down July 20: What Silently Breaks and How to Migrate in Time

If you're running anything on Deno Deploy Classic (dash.deno.com), you have until July 20 to either migrate or watch your deployments go dark. That's three days from today.

The official docs frame this as a straightforward platform upgrade. It's not. There are several ways your migrated app can appear to work on the new platform (console.deno.com) while silently dropping workloads — and at least one breaking API change that never throws.

Here's what actually breaks, what you need to do right now, and the one decision you cannot undo.

What Classic Had That New Deploy Does Not

The two platforms share a name but not a feature set. New Deploy is cleaner, built around modern Deno APIs, and will presumably grow back to parity eventually. But today — the day you need to migrate — it's missing things your code might rely on.

The Queue API Is Gone and Fails Silently

Classic shipped a built-in queue API. New Deploy does not. The nasty part: if your code calls queue.push() after migration, it doesn't throw. The job gets dropped without an error, your health checks pass, and you find out in production when work never happened.

If you were using Classic's queue for background jobs — sending emails, processing uploads, fanning out webhooks — you need a replacement before you migrate. The cleanest path is Deno Queues built on Deno KV. If you already have a queue elsewhere (Cloudflare Queues, SQS, BullMQ on Redis), just call it directly from your request handler.

Silent data loss has a way of staying hidden until a user complains. Don't assume you'll catch it quickly.

serve() Is Not Deno.serve()

Classic supported the legacy serve() function imported from the standard library. New Deploy doesn't. If your entry file looks like this:

import { serve } from "https://deno.land/std/http/server.ts";

serve((req) => new Response("ok"));

Swap it for the built-in API:

Deno.serve((req) => new Response("ok"));

Grep your whole codebase for from "https://deno.land/std/http/server.ts" before migrating. Small change per file, easy to miss when you're in a hurry.

deployctl Is Retiring Too

The deployctl CLI that most CI/CD pipelines relied on is retiring alongside Classic. The replacement is the deno deploy subcommand built directly into the Deno runtime. Update your pipeline scripts before the deadline — deployctl commands stop working the same day the platform goes down.

The Region Regression Nobody Mentioned

Classic served from six PoPs: US, EU, Brazil, Singapore, Tokyo, and Sydney. The new platform currently has two: US and EU.

If your users are in Asia-Pacific, expect a latency regression. There's no workaround today — you'd need to front it with a CDN that caches your responses. Deno says more regions are coming; no public timeline.

Migrating: The Steps That Aren't Optional

Nothing transfers automatically. You do all of this by hand:

• Create a new organization at console.deno.com — **pick the name carefully, you cannot change it later**

• Create a new app and reconnect your GitHub repository

• Re-enter every environment variable manually (none transfer)

• Update your entry point from serve() to Deno.serve()

• Remove or replace any queue code before deploying

• Update CI pipelines from deployctl deploy to deno deploy

• Reconnect your custom domains

KV Data Requires an Email

Deno KV is available on the new platform, but your existing Classic KV data does not migrate automatically. Email [email protected] and request help moving your KV database. Do this now, not the day before — there's no indication they can turn this around in hours.

The Name You Can't Take Back

Your organization name on the new platform cannot be changed after creation. Under a hard deadline, this is a real foot-gun — you type something that seems fine in the moment and end up with a production URL that looks like a typo for years.

Decide on the name before you open the dashboard. If your Classic subdomain was username.deno.dev, try to claim the same one. Classic and new Deploy don't share namespaces, so it's first-come, first-served.

If You're Out of Time

Three days isn't enough for a careful migration if your app has queue jobs, KV data, or a tuned CI pipeline. The pragmatic playbook:

• Get the app deploying to the new platform in any state

• Cut over DNS once it's live, even if some features are broken

• Fix queue replacement, KV migration, and deployctl updates in the next sprint

A broken-but-deployed app keeps your domain alive. An unmigrated Classic project after July 20 becomes a dead URL with no automated recovery path.

Check your list now, not over the weekend.