SFCC technical debt or platform limit?

Salesforce B2C Commerce gets blamed for a lot. Sometimes it absolutely deserves it.

It can also become the name for fifteen years of custom code, brittle integrations, slow release practices, unclear ownership, and business rules nobody wants to touch.

Replacement may still be right. First figure out whether you are replacing a platform limit or giving fifteen years of technical debt a new address.

Name the constraint precisely

“The platform is slow” can mean several things.

Page rendering may be slow. Releases may be slow. Merchandising changes may require development. Search indexing may lag. Integrations may block checkout. The team may need too much regression testing because customizations cross core behavior. Business stakeholders may simply be tired of waiting for the delivery organization.

Those conditions do not have the same solution.

A new frontend can change page delivery and experience development. It will not repair a weak product feed. A new commerce platform can replace core behavior. It will not clarify who owns promotions across channels.

Start with the business change the company cannot make and follow the constraint through the system.

Separate core from custom

Inventory the behavior in three groups:

Standard platform capability and constraint.
Custom implementation built around the platform.
External systems and operating processes that shape the result.

This is harder than reviewing the cartridge list. Some custom behavior exists because the platform lacked a capability. Some exists because a past team chose a specific design. Some compensates for upstream data or downstream process. Some has not been used in years but still participates in every regression cycle.

The goal is not to assign blame. It is to understand which cost survives a replatform.

Test the release path

SFCC programs can accumulate a large deployment and regression surface. When every change touches a shared codebase and several integrations, teams become cautious for good reasons.

Look at how long a small change takes from decision to production. Count handoffs, environments, regression effort, synchronized dependencies, and approval steps. Identify which parts are required by the platform and which grew from the organization’s delivery history.

A modern storefront architecture may reduce coupling at the experience layer. It can also create new hosting, API, and integration responsibilities.

The question is whether the target model reduces the actual release constraint.

Do not confuse familiarity with platform behavior

Long-running implementations develop folklore. “SFCC cannot do that” may mean the current implementation cannot, the current team has never done it, or changing it would be expensive under the existing architecture.

Validate claims against current platform capability and a representative implementation. Do the same with any replacement platform.

Sales demos are not architecture evidence. Neither are complaints repeated often enough to become requirements.

Price the migration honestly

A replatform moves more than features.

It moves catalog and customer data, promotion behavior, integrations, content operations, analytics, SEO signals, payment flows, service processes, release ownership, and the knowledge people have accumulated around exceptions.

Some of that work creates a cleaner system. Some recreates behavior the business still needs. Some should be retired instead of migrated.

The business case should separate those categories.

If the company is paying to reproduce years of accidental complexity on a new platform, the license decision is not the transformation.

Modernize at the right boundary

The answer may be a full platform replacement. It may be Storefront Next or another headless experience layer. It may be an integration and data program. It may be removing customizations, improving delivery automation, or fixing ownership.

I get suspicious when an assessment reaches the platform answer before isolating the constraint.

SFCC can be the problem. It can also be the place where all the other problems are visible.

Very different diagnoses. Very different invoices.