JDK 21 on SAP Commerce Cloud: What Changes, Who It Affects, How to Get There

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.

What the Framework Update Actually Changes

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.

Backend changes

• 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.

• Spring Framework moves to 6.2, and Spring Security is upgraded to the current 6.x line — replacing Spring Security OAuth, which reached end-of-life in 2022. Bean definitions, security filter chains, and MVC path-matching behavior all change.
• Namespace migration from javax.* to jakarta.* is mandatory across custom extensions. Servlet, JMS, persistence, validation, and mail APIs are all affected.
• OAuth is replaced with a re-implementation built on Spring Authorization Server. Legacy /authorizationserver flows and client configurations require migration (SAP KBA 3641255).
• Drools is upgraded from 8.x to 10.x to align with Jakarta EE APIs (Spring 6 is incompatible with Drools 8); rule authoring and KIE session usage patterns change.
• Legacy cockpit extensions were removed in Q3 2025 — including cockpit, admincockpit, cmscockpit, productcockpit, and the subscription/bundle cockpit extensions. Any customization still bound to these must migrate to Backoffice.
• Deprecated password encoders were fully removed as of release 2211.47 / 2211-jdk21.5 — including PBKDF2WithHmacSHA1SaltedPasswordEncoder, MD5PasswordEncoder, SHA1PasswordEncoder, and PlainTextPasswordEncoder. SAP later added automatic rehashing on login for storefront customers using currently supported algorithms (Argon2, bcrypt, scrypt) — but this does not cover employee/back-office users, who need a separate migration plan.
• PathPatternParser becomes the default in Spring MVC 6. Legacy Ant-style wildcards (/**/segment, {*path}) either need an AntPathMatcher fallback or a rewrite of the mappings.

Frontend changes

• 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.

• Any composable storefront version earlier than 221121.1 is ineligible for go-live once the deadline passes — new builds on unsupported storefront versions are blocked by Cloud Portal.
• Node.js 20 reaches end of support on April 30, 2026. Composable storefront SSR and build tooling must run on Node.js 22 or later (Node.js EOL schedule; SAP KBA 3439260).
• Angular was upgraded from 19 to 21 in the February 2026 release of composable storefront. Customers still on the pre-February build face a combined framework-and-storefront upgrade.
• Accelerator (JSP-based) storefronts remain supported through Q3 2028 but continue to accumulate technical debt. Framework Update customers on Accelerator should still put a composable storefront migration on the roadmap, even though it isn't on the critical path for JDK 21.
• Each major Spartacus release typically bumps the underlying Angular version, so an old Spartacus library usually means an old, unsupported Angular version.
• New SAP Commerce Cloud capabilities are increasingly gated to a compatible Spartacus version.
• Authorization Code Flow became the default authentication method in the March 2026 composable storefront update (authorizationCodeFlowByDefault). If you cross that release, verify your custom login and CSRF handling still behave as expected.

Upgrade Scenario: On Version 2211 with JDK 17

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.

What's in your favor:

• Already being on the 2211 code line means no data model migration, no ImpEx breakage from a version jump, and no Solr schema upheaval.

• SAP publishes OpenRewrite recipes (SAP KBA 3618495) that automate a large share of the javax-to-jakarta rewrites, Spring configuration updates, and dependency version bumps.
• Composable storefront customers on 2211.x can upgrade to 221121.1 without changing backend version — the same storefront release is compatible with both JDK 17 and JDK 21 backends, so frontend and backend work can be sequenced independently.
• The August 2025 JDK 17 update had its validity extended from six to twelve months specifically to give this cohort time to plan.

What still requires manual work:

• 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.

• Dependencies declared in external-dependencies.xml without an explicit version can break the Ant/Gradle target in the JDK 21 build. Every dependency needs a version tag.
• The password encoder removals will break authentication for any user whose hash was stored under a now-removed encoder. A rehash-on-next-login strategy (with a separate plan for employee users) needs to be designed before cutover.
• Third-party integrations — payment providers, tax engines, marketing platforms — that were pinned to older Spring or Jakarta versions need their own compatibility validation.

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.

Upgrade Scenario: On Version 2205 or Earlier

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.

Stage 1: 2205 to 2211

• 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.

• Upgrading from 2205 to 2211 requires reviewing the migration guide for removed and deprecated extensions, data model changes, ImpEx behavior changes, and OCC API version alignment.
• Customers on composable storefront 6.0 running against 2205 had their support end on May 18, 2024, aligned with Angular 15's end-of-life. These customers are already on unsupported infrastructure and need to upgrade the storefront in tandem (SAP KBA 3435022).
• Accelerator storefront customers on 2205 can defer the frontend rewrite, but shouldn't — the platform upgrade itself will surface enough friction that bundling in a composable storefront migration is often the more cost-effective sequence.

Stage 2: 2211 to JDK 21

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

Prescriptive Upgrade Steps

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.

Step 1 — Discovery and impact assessment

1. 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.

2. Run a dependency audit against external-dependencies.xml and all extension build files. Flag any dependency without an explicit version — these will fail the JDK 21 Ant/Gradle target.
3. Identify all usages of removed cockpit extensions and the deprecated password encoders. Produce a migration list.
4. For composable storefront customers, capture the current Angular version, Node.js version, and storefront version. Compare against the target: composable storefront 221121.1 or later, Node.js 22, Angular 21.
5. For customers in the second scenario, add a version-gap analysis: what sits between the current release and 2211.latest — deprecated extensions, data model deltas, API removals.

Step 2 — Environment and CI/CD preparation

1. 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.

2. Add a parallel CI/CD pipeline targeting the JDK 21 build. Keep the JDK 17 pipeline running alongside it during the migration.
3. Ensure external-dependencies.xml declares an explicit version for every dependency — a missing version causes the JDK 21 Gradle scan to fail.
4. Add OpenRewrite tooling to the developer workstation setup so recipes can be re-run on each branch as fixes are merged.

Step 3 — Apply OpenRewrite recipes on the backend

1. 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.

2. Compile after each recipe run. OpenRewrite is deterministic but doesn't guarantee a compiling result on the first pass in every codebase.
3. Review recipe output for false positives — imports legitimately using javax that should remain, or Spring configuration the recipe rewrote incorrectly.

Step 4 — Manual backend fixes

1. Rewrite custom OAuth clients and any authorization-server extensions against the new OAuth implementation described in the SAP Help Portal migration guide.

2. Migrate Cockpit-based customizations to Backoffice widgets. Cockpit is gone, not deprecated.
3. Replace deprecated password encoders. Maintain a compatibility encoder mapping so existing user hashes can be verified on next login and rehashed transparently — and build a separate plan for employee/back-office accounts, which the automatic rehash does not cover.
4. Fix Spring Security 6 intercept-url elements that no longer accept a URL without an access expression.
5. Address Spring MVC path-matching failures by rewriting mappings to PathPattern syntax or explicitly configuring AntPathMatcher in spring-mvc-config.xml.
6. Rebuild Drools rulesets against Drools 10 syntax; retest all rule execution paths.
7. Resolve duplicate controller mappings and JSP model binding errors surfaced by the stricter Spring 6 validation.

Step 5 — Frontend track (composable storefront customers)

Scenario A: You're on 221121.x with Angular 19 (pre-February 2026 build)

1. 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.

2. Confirm whether you're crossing the Angular 19 → 21 boundary. If your current patch predates February 2026, plan for an Angular major upgrade as part of this track.
3. Upgrade Angular: ng update @angular/core@<target-major> @angular/cli@<target-major>.
4. Update the Spartacus libraries: ng update @spartacus/schematics@<target-version>.
5. Run the Spartacus migration schematics from the step above — they handle most breaking API/config changes automatically.
6. Review the migration notes for your target version on the SAP Help Portal for anything the schematics don't auto-fix: config renames, deprecated modules, CSS/selector changes.
7. Rebuild, run your test suite, and smoke-test key flows — login, cart, checkout, and ASM if you use it. There are known post-upgrade issues around ASM/authentication on the JDK 21 branch, so test that path deliberately.
8. Confirm the paired backend version. SAP's guidance is to keep composable storefront aligned with the same backend update release, so verify your 2211-jdk21.x backend patch is compatible with the storefront patch you land on.
9. Check the authentication flow change: the March 2026 update enabled authorizationCodeFlowByDefault. If you cross that release, verify your auth setup still behaves as expected.
10. Test SmartEdit, ASM modules, and CSS styling closely — these are the areas most prone to breaking between versions.

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.

1. Confirm current and target versions from package.json against the current supported release list on the SAP Help Portal.

2. Verify Node.js 22 is in place (required since Node 20's support ends April 30, 2026) — this becomes a check, not an upgrade.
3. Skip the Angular update command — no ng update @angular/core needed since the major version stays the same.
4. Run ng update @spartacus/schematics@<target-version>. This still applies to patch/minor-level migrations — even non-major releases can carry config tweaks or small breaking fixes.
5. Review the migration/fixed-issues notes for the specific patches between your current and target version. Minor releases can ship notable behavior changes — authorizationCodeFlowByDefault (March 2026) is a good example of a change that wasn't tied to an Angular bump.
6. Rebuild and smoke-test key flows — login, cart, checkout, and ASM — since there are known post-update quirks on this line.
7. Confirm your 2211-jdk21.x backend patch is compatible with the storefront patch you're moving to.

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.

Step 6 — Validation and cutover

1. 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.

2. Load-test the JDK 21 environment. Java 21 virtual threads can materially change concurrency behavior for I/O-bound workloads — confirm sizing before production.
3. Perform a dress-rehearsal deployment through Cloud Portal targeting a staging environment on 2211-jdk21.latest.
4. Plan the production cutover during a low-traffic window. The Cloud Portal deployment itself is standard, but the first startup can surface issues that only appear under production data volume.
5. Decommission the JDK 17 pipeline once production is stable on JDK 21. Keep the pipeline definition in source control for rollback rehearsal only.

FAQs

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.

Conclusion

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

• SAP Help Portal — Framework Update: Java JDK 21 and Spring 6.2
• SAP KBA 3653999 — Information about JDK 21 Upgrade
• SAP KBA 3618495 — OpenRewrite recipes for JDK21 Framework Update adoption
• SAP KBA 3641255 — Moving to the New OAuth Implementation in Commerce Cloud JDK 21
• SAP KBA 3439260 — Node.js & Angular Policy for 2211.19+ Composable Storefront
• SAP KBA 3435022 — Composable Storefront versioning alignment with Commerce Cloud
• Node.js — End-of-Life schedule
• Knack Systems — SAP Commerce Cloud Version Upgrade

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.