Azure App Service will stop supporting Java 8, 11 and 17 on September 1, 2027. Apps keep running after that date, but they stop receiving security updates and Microsoft stops providing customer support for those runtime versions. It is a routine lifecycle notice with a non-routine amount of work hiding behind it, because those three versions cover a huge share of the Java workloads actually deployed on the platform.
Why the dates line up
The retirement follows Microsoft’s own OpenJDK support roadmap for the Microsoft Build of OpenJDK, which lists September 2027 as the earliest end-of-support date for both the 11 and 17 LTS lines. Java 21 extends to September 2028 and Java 25 to September 2030. Java 8 is a special case: it is not a Microsoft-supported LTS on the same terms, and on Azure it rides on Eclipse Temurin builds from the Adoptium project, which follow their own community timeline.
The same policy text spells out how App Service handles runtimes past end of support: applications continue to run unchanged, but no security patches flow and support requests on those versions go unanswered. The platform’s language support policy is explicit that moving to a supported version is the only way to keep receiving patches.
Azure Functions is caught in the same net
It is not just App Service. Azure Functions lists Java 8, 11 and 17 as generally available only until September 2027 in its supported languages table, with Java 21 supported to September 2028 and Java 25 to May 2029. Teams running Java function apps on the same LTS versions face the same decision on the same clock.
What to actually do about it
Microsoft’s deployment and configuration documentation includes an Azure CLI script that inventories every web app in a subscription and flags any using Java 8, 11 or 17, checking both the javaVersion setting and the linuxFxVersion image string. That script is the right first step. Running it now tells you the real scope: how many apps, which resource groups, which runtimes.
From there the decision tree is short. Most teams should target Java 21, since it buys two extra years of support over 17 and is a mature LTS with the runtime changes already stabilized. Java 25 buys until 2030 if you want to skip a generation, assuming your frameworks support it. Spring Boot, Tomcat and JBoss EAP on App Service all have current releases that run on 21.
The migration itself on App Service is usually a configuration change rather than a code port, since the platform supplies the runtime, but the code compatibility work is on you: libraries that dropped Java 8 support, removed APIs between 8 and 17, and any native dependencies. Testing against the target version before the deadline is the part that takes time, and September 2027 is closer than it looks for teams with a long release cadence.
There is also an escape hatch. If an application genuinely cannot move off Java 8, moving it to a custom container with a community-maintained JDK keeps it running on the platform, though you then own the patching yourself. That is a legitimate trade for a legacy internal app, and a bad one for anything internet-facing.
The deprecation mechanics
Per the platform policy, deprecated runtimes disappear from the create and configure pages in the portal first, while existing apps continue to run. Deployments via Azure CLI, ARM templates or Bicep can still create apps on hidden runtimes during the deprecation window. Full removal from the platform comes later, and subscription owners get an email notice before that happens. Microsoft’s policy also promises at least six months of deprecation notice before any supported runtime is retired.
Support mechanics are worth understanding before you plan. Supported JDKs on App Service get patched automatically on a quarterly basis, in January, April, July and October, so staying on a supported version means patches arrive without action. Pinned patch versions prevent surprise auto-updates in production, which is why the docs recommend pinning for most production apps and testing upgrades deliberately. The same quarterly rhythm applies to the underlying Tomcat and JBoss EAP stacks, and there are supported combinations across Tomcat 8.5 through 11 and JBoss EAP 7.3 through 8, so a runtime upgrade is a matter of picking a tested stack string rather than building your own image.
One caution for the inventory step: the CLI script looks at javaVersion and linuxFxVersion, but apps deployed as custom containers escape that check entirely. If your team runs Java inside its own images on App Service, the notice does not apply to the platform runtime, though the community support math for Java 8 and 11 eventually catches up with any image you build anyway.
The takeaway
This notice landed with almost eleven months of runway, which is exactly enough time to do this calmly and exactly short enough that doing nothing turns it into a fire drill next summer. Run the inventory script this week, count the affected apps, and put the version upgrade on a real schedule. The apps will keep running after September 2027, but running unpatched is not a posture any security team should sign off on.