Salesforce Commerce Cloud Migration Guide

Summary

SFCC migrations fail when teams treat the platform as a single thing to move. It's not. You're dealing with architectural generations stacked on top of each other, Demandware-era cartridges, partial SFRA modernizations, hybrid headless setups. The discovery work that surfaces a clean SFRA implementation won't find the business logic buried in 47 custom cartridges from 2014.

Multiple Architectures Hiding in One Platform

Salesforce Commerce Cloud isn't one platform. You might be dealing with:

Legacy SiteGenesis with custom cartridges piled up over a decade
SFRA implementations that partially modernized the frontend
Hybrid setups where headless APIs serve some channels while controllers handle others
Composable Storefront deployments that never fully decoupled from the backend

Each requires a fundamentally different migration approach.

Reading the Cartridge Stack

The cartridge stack tells the real story:

Custom cartridge count and complexity. More than twenty custom cartridges usually signals years of accumulated business logic that lives nowhere else.
Override depth. How many core platform files have been overridden, and at what layers? Deep overrides into ISML templates and pipelines indicate logic that will need complete reconstruction.
Third-party cartridge dependencies. Payment processors, OMS integrations, personalization tools, each represents an integration that needs equivalent functionality on the target platform.
Business Manager customizations. Custom attributes, site preferences, and configuration that teams have built workflows around.

Data Structures That Don't Map Cleanly

SFCC's data model has specific structures that resist straightforward migration:

Custom objects and their relationships. These often encode business rules that aren't documented anywhere.
Product attribute definitions. Especially localized attributes and complex variant structures.
Content asset organization. Slots, content assets, and folder structures that power merchandising.
Customer data structures. Custom attributes, saved payment methods, address books, and loyalty data.

Mapping the Integration Surface

Document every system that touches SFCC:

OMS connections. Order routing logic, inventory allocation, fulfillment workflows.
ERP integrations. Product information, pricing feeds, inventory synchronization.
Marketing platform connections. Einstein recommendations, email triggers, CDP integrations.
Payment and fraud services. Tokenization strategies, fraud scoring, payment method support.

Finding Where Knowledge Actually Lives

This is where migrations quietly fail:

Who understands the business logic in those cartridges
Whether documentation exists beyond code comments
How many original implementation team members remain
What decisions were made and why, especially the "temporary" fixes that became permanent

Patterns That Signal Risk

"We customized everything." Teams that heavily modified core platform behavior often don't realize how much they've diverged. They assume standard migration tooling will handle it. It won't.

Multiple implementation partners over the years. Each partner brought their own conventions. The codebase becomes a geological record of different coding styles, architectural preferences, and integration patterns.

Business logic in templates. ISML templates that contain business rules, pricing logic, availability checks, customer segmentation, make extraction painful. That logic needs to be identified, documented, and rebuilt.

Undocumented Einstein dependencies. Einstein Recommendations and Predictive Sort configurations that marketing relies on but no one can explain how they were set up. The behavioral data and training history won't transfer.

Heavy Business Manager reliance. When merchandisers have built complex workflows around Content Slots, A/B tests, and campaigns configured entirely in Business Manager, you're migrating operational processes, not just code.

What Assessment Actually Requires

Technical Inventory

Document the actual state, not what was planned or what the original architecture diagram shows:

Complete cartridge manifest with dependency mapping
Custom object schema with relationship documentation
Integration inventory with data flow direction and frequency
API usage analysis, OCAPI vs SCAPI vs custom endpoints
Job and batch process catalog

Business Logic Extraction

Identify where rules live and who owns them:

Pricing and promotion logic
Inventory allocation and ATP calculations
Customer segmentation and personalization rules
Order orchestration and fulfillment routing
Tax and shipping calculation overrides

Stakeholder Requirements

Migration isn't about replicating what exists:

What capabilities are actually used versus configured but abandoned
What frustrations the current platform creates
What business capabilities the migration should unlock
Which features are negotiable and which are non-negotiable

Gap Analysis

Compare current-state capabilities against target platform options:

Feature parity assessment with prioritization
Custom development requirements
Integration rebuilds vs replacements
Data migration complexity scoring

How DigitalStack Structures This Work

SFCC migrations generate massive amounts of context, cartridge inventories, integration maps, stakeholder requirements, architectural decisions. That context gets lost in shared drives and slide decks.

DigitalStack maintains the connection between what you discover and the decisions that follow:

Technical findings link to architectural recommendations. When you document a complex cartridge, the migration approach references it directly.
Stakeholder input becomes structured data. Survey responses from merchandisers, developers, and operations teams feed directly into requirements, not scattered interview notes.
Gap analysis stays current. As scope changes and priorities shift, the analysis updates instead of becoming a stale artifact from week two.
Outputs generate from structured data. Migration roadmaps, risk assessments, and architecture documents reflect the actual state of discovery.

Discovery work for a platform this complex requires a system that maintains context across months of engagement. Slides and spreadsheets won't hold together.

Next Step

If you're preparing for an SFCC migration engagement, see how DigitalStack structures the discovery process from technical assessment through architecture recommendations.