Azure Stack Hub App Service: Install Window Closed, 2029 Is the Decoy

The date everyone was watching passed quietly last week. As of September 30, 2026, you can no longer stand up a new App Service deployment on Azure Stack Hub. The retirement notice frames this as the gentle first step before the real event—full retirement on September 30, 2029, when updates, new features and support all stop. Three years of runway. Plenty of time.

That framing is the thing worth pressure-testing. Because the load-bearing claim in Microsoft’s notice—”existing supported deployments continue through 2029″—is technically true and practically misleading.

Does “supported through 2029” mean “safe to run until 2029”?

Not in the way the calendar suggests. “Supported” here means Microsoft keeps the lights on: the resource provider stays serviceable, you can patch within the bounds of the Azure Stack Hub update cadence, and you can open a ticket. What it does not mean is that the product moves forward. New runtime stacks, security-relevant platform features, and parity with public Azure App Service effectively froze at the last shipped version. You are running a product that is now in managed decline.

For most workloads that’s survivable. For the workloads that actually land on Azure Stack Hub—regulated, air-gapped, sovereign—a frozen PaaS runtime is a slow-motion compliance problem. The TLS libraries, the language runtimes, the base images: all aging on a fixed clock while your auditors keep moving.

So is 2029 the deadline? No.

Your real deadline is whichever comes first: the end of support for the language runtime your apps depend on, your next hardware refresh or stamp decommission, or the audit cycle that flags an unsupported platform. Any of those can land well before 2029. Procurement and architecture decisions for sovereign estates run in multi-year cycles—if migration isn’t funded in the next planning round, you are already behind.

The September 2026 cutoff bites sooner than people expect, too. It’s not just greenfield projects. It’s your ability to rebuild a stamp from scratch, to stand up a parallel test environment, or to add App Service capacity to an existing region. That capability is gone now. Build and dev/test teams relying on it needed an alternative last month.

What’s the actual blast radius, and what’s in it?

Start by finding out what you’re defending. From the Azure Stack Hub admin portal, the App Service resource provider blade lists deployment status, version, worker tiers and quota. From PowerShell, against the tenant subscription:

1
2
3
4
5
6
7
8
9

# Inventory every App Service-managed resource across tenant subscriptions
Get-AzResource -ResourceType 'Microsoft.Web/sites' |
  Select-Object Name, ResourceGroupName, Location, Kind |
  Sort-Object ResourceGroupName |
  Format-Table -AutoSize
​
# App Service Plans and their SKUs — your capacity and cost picture
Get-AzResource -ResourceType 'Microsoft.Web/serverfarms' |
  Select-Object Name, ResourceGroupName, Sku, Location

Pair that with the admin-side App Service resource provider version so you know exactly which frozen build you’re on. Capture app settings, custom domains, certificates and deployment slots now—those are the migration-cost multipliers nobody budgets for.

Which exit actually survives the sovereignty constraint?

Three options, and the constraint that usually decides it is the reason you chose Azure Stack Hub in the first place: data can’t leave the boundary.

• Direct to public Azure App Service. Cleanest technically, dead on arrival for genuinely sovereign or air-gapped workloads. If a subset of apps never actually needed on-prem residency, move those and shrink the problem. Be honest about which ones.
• Azure Arc-enabled Kubernetes + the App Service extension. The closest thing to a like-for-like PaaS experience that stays on your hardware. You bring the Kubernetes cluster (AKS on Azure Stack HCI, or your own), project App Service, Functions and Logic Apps onto it via Arc, and keep the control plane connected to Azure. It is not a lift-and-shift—you’re adopting and operating Kubernetes, which is a real skills and platform-engineering commitment. But it preserves the developer contract.
• Re-platform to containers or VMs. The pragmatic floor. Containerize the apps, run them on AKS or plain VMs, rebuild the CI/CD yourself. More work up front, fewer surprises later, and no dependency on any single managed PaaS surviving the next retirement notice.

There is no turnkey migrator. Microsoft hasn’t promised one, and assuming it will show up is how 2029 becomes 2028-in-a-panic.

Stop treating 2029 as the clock. The install window is already shut, and the only variable you still control is how many planning cycles you spend pretending otherwise.