Half-hour builds, 90-minute deploys: SAP Commerce Cloud v2

On SAP Commerce Cloud v2, a build that finishes in a few minutes locally takes around half an hour, and a deploy with an init or update step can run up to 90 minutes — occasionally much longer. The reason is structural, not a misconfigured project: every build is assembled from scratch on a fresh Kubernetes pod, and the deploy serially reinitialises or migrates the type system. It is slow by design.

Why does a build take half an hour when it takes minutes locally?

There is no incremental compilation in the cloud pipeline. As one practitioner running two commerce clouds side by side puts it, a build that takes "a few minutes on your local development machine" takes "around half an hour on CCv2" because "every build is created from scratch on an empty Kubernetes pod." Each build spins up a clean container, pulls dependencies, compiles the full platform plus your extensions, runs the frontend build, and bakes a deployable image. Nothing is cached between runs, so the tenth trivial change costs exactly as much as the first.

The from-scratch model also imports the container registry's bad days. Migration write-ups report weekly build failures with an UnknownHostException against the Azure container registry — a transient DNS or registry hiccup that fails an otherwise valid build and sends you back to the queue. When every build is a cold start over the network, every network wobble is your problem.

What is the deploy actually doing for 90 minutes?

The build produces an artefact; the deploy applies it. In "none" mode a deploy is comparatively quick, but the moment you need an init (rebuild the schema) or update (migrate the type system), you are into serial database work: type-system changes, essential and project data imports, Solr index setup, and cronjob re-registration. The same practitioner notes deploys "take up to 1.5 hours" and — the part that hurts operationally — arrive with "no progress indicator or log to follow." You start it, and you wait, blind.

Update-with-migration is worse. A community thread describes a migration-mode deployment that "takes nearly 2.5 hours with all backend cronjobs and business processes impacted" — i.e. the platform is degraded for the duration, not just the deploy pipeline. And when it hangs, self-service ends: deploys can "get stuck completely and we have had to contact SAP support," which turns a release window into a support ticket.

How slow can the pathological case get?

Slow enough that SAP documents it in its own knowledge base. KBA 3084783 records a single deployment that ran for 1 day, 1 hour, 20 minutes and 38 seconds, with one line of the log accounting for most of it:

Generating path values for OrgUnitModels took 45247923 ms

That is roughly 12.6 hours spent single-threaded on path-value generation for one model type, and per the KBA the behaviour "affects SAP Commerce Cloud across all versions." It is an edge case tied to data volume, but it is the same pipeline: a serial, opaque initialisation step with no back-pressure and no way to parallelise your way out. The 90-minute median and the 25-hour tail are the same design under different data.

What that looks like next to a laptop, as reported by practitioners as of early 2026:

Why the constraints bite hardest where you customise

The pipeline cost would be tolerable if the platform let you route around it, but the managed model narrows your options exactly where teams tend to differentiate. Search is the clearest example: practitioners report that on CCv2 "you can't use any custom modules with Solr," so search-side extensions that were routine on-prem simply aren't available. You inherit the rebuild-from-scratch tax and lose some of the escape hatches that made the platform's slowness bearable before.

This is the same shape we see across enterprise suites, where the platform quietly decides what you may extend. It rhymes with the WMS modifications that vanish with every upgrade, and with B2B promo logic hitting invisible governor limits: the constraint isn't in your code, it's in the runtime you rent, and it surfaces only when you push on it.

What the slow pipeline actually costs you

The headline numbers are annoying; the second-order effects are the real bill. When a no-op change costs half an hour to build and a schema change costs 90 minutes to deploy — blind — three things follow. Batching: teams stop shipping small, safe changes and start bundling a fortnight of work into one risky release, because the pipeline makes small releases uneconomic. Mean-time-to-recovery: with "no progress indicator or log to follow," a stuck deploy is indistinguishable from a slow one until support tells you which it was, so incidents run long. And coupling: because a release is a full-platform rebuild-and-reinitialise, a change to one corner of the catalogue drags the entire type system and every cronjob through the same serial gate. You are paying monolith deployment costs for changes that are logically tiny. It compounds with the broader SAP migration story — middleware that retires in 2027 with a tool that migrates 60% — where the platform's timeline, not yours, sets the tempo.

The fix direction is architectural, not a faster build agent: decompose the release so a change to orders, loyalty or returnables ships on its own path rather than through one full-platform init, and put the moving parts on an event-driven bus where services deploy independently. That is a different diagnosis for a different post; the point here is that half-hour builds and 90-minute deploys are a symptom of the coupling, not the disease.

None of this is a reason to rip out a working storefront tomorrow. But it is worth measuring: track your build and deploy P50 and P95 for a quarter, count the releases you didn't ship because the window was too expensive, and price the coupling. Once the pipeline's tax shows up as a line item rather than a background hum, the case for moving the fast-changing edges off the monolith tends to make itself.