Migration Guide
SFCC toward composable — clean it before you leave it.
The honest answer, more often than the industry admits, is that the cartridge estate needs cleaning, not replacing. SFRA vs PWA Kit vs fully headless, the test harness that makes a refactor safe, and what leaving Salesforce Commerce Cloud actually costs.
This is a technical playbook for one migration decision. For SFCC build and integration work generally, see Salesforce Commerce Cloud Development. For replatforming decisions in general, see Platform Migration.
Where the decision goes wrong
Four ways teams jump too fast.
Every one of these traces back to the same root cause — not separating what the platform actually can't do from what four years of cartridge decisions made hard.
Replatform chosen before the bottleneck is named
The team is frustrated with SFCC, so "leave SFCC" becomes the plan before anyone separates platform ceiling from cartridge debt — two very different problems with very different fixes.
Cartridge debt mistaken for platform debt
A storefront four years deep in custom cartridges, forked SFRA modules, and undocumented hooks feels like the platform's fault. Most of that debt would follow the team to any new platform.
No test harness, so a refactor feels riskier than a rewrite
Without characterization tests around what the cartridges actually do today, every change ships on faith — and a rewrite starts to look safer than it is.
Checkout and Einstein economics left out of the math
Teams price the new frontend build and skip the cost of rebuilding PCI-scoped checkout, re-training merchandising on Page Designer's replacement, and losing Einstein's personalization signal on day one.
OCAPI habits carried into new code
Engineers who learned SFCC on OCAPI keep building against it out of habit, even on greenfield cartridge work — adding to the exact legacy-API debt a cleanup is supposed to retire.
Three real destinations
SFRA, PWA Kit, or fully headless.
Not two options. SFRA and PWA Kit both keep you on Salesforce — the frontend architecture changes, the commerce backend and content model don't. Fully headless is the only option that actually leaves.
The step buyers usually skip
Moving from SFRA to PWA Kit is a frontend rebuild on the same platform — real work, but a fraction of the risk of leaving Salesforce entirely. Most brands that think they need the third column actually need the second, or the first with a cleanup.
Salesforce's own PWA Kit and Managed Runtime module walks the same architecture from Salesforce's side.
Cartridge debt, cleaned
A test harness makes a refactor safer than a rewrite.
Characterization tests before anything moves
Tests that capture what a cartridge actually does today — not what the ticket says it should do. This is the safety net that makes refactoring safer than a rewrite, not slower than one.
One cartridge per slice, dependency graph mapped first
Import/export cartridges, pricing hooks, and shared libraries get mapped before the first line changes. Touching a widely-depended-on cartridge without that map is how a cleanup becomes an outage.
Regression harness runs on every controller change
SFRA controllers are the highest-risk surface — checkout, cart, and account logic live there. Every change to a controller runs against the full regression suite before it merges, not before release.
Forked SFRA modules reconciled against base, deliberately
Years of custom overrides drift from the base cartridge Salesforce ships. Reconciling them is tedious and is also the single most valuable cleanup — it's what makes future Salesforce upgrades routine again.
A refactor without characterization tests isn't safer than a rewrite. It just feels that way until the first regression ships to production.
This is the exact approach behind an enterprise luxury retailer's embedded engagement — a storefront four years deep in custom cartridges, refactored cartridge-by-cartridge against a custom test harness, never replatformed.
Page Designer & content authoring
What merchandising keeps, and what changes.
Page Designer stays the merchandising tool of record
On SFRA and on PWA Kit, Page Designer is how non-engineers build and schedule storefront content. Leaving SFCC means retiring it — and re-training the merchandising team on whatever replaces it.
Content model is reachable through SCAPI on Composable
Moving to PWA Kit doesn't mean rebuilding the content model. The same Page Designer pages render through a React frontend calling SCAPI instead of ISML rendering server-side.
Component authoring changes even when the model doesn't
Merchandisers building layouts in Page Designer are choosing among components a developer built. On Composable, those components are React, not ISML includes — the authoring experience stays familiar, the underlying build does not.
This is the argument for PWA Kit over a full exit in one sentence: the merchandising team's tool doesn't change, only the code rendering what they build inside it.
What leaving actually costs
The license fee was never the real cost.
Checkout and PCI scope
Salesforce's checkout is PCI-scoped and battle-tested. Leaving SFCC means rebuilding it or integrating a new payment provider, and re-establishing PCI compliance from a different starting point.
Einstein personalization and search
Product recommendations, predictive sort, and AI search are trained on years of the brand's own transaction data inside Einstein. That signal doesn't export — it gets rebuilt from scratch on a new stack.
Business Manager workflows
Promotions, inventory rules, and merchandising workflows built up over years inside Business Manager have no direct equivalent on a different platform. Each one gets re-specified and rebuilt.
Revenue-share and license economics, inverted
SFCC's pricing is usually tied to GMV. A composable stack trades that for fixed licensing across several vendors chosen individually — cheaper at some GMV levels, more expensive at others. The crossover point is worth modeling before deciding, not after.
Search relevance and merchandising sort rules
Years of tuned search relevance and manual sort overrides live inside SFCC's search configuration. A new search vendor starts from a blank relevance model — re-tuning it happens in production, in front of real customers.
The license fee was never the real cost. It was always checkout, Einstein, and years of Business Manager workflows — and none of those migrate for free.
Side by side
The three paths, named honestly.
| Dimension | Stay on SFRA, clean cartridges | Move to PWA Kit | Leave SFCC entirely |
|---|---|---|---|
| Hosting & ownership | Salesforce-managed, unchanged from today. | Still Salesforce (Managed Runtime); frontend code is yours. | Self-managed or a different vendor entirely. |
| Rendering | Server-rendered ISML templates. | React via PWA Kit, server-rendered on Managed Runtime. | Whatever the new frontend stack chooses. |
| API surface | SCAPI plus legacy OCAPI on older integrations. | SCAPI only — OCAPI is retired as part of the move. | None of SFCC's — catalog, pricing, and promotions are re-integrated from a new source. |
| Content authoring | Page Designer, native, no retraining. | Page Designer content reached through SCAPI; components rebuilt in React. | Page Designer is gone; a new CMS and a new authoring workflow replace it. |
| Checkout & Einstein | Both stay exactly as they are today. | Both stay — Composable Storefront calls the same commerce and AI services. | Both are rebuilt, replaced, or re-integrated from a new vendor. |
| Migration effort | Lowest — a cartridge cleanup, not a migration. | Moderate — new frontend, same commerce data model and backend. | Highest — a true replatform with full data migration and integration re-testing. |
Replatforming off a platform you haven't cleaned is replatforming your own technical debt onto a new vendor.
Destm's longest continuous client relationship has run more than eight years — embedded, not transactional, which is the same posture that makes a cartridge cleanup outlast a vendor handoff.
If the answer really is to move
A genuine exit runs like any other replatform.
Sometimes the ceiling is real. Catalog complexity, B2B pricing rules, or a customization need SFCC genuinely can't support are legitimate reasons to move, not just frustration with the platform you already know.
When that's the honest answer, the move runs as a controlled program, not a rebuild sprint — URL and SEO mapping, order and customer data reconciled against source, every integration load-tested before cutover, and old and new running in parallel until parity is proven.
That program is the same one Destm runs for any platform move, detailed in full at Platform Migration. SFCC adds one wrinkle: Einstein and Business Manager have no export button, so the rebuild plan for personalization and merchandising workflows has to exist before the migration timeline is set — not get discovered mid-cutover.
FAQ
Questions we get on the first SFCC call.
QShould every SFCC brand consider leaving the platform?
Should every SFCC brand consider leaving the platform?
No. Most of the pain we see traces back to an uncleaned cartridge estate, not a genuine platform ceiling. Clean the cartridges first, prove the pain is still there, then re-evaluate — leaving is a much smaller decision after that step than before it.
QWhat's the actual difference between SFRA and PWA Kit?
What's the actual difference between SFRA and PWA Kit?
SFRA renders ISML templates server-side inside SFCC itself. PWA Kit — Composable Storefront — is a React frontend hosted on Salesforce's Managed Runtime, calling SCAPI instead of rendering templates. Same commerce backend and content model, different frontend architecture.
QIs OCAPI still worth building against for new work?
Is OCAPI still worth building against for new work?
No. Salesforce's own developer guidance treats OCAPI as legacy and directs new integrations to SCAPI, which is built on OAuth 2.0 and an OpenAPI spec instead of proprietary protocols. Any cartridge cleanup should retire OCAPI calls as it touches them.
QWhat does a cartridge-by-cartridge cleanup actually look like?
What does a cartridge-by-cartridge cleanup actually look like?
Characterization tests around current behavior first, a dependency map of what touches what, then one cartridge extracted or refactored per slice — with the regression suite running against every controller change before it merges, not before release.
QWhat's the biggest hidden cost of leaving SFCC?
What's the biggest hidden cost of leaving SFCC?
Checkout and PCI re-scoping, Einstein's personalization signal rebuilt from zero, and every Business Manager workflow merchandising depends on re-created by hand in a new admin tool. Teams that price only the new frontend build are pricing a fraction of the real project.
QHow do you actually decide stay-and-clean vs move, for a specific brand?
How do you actually decide stay-and-clean vs move, for a specific brand?
We separate cartridge debt from platform ceiling first. If Einstein and Salesforce checkout are load-bearing for the business and the team can't sustain a headless build for years, staying and cleaning almost always wins on total cost.
How an engagement starts
Three steps to a partnership
Intake call
30 minutes. We listen, you talk. No deck.
Diagnostic
We audit the surface, name the bottleneck, propose a path.
Kickoff
Senior engineer in your standup by week two.
Clean it, or leave it — let's find out which
Tell us what your cartridge estate actually looks like. We'll come back with what's debt, what's a real ceiling, and which of the three paths fits.