Cloud Services (extended support) retires 2027-03-31. Microsoft ships no migration tool and grants no extensions.

This is the last stop for web and worker roles. The price per VM does not change; the shape of the bill does. And you can no longer spin up a fresh copy to rehearse on.

The dates

• "As of March 31, 2025, cloud Services (extended support) is deprecated and will be fully retired on March 31, 2027." (Microsoft Learn)
• "Unfortunately, we can't grant extension requests" (migration FAQ).

What is not carried over

Two source classes, never blurred: the vendor's own docs are authoritative; community reports are real, dated and linked, but not vendor-confirmed, and they are labelled that way.

From the vendor's published docs

• "there's no one-click migration tooling available. Each application must determine how its code runs on the VM/node and make custom adjustments accordingly." (FAQ)
• On the Service Fabric managed cluster Microsoft points to: "Manually making changes to the resources in a managed cluster isn't supported." (overview)
• Role lifecycle, Key Vault certificates wired through the role profile, RDP and diagnostics extensions, and the .cspkg/.cscfg deployment model all need a new home. None of them carry over.

The price trap

• Microsoft: no rate change for the same VM size. The catch is the minimum footprint: a managed cluster needs at least 3 nodes on Basic (no zone redundancy) and 5 on Standard (source).
• A typical two-instance web role moving to a production-grade Standard cluster runs on at least five VMs: about 2.5x the VM-hours at the same size, before any worker roles.
• Other targets (App Service, Container Apps) avoid the node minimum but mean a larger code change for .NET Framework roles.

Reported by users, not confirmed by the vendor

• New dev/stage deployments are already refused: BadRequest: Cloud Services (extended support) will be retired on 31 March 2027 (2025-07-28, unresolved). You cannot rehearse on a fresh copy.
• "it's simply not possible to change a app architect to what Microsoft is asking by next year": an ASP.NET 4.8 Web Forms application (2025-05-19, unresolved).
• Retirement notice received, no migration route (2025-08-05, unresolved).

Check your own setup

Zero dependencies and offline: it reads a Resource Graph export you produce. It never asks for, stores or transmits a credential: you run it with your own login, and nothing leaves your machine.

az graph query -q "resources | where type =~ 'microsoft.compute/cloudservices' | project name, resourceGroup, location, properties" --first 1000 -o json > cses.json
node check.js cses.json
node check.js --demo

The part nobody checks

Because new Cloud Services deployments are refused, the usual rehearsal (clone production, migrate the clone) is gone. The replacement has to be proven on its own terms: the same requests answered, the same queues drained by the worker roles, the same certificates served, under production-like load, before DNS moves. Plan that verification before the code change, not after it.

If you would rather not do it yourself

We take this on as fixed scope, and we will say plainly that you would be among our first customers for this particular engagement. What we bring is the breakage map above and a hard habit of proving the new setup works rather than assuming it.

• Re-hosting audit, fixed price. We run the checker, read the roles and their dependencies, and hand back a target per role (managed cluster, App Service or Container Apps) with the VM-hour and code-change trade-off, and a cutover plan that does not need a fresh Cloud Services copy.
• Re-host and verify, fixed price quoted by email on role count. We move the roles, re-plumb certificates, diagnostics and deployment, and prove request-for-request and queue-for-queue parity before cutover.