On-prem mainstream maintenance ended 31 July 2026
SAP Commerce on‑premise left mainstream maintenance on 31 July 2026 — no more security patches, legal‑change packages or SLA‑backed fixes. Avalanche plans and runs the move to SAP Commerce Cloud, to composable, or to a defensible interim, without stopping the business that runs on it.
Commerce programs delivered for
The dates that matter
Three deadlines, one direction. Where your estate sits against them decides how much room you still have to choose — on‑premise and Commerce Cloud alike.
On‑prem 2205, the final on‑premise release, leaves mainstream maintenance. A month later, Commerce Cloud stops building on JDK 17.
JSP Accelerator storefront templates and add‑ons are removed from Commerce Cloud 2211.
Extended support for Accelerator ends. Any storefront still on it is on its own.
Per SAP Help Portal maintenance notices and SAP’s Key Technical Updates for Commerce Cloud. The diagnostic walks your exact version against each one.
Migration paths
Most firms sell the path they staff. We model all three against your architecture, your team and your cost base — then recommend one and defend it in writing.
Same Java core, same type system, same extension mechanism — SAP changed the deployment model and the front end, not the engine. The lowest requalification burden and the fastest route back into support.
Decouple the storefront over OCC APIs, then modularize what genuinely benefits from it. More runway and faster time‑to‑change — for a longer program and a different operating model for your team.
Customer‑specific maintenance is not a safety net — it is reduced cover, often at higher cost. If you must hold, we compensate deliberately: controls, patch strategy, a payment‑gateway watch, and a dated exit.
Exposure check · 2 minutes
Five questions. You get a risk band, the path we would recommend, an effort range and your first thirty days — on screen, as you answer. No gate, no email required.
A directional read from public SAP maintenance dates and our delivery history — not a substitute for a mapped assessment of your environment.
Practice
Transformation is not a technology problem first. Before proposing a single component we map your business strategy, organization, data landscape and market needs. The solution follows from that — not the other way around.
A current‑state inventory of your commerce estate — version, extensions, storefront, data volumes, integration surface — turned into a costed, sequenced roadmap and a signed‑off blueprint.
On‑premise to Commerce Cloud, Accelerator to Composable Storefront, or SAP to non‑SAP where the requirements point that way. Migration harness, reconciliation, dress rehearsals, rollback plan.
Blueprints for ERP, PIM, OMS, tax, payments and the legacy systems nobody wants to touch. Contract‑first APIs, idempotency, and failure handling that survives peak.
Country‑by‑country waves: currency, language, translation workflow, tax and legal variance, regional fulfilment, local payment methods, and in‑region support handover.
Sprint planning that ties business goals to development teams. Scrum and SAFe coaching, backlog and user‑story discipline, and mentoring that stays after we leave.
Core Web Vitals and SSR tuning, Solr lifecycle, release regression packs, and a hypercare model that ends on a date instead of drifting.
Integration
Programs rarely fail on the storefront. They fail where commerce meets the systems of record — orders that double‑post, prices that disagree, inventory that lies. We blueprint that surface first and prove it with contract tests before a sprint of UI is written.
SAP and non‑SAP alike — Salesforce Commerce, BigCommerce, composable stacks. The pattern matters more than the badge.
Catalog · Pricing · Promotions · Cart & checkout · Orders · B2B accounts · Search
How engagements run
No phase closes on a status deck. Each one ends with an artifact your team owns and can run without us.
Stakeholder interviews, estate inventory, data profiling, integration surface map, risk register.
Solution and integration architecture, data model, migration strategy, environment plan, cutover shape.
Sprints against a groomed backlog, Impex and config baselines, CI/CD wired, test automation growing each sprint.
Pilot market first, then waves. Dress rehearsals, reconciliation reports, rollback drill, in‑region handover.
Hypercare with an end date, performance and search tuning, release cadence handover, next‑horizon backlog.
What your team keeps
Some of it we bring on day one; some we build to fit your landscape. All of it stays.
Versioned Impex, JSON/YAML and property sets for catalog, pricing, promotions and site config — environments you can rebuild, not excavate.
Jenkins, GitLab CI or Bamboo: build, unit and integration tests, gated promotion from dev through QA and staging to production.
Repeatable extract, transform and load runs with per‑entity reconciliation — counts and deltas before anyone signs a go‑live.
Hour‑by‑hour sequence, owners, checkpoints and abort criteria, rehearsed twice before the real weekend.
Checkout, pricing, tax, promotions and B2B account paths automated, so monthly platform updates stop being a fire drill.
A grounded assistant over your own catalog and order data — guided selling, order status, reorder — scoped so it cannot invent a price.
Who you work with
I specialize in global and pilot digital transformation — taking complex business challenges and turning them into streamlined digital experiences that scale with confidence.
A proven track record delivering SAP and non‑SAP e‑commerce and integration programs for global brands including Shure, Levi’s, Nestlé, Rockwell Automation and Lenovo — with depth across strategy, systems architecture and hands‑on execution. The same person in the boardroom and in the blueprint review.
You are not handed to a delivery pod after the sales call. Engagements are led personally, with specialists brought in around a defined architecture rather than staffed to fill a bench.
SAP Commerce (Hybris) B2B and B2C, Composable Storefront, SmartEdit, Solr, OCC APIs, BTP integration
Salesforce Commerce, BigCommerce, composable stacks — and the migrations between them
Scrum and SAFe, sprint facilitation, Agile coaching and team mentoring through go‑live
United States — working across US, EMEA and APAC rollout waves and time zones
Straight answers
Answered with the dates and ranges we would give you on a call. If the answer to yours is “it depends,” we say what it depends on.
Mainstream maintenance for SAP Commerce on‑premise ended on 31 July 2026. Release 2205 was the final on‑premise version. Only customer‑specific maintenance remains — no new security patches, no legal‑change packages, and no SLA‑backed support for new defects.
Not automatically. Commerce Cloud stops building on JDK 17 after 31 August 2026, so you need the JDK 21 / Spring 6 framework update — and Composable Storefront versions older than 221121.1 cannot go live on it. If you still run the JSP Accelerator, it is removed from 2211 in September 2027, with extended support ending in September 2028.
A typical lift runs six to twelve months. A fast track on a lightly customized estate can close in four to six; a heavily customized multi‑market estate phased by region usually runs ten to sixteen. Going fully composable is a twelve to twenty‑four month program — the difference is scope, not vendor speed.
No — and it is the single most useful thing to understand before budgeting. Commerce Cloud keeps the same Java core, type system and extension mechanism. SAP changed the deployment model and the front end, not the commerce engine. That is why a lift carries a far lower requalification burden than a replatform to a different vendor.
The platform keeps running — which is what makes it dangerous. You now carry the security and compliance risk yourself. In practice it shows up as PCI DSS audit findings, payment‑gateway and TLS compatibility drift as providers deprecate older integrations, unpatched dependency vulnerabilities, and a shrinking pool of specialists willing to touch the version.
Not immediately — but with the Accelerator templates leaving 2211 in 2027 and extended support ending in 2028, an Accelerator storefront is a dead end on a known clock. Many enterprises lift to Commerce Cloud first to get back into support, then decouple the storefront as a deliberate second phase.
Four variables drive it: how far your core is forked from standard, how many systems integrate with commerce, how many markets and sites go live, and whether the storefront is replaced at the same time. The diagnostic maps those four against your estate and produces a costed options paper — before you commit to anything.
Start here
No slide deck. We walk your architecture, your version, your integration surface and your team — and you leave with a clear‑eyed view of your options, whether or not you work with us.
