When your commerce platform goes end-of-life under you

When your commerce platform goes end-of-life, nothing breaks on the day it happens. That is the trap. CloudCraze, now Salesforce B2B Commerce Classic, has been support-only since the Winter 2021 release: security and bug fixes, no new features. You still own a running store, a frozen managed package you cannot fully debug, and a migration bill you never budgeted. "Buying safe" turned out to include the vendor's right to sunset you.

What actually happened to CloudCraze?

CloudCraze began as an independent B2B commerce product built natively on Salesforce, founded in 2010. Salesforce acquired it, rebranded it B2B Commerce, and shipped it as a managed package: code you install and configure but do not own. That distinction is invisible on day one and decisive on the day support stops. Then the roadmap moved. Since the Winter 2021 release the classic package has been support-only, patches and bug fixes with no new capability. The future is the Lightning Web Runtime storefront, which the migration vendors describe as two generations removed from the CloudCraze you are running. Nothing was switched off, and that is precisely why the risk is easy to defer: the store still takes orders, the dashboards still load, the invoices still post to SAP. The platform simply stopped moving while the ecosystem around it kept going.

Why does a frozen platform still cost money?

Because support-only is not the same as maintenance-free. The package sits on Backbone.js and Handlebars, frameworks already aging when the freeze landed, and storefront work in CloudCraze usually means overriding out-of-the-box Handlebars templates. One developer's summary of that approach is blunt:

It makes upgrade a potential nightmare every single time as things may change and templates overrides might have to be altered.

The maintenance load is not hypothetical. Corevist, a rival platform vendor, so read the framing accordingly, aggregates manufacturer and developer accounts and describes CloudCraze as

an extremely highly strung package that is hard to work with and breaks/misbehaves at every opportunity.

It also reports one manufacturer spending $1M+ per year just to keep the integration supported, licensing not included. The people who can do that work are getting scarcer and pricier: the same source cites developer salaries in the $145,000 to $208,000 range, in a talent pool that shrinks every year the industry moves toward modern frameworks. A frozen platform, quietly, gets more expensive to stand still on.

Why can't you just debug your way out?

Because a managed package is a black box by design. You installed it; you did not receive the source. When something misbehaves inside the package, ordinary Apex debugging does not reach it. As the field guides note, System.debug output will not appear for managed-package code, leaving you with the package's own logs or a support ticket. On a platform still shipping fixes that is an annoyance. On a platform frozen at Winter '21 it is structural: the code that fails is the code you are least able to inspect, owned by a vendor whose incentive is to move you onto the successor product rather than deepen the one you are on. Every returnables reconciliation, every order sync back to SAP, every pricing edge case now runs through a component whose edges you can see but whose inside you cannot. The result is a support model where your best diagnostic step is often to reproduce the fault, screenshot it, and wait.

It is the same failure mode as the field app that shipped at 1.9 stars: when a vendor owns the weakest link in your route-to-market, your options narrow to whatever that vendor decides to ship next.

The platform risk buyers forget

The diagnosis is not that CloudCraze was a bad product. It is that the procurement logic that chose it, big vendor, native to the CRM, therefore "safe", priced in the wrong risk. Enterprise buyers model outage risk, security risk, and integration risk. None of those are wrong to model; they are simply the risks that surface in a security questionnaire. They rarely model roadmap risk: the vendor's unilateral right to freeze, deprecate, and eventually sunset the thing your order capture runs on.

Managed packages concentrate that risk. You license configuration, not code; you inherit the framework choices and the debugging limits; and your exit is a re-platforming project timed on the vendor's calendar, not yours. It rhymes with the base-and-attach licensing traps in Dynamics, where the sticker price hides the structural cost, and with the integration spaghetti that turns every connector into a permanent line item. That $1M+ support figure is, mostly, integration you were never given the keys to.

The way out is not another managed package. It is owning the layer that carries your commercial logic, order capture, stock, returnables, pricing, on an event-driven platform you actually control, with the vendor's financial core left where it belongs and the storefront reduced to a component you can rewrite on your own schedule. That is a bigger conversation than a migration checklist, and better had before the next end-of-life notice than after it.

Somewhere on every large brewer's roadmap is a platform currently described as safe. The question worth asking now is not whether it works today; it is who decides when it stops. If the answer is a vendor's release-management team, the end-of-life clock is already running. You simply have not been shown the time.