SAP has set a hard cutoff of August 31, 2026, after which new builds targeting Java 17 are blocked in the Cloud Portal.
In September 2025, SAP released version 2211-jdk21.1 of SAP Commerce Cloud, a Framework Update that raises the platform from JDK 17 to JDK 21 and moves the Spring Framework from the 5.x/6.0 line to 6.2. This is not an incremental patch. It touches the runtime, the OAuth stack, Drools, the entire javax to jakarta namespace, and, for customers on composable storefront, the Node.js and Angular versions of the frontend. (SAP Help Portal)
SAP has set a hard cutoff of August 31, 2026, after which new builds targeting Java 17 are blocked in the Cloud Portal. Security fixes for JDK 17 ended at the close of Q2 2026, and SAP's own recommended completion date was June 30, 2026. As of this article's July 2026 publication date, less than two months remain. Customers who haven't started an upgrade need to move now.
This article covers what changes on the backend and frontend, walks through two common customer starting points — 2211 on JDK 17, and 2205 or earlier — and lays out the step sequence Knack Systems uses on Framework Update engagements, plus answers to the questions we hear most often from customer teams.
The Framework Update is three simultaneous upgrades — runtime, Spring, and dependent libraries — plus a frontend track that composable storefront customers must run in parallel. None of this is optional for cloud customers who need to keep deploying past August 31, 2026.
Java runtime moves from JDK 17 to JDK 21 (LTS). Bytecode, garbage collector defaults, and access to reflective APIs all shift; virtual threads become available for I/O-bound workloads.
Composable storefront 221121.1 (released September 2025) is the aligned frontend release that supports both the JDK 17 and JDK 21 backend lines during the transition window. It initially shipped on Angular 19.
This is the most common starting point today. The customer is already on 2211 (typically 2211.30 through 2211.44), running JDK 17, and receiving monthly update releases. The path to JDK 21 is a single Framework Update, not a version migration.
Already being on the 2211 code line means no data model migration, no ImpEx breakage from a version jump, and no Solr schema upheaval.
OpenRewrite handles common patterns but not custom OAuth flows, custom Spring Security filter chains, JSP model bindings, or bespoke Drools rules — these need manual inspection and fixes.
Effort involved: For a mid-complexity 2211 project — one Accelerator or composable storefront, five to fifteen custom extensions, two to five integrations — a Framework Update engagement typically runs eight to fourteen weeks from kickoff to production go-live, including regression testing. Platforms with bespoke OAuth or custom Drools rulesets should plan for the upper end of that range.
If you're on 2205, 2105, or earlier, this is a fundamentally different exercise. Before adopting the JDK 21 Framework Update, you must first reach the 2211 code line. This is a two-stage program — version upgrade first, framework update second — and both need to finish before August 31, 2026.
Version 2205 was the last release on the pre-2211 code line; 2211 introduced the Continuous Innovation model with monthly update releases and a rolling six-month validity window.
Once on 2211 (JDK 17), the customer joins the upgrade path described in the previous scenario. Recurring manual fixes documented across public case studies of 2205-to-JDK-21 upgrades include Spring MVC URL mapping, Spring Security intercept-url configuration, JSP model attribute binding, and the password encoder replacements. These are predictable and can be planned for in advance.
Effort involved: A 2205-or-earlier customer should plan for a program in the range of sixteen to twenty-six weeks, depending on customization depth, storefront choice, and integration surface. Given the August 31, 2026 cutoff, customers who haven't started this program by mid-2026 should run the 2211 upgrade and the JDK 21 update as overlapping streams rather than sequential ones, and freeze non-essential feature work for the duration.
Knack Systems has run this exact sequence for customers moving off end-of-life releases — including a North American building materials company we took from SAP Commerce Cloud 1905 straight through to 2211. See how we scope and run these programs
The following sequence is what Knack Systems uses on Framework Update engagements. It applies to both scenarios above — customers in the second scenario run an additional version-upgrade sub-project before entering the JDK 21 track.
Inventory every custom extension, integration, and storefront in scope. Capture Spring bean count, custom Spring Security config, custom OAuth clients, Drools rulesets, and Cockpit-based customizations.
Stand up a JDK 21 development environment: JDK 21 LTS, Ant/Gradle versions aligned with 2211-jdk21.1, and an IDE (IntelliJ or Eclipse) configured for JDK 21 language level.
Following SAP KBA 3618495, run SAP's OpenRewrite recipes across the custom extension tree. Commit results in isolated, reviewable chunks — javax-to-jakarta, Spring configuration, Spring Security, dependency versions.
Rewrite custom OAuth clients and any authorization-server extensions against the new OAuth implementation described in the SAP Help Portal migration guide.
Scenario A: You're on 221121.x with Angular 19 (pre-February 2026 build)
Upgrade Node.js to 22 first — required for any current 221121.x release regardless of the Angular version, and Node 20 loses support on April 30, 2026.
Scenario B: You're already on Angular 21
The process is the same shape, just lighter — no Angular CLI/core update, and the Spartacus schematics step does most of the real work.
Confirm current and target versions from package.json against the current supported release list on the SAP Help Portal.
It's worth reading the release notes for each patch in between rather than assuming "same major version, no surprises" — SAP does occasionally ship default-behavior changes in minor updates.
Run the full regression suite against the JDK 21 build in a dedicated test environment. Prioritize authentication flows, payment flows, and any integration that was pinned to javax libraries.
What happens if we miss the August 31, 2026 deadline?
New builds targeting Java 17 are blocked in the Cloud Portal after that date. In practice, that means you can't deploy any change — feature, fix, or hotfix — to a JDK 17 environment. Security patching for JDK 17 already stopped at the end of Q2 2026.
Do the backend and frontend upgrades have to happen at the same time?
Not necessarily. If you're already on 2211.x, composable storefront 221121.1 runs against both the JDK 17 and JDK 21 backends, so you can sequence the frontend and backend work independently. If you're on an older composable storefront version tied to an unsupported Angular release, that decoupling doesn't apply, and the two tracks should run together.
How long does a Framework Update engagement take?
For a 2211/JDK 17 customer with moderate customization, plan for eight to fourteen weeks. For a 2205-or-earlier customer, plan for sixteen to twenty-six weeks, since the version upgrade to 2211 has to happen first. Both estimates assume a defined scope; heavy custom OAuth, Drools, or Cockpit usage pushes toward the upper end.
We're on 2205 or earlier — can we skip straight to JDK 21?
No. JDK 21 support ships on the 2211 code line, so you need to reach 2211 first. That's a two-stage program, not a shortcut.
Does OpenRewrite handle everything automatically?
It handles a large share of the mechanical rewriting — namespace changes, common Spring configuration updates, dependency version bumps. It does not handle custom OAuth flows, custom Spring Security filter chains, bespoke Drools rules, or JSP model bindings. Those need manual review regardless of code line.
What if we're on Accelerator (JSP) storefront, not composable storefront?
Accelerator remains supported through Q3 2028, so it isn't on the critical path for the JDK 21 deadline. That said, most Accelerator customers find enough friction during the platform upgrade that bundling a composable storefront migration into the same program is usually more cost-effective than doing it later as a separate project.
The JDK 21 Framework Update is the largest technical inflection point SAP Commerce Cloud has seen in several years. For customers already on 2211 with JDK 17, it's a defined, well-tooled exercise — OpenRewrite covers most of the mechanical rewriting, and composable storefront 221121.1 decouples the frontend and backend cutovers. For customers on 2205 or earlier, it's a two-stage program, and the timeline is now the binding constraint.
In both cases, the deciding factor is when the program starts, not how it starts. With the August 31, 2026 cutoff under two months away, discovery and impact assessment should be the highest-priority technical work on your current sprint board.
Not sure where your instance stands, or how long your specific upgrade will take? Talk to Knack Systems about a Framework Update assessment
Sources
This article reflects publicly available SAP documentation and Knack Systems' hands-on Framework Update engagements as of July 12, 2026. SAP update-release timelines are subject to change — always confirm current dates against the SAP Help Portal before finalizing a project plan.