Migrate from Deploy Classic

Deno's official documentation lists 2026-07-20 as the shutdown date for Deploy Classic and Subhosting v1. That date has passed. If any Classic resource remains, do not assume it was migrated automatically—confirm its status in console.deno.com and current official status, then follow this inventory.

It is not an in-place upgrade

• Classic projects do not automatically become new apps; the new platform requires an organization.
• Replace deployctl with built-in deno deploy.
• GitHub integration uses integrated builds; do not preserve assumptions from the old Action workflow.
• Split the single Classic environment set into Production, Development, and Build contexts.
• Reconfigure custom domains while preserving a DNS propagation window.

Code and data differences

- import { serve } from "https://deno.land/std/http/server.ts";
- serve(() => new Response("hello"));
+ Deno.serve(() => new Response("hello"));

• Legacy std serve() can time out during new Deploy warmup. Upgrade dependencies and use Deno.serve().
• Deno.cron() remains available, but recheck UTC, retries, and timeline behavior.
• Classic KV data is not migrated automatically; coordinate with official support and verify integrity.
• New Deploy currently does not support Deno.Kv.enqueue() / listenQueue(); move to an external broker or database job queue.
• Subhosting v1 project/deployment becomes v2 app/revision and requires explicit API/SDK mapping.

Cutover checklist

1. Inventory projects, domains, variables, cron, KV, queues, regions, and Subhosting calls.
2. Create apps in the new organization and verify build/runtime on a non-production timeline.
3. Migrate secrets and contexts without logging their values.
4. Migrate data and background work, then reconcile counts, hashes, or business invariants.
5. Configure certificate challenges and DNS with a rollback window.
6. Verify logs, traces, metrics, alerts, and cost before retiring old resources.

Official sources: Migration guide and About Deno Deploy.