SAP Commerce 2211 Upgrade Readiness Checklist
A practical readiness model for moving legacy Hybris and SAP Commerce landscapes onto 2211-jdk21, now that Commerce Cloud blocks Java 17 builds.
Commerce Cloud Integrations
SAP Commerce engineering team
Architecture, integrations, performance, upgrades, and Composable Storefront on SAP Commerce Cloud.
Moving to SAP Commerce 2211 is rarely a version bump. Most programmes fail because they treat the upgrade as a platform build, a storefront migration, and an integration rewrite at the same time. The work needs a control model that separates platform compatibility, custom extension debt, data movement, storefront risk, and cutover mechanics.
Baseline the Current Landscape#
Start with an inventory that can survive scrutiny from architecture, operations, and release management.
| Area | Evidence to collect | Upgrade risk |
|---|---|---|
| Platform version | Current SAP Commerce patch, Java version, DB version | Unsupported APIs, removed extensions |
| Extensions | localextensions.xml, custom extension graph | Circular dependencies, dead code paths |
| Storefront | Accelerator, Spartacus, mixed storefronts | Template rewrite, OCC contract drift |
| Integrations | Data Hub, hot folders, CPI, custom OCC clients | Batch sequencing, idempotency gaps |
| Operations | Builds, deployments, cronjob windows | Long running jobs, manual release gates |
Do not begin implementation until this baseline is versioned. The first migration failure usually comes from an unowned extension, an undocumented hot folder, or a storefront customization hidden behind a CMS component.
Extension Compatibility#
Review every custom extension against three questions:
- Does it still need to exist in 2211?
- Does it depend on accelerator storefront classes or deprecated platform services?
- Can it be tested without a full web application context?
An extension that cannot be tested in isolation should be treated as migration risk, not normal code.
<extension name="customcheckout">
<requires-extension name="commercefacades"/>
<requires-extension name="commerceservices"/>
<requires-extension name="payment"/>
</extension>
The dependency graph should point toward platform services and facades. If storefront extensions become required by core or integration extensions, the upgrade path will be harder than it needs to be.
Data Migration Controls#
Most SAP Commerce upgrades carry data risk in catalogs, prices, users, orders, promotions, and CMS content. Treat ImpEx and migration scripts as release artifacts, not operator notes.
impex.legacy.mode=false
catalog.sync.workers=8
cronjob.timertask.loadonstartup=false
Run data rehearsals with production-shaped data volumes. Track counts before and after import, especially for catalog versions, classification assignments, price rows, stock levels, and CMS components.
Cutover Model#
The safest upgrade programmes rehearse cutover before the final sprint. Define the freeze window, export timing, redirect strategy, cache warmup, Solr indexing order, and rollback threshold while there is still time to change the architecture.
Readiness Gate#
A 2211 programme is ready to execute when custom extensions compile with known removals addressed, the storefront path is clear, integrations have replayable tests, data migration has at least one full rehearsal, and release engineering can deploy without manual shell work.