Summary
Enterprise retailers leveraging Salesforce Commerce Cloud on the legacy SiteGenesis framework face mounting technical debt and missed opportunities. Salesforce ceased active SiteGenesis development in 2017, focusing all innovation on the Storefront Reference Architecture (SFRA) and the newer Composable Storefront. Staying on SiteGenesis means operating with a shrinking feature set, higher maintenance costs due to brittle custom code and outdated architecture, and limited access to critical integrations, AI capabilities, and the full LINK cartridge ecosystem. The business case for migration is now undeniable, driven by the need for access to current platform capabilities, improved developer productivity, reduced TCO, and superior mobile performance.
SFRA offers a modular, mobile-first architecture that vastly improves customization, allows for extensible code without breaking core functionality during updates, and inherently boosts mobile conversion rates and Core Web Vitals. It provides a structured path for continuous improvement and serves as a prerequisite for advanced features like SCAPI integrations and Einstein AI. Furthermore, SFRA enables a phased, hybrid approach towards headless commerce, offering flexibility for retailers who aren't ready for a full Composable Storefront pivot. A successful migration requires a structured approach, from comprehensive audit and architecture design to redevelopment, rigorous testing, and SEO continuity planning.
While some retailers might consider jumping directly to Composable Storefront, SFRA remains a fully supported, proven migration target with a shorter timeline, especially for those with significant existing investments or SFRA-compatible integrations. Ranosys, a Salesforce Summit Partner, brings extensive expertise in Salesforce Commerce Cloud, Digital Commerce, and Digital Transformation. We guide enterprise retailers through the entire SiteGenesis to SFRA migration lifecycle, ensuring zero disruption to live operations, optimizing performance, and providing ongoing managed services. Our structured discovery process delivers clear scope, timeline, and cost, allowing businesses to confidently modernize their commerce platforms and unlock future growth.
When a Salesforce Commerce Cloud storefront runs on SiteGenesis, the maintenance cost is rarely visible on a single invoice. It shows up in developer hours spent on brittle custom code, in SFRA-only LINK cartridges the team cannot access, and in new Salesforce features that arrive with a footnote: SiteGenesis not supported. That friction compounds over time, and the business case for staying put gets harder to defend each quarter.
Many enterprise retailers have evaluated SiteGenesis to SFRA migration services and paused. The scope looked large, the timing was never right, and SiteGenesis technically still functions. According to Salesforce’s official developer documentation, Salesforce stopped active SiteGenesis development and now directs retailers toward Storefront Reference Architecture (SFRA) as the recommended B2C Commerce foundation. For retailers evaluating a Storefront Reference Architecture migration, the question is no longer whether to move, but how to do it without disrupting live operations.
This SFRA migration guide covers the architectural differences, the step-by-step migration process, what drives timeline and cost, and the decision factors that matter most for enterprise retail teams.
What is SiteGenesis?
SiteGenesis is Salesforce Commerce Cloud’s legacy storefront framework, inherited from the Demandware acquisition. Its monolithic structure requires developers to modify core code directly for every customization, creating tightly coupled dependencies and accumulating technical debt with each release cycle. Salesforce stopped active feature development on SiteGenesis in 2017, limiting updates to security patches and bug fixes only.
What is SFRA (Storefront Reference Architecture)?
Storefront Reference Architecture (SFRA) is Salesforce’s mobile-first storefront framework for Salesforce B2C Commerce Cloud, introduced in 2018. It uses a controller-based MVC architecture with Node.js, replacing pipelines with modular JavaScript controllers. ISML templates remain, but the patterns are simpler and easier to extend without touching core code.
SFRA’s cartridge layering model is its defining architectural advantage. Salesforce maintains the app_storefront_base cartridge on GitHub. Custom code, plugin cartridges, and LINK cartridges layer on top without modifying the base, so platform updates do not break custom functionality. SFRA cartridge migration also opens access to the full LINK ecosystem, including integrations that SiteGenesis versions have deprecated. SFRA serves as the prerequisite for SCAPI integrations, Einstein AI commerce features, and the Composable Storefront path.
SiteGenesis vs SFRA: Key differences
| Dimension | SiteGenesis | SFRA |
| Architecture | Monolithic, pipeline-based | Modular, controller-based |
| Customization model | Override or replace core code | Extend via cartridge layering |
| Design approach | Desktop-first, responsive adapted | Mobile-first, responsive design by default |
| Template language | ISML (legacy patterns) | ISML (modern, simplified) |
| Salesforce investment | Security patches only | Active development and new features |
| SCAPI and headless support | Limited | Full support |
| LINK cartridge access | SG-specific only | Full catalog access |
| Testing support | Limited | Unit, integration, and functional testing |
| User experience optimization | Constrained by monolithic structure | Modular, faster to iterate |
Why enterprise retailers migrate from SiteGenesis to SFRA
The business case for a Salesforce Commerce Cloud SFRA upgrade comes down to four practical factors.
Access to current platform capabilities: Salesforce concentrates its product investment on SFRA and the Composable Storefront layer above it. Payment integrations, Einstein AI features, SCAPI-dependent capabilities, and SFRA-only LINK cartridges are unavailable or unsupported on SiteGenesis. Retailers on SiteGenesis operate with a shrinking feature set.
Developer productivity and talent availability: SiteGenesis relies on pipeline architecture that fewer developers know. As 64Labs noted in their 2025 SFRA analysis, the SiteGenesis talent pool has been contracting since roughly 2022. That contraction shows up directly in higher hiring costs and slower delivery.
Technical debt and total cost of ownership: SiteGenesis customizations sit inside core code. Every version update risks breaking existing functionality. Teams spend developer cycles on patching rather than building features that generate revenue. For Salesforce Commerce Cloud (SFCC) operators, this maintenance burden is the largest hidden contributor to total cost of ownership over a three-to-five year horizon.
Performance and mobile conversion: SFRA’s mobile-first architecture produces better Core Web Vitals scores out of the box. Mobile conversion rates consistently lag on older architectures, and the gap widens as shoppers expect faster, more responsive experiences.
From SiteGenesis to SFRA: Zero disruption, live integrations
Eu Yan Sang, a TCM brand with 170+ retail outlets across Asia, had been running Salesforce Commerce Cloud on SiteGenesis Pipeline architecture. When their roadmap outgrew what the legacy architecture could support, Ranosys migrated their storefront to SFRA with zero disruption to live operations and user experiences.
Benefits of migrating to SFRA: What enterprise retailers gain
A Salesforce Commerce Cloud SFRA upgrade delivers measurable improvements across development velocity, integration access, storefront performance, and long-term platform flexibility.
1: Extensible customization without upgrade risk
SFRA’s cartridge layering model keeps custom code above the base cartridge, not inside it. When Salesforce releases an update, the base cartridge updates without touching custom functionality. Teams spend less time on regression testing and less budget on keeping the storefront current.
2: Full access to the LINK cartridge ecosystem
Salesforce’s LINK cartridge program includes certified integrations for payments, tax, fraud detection, search, and ratings and reviews. Many integrations are SFRA-only or carry deprecated SiteGenesis versions. SFRA cartridge migration opens the full partner ecosystem without requiring custom builds for every connection.
3: Improved mobile performance and user experience
SFRA is mobile-first by design, with optimized checkout flows and touch-friendly interactions. It also gives merchandising teams data-driven tooling to measure and improve customer experiences across devices. Improved Core Web Vitals scores affect organic search rankings, since Google’s page experience signals influence visibility.
4: A path to composable and headless commerce
SFRA supports phased hybrid implementations alongside Salesforce’s Composable Storefront (PWA Kit). According to Salesforce’s official developer documentation on hybrid headless rollouts, retailers can run SFRA and a PWA web app simultaneously using session bridging, enabling incremental migration toward headless architecture without rebuilding the entire storefront. LINK cartridges for modern payment methods, including Apple Pay and digital wallets, are exclusively available in this ecosystem and cannot be implemented on SiteGenesis.
5: Structured testing and quality assurance
SFRA includes built-in support for unit, integration, and functional testing frameworks. For enterprise retailers managing complex catalogs and multiple integrations, structured testing means fewer production incidents and greater release confidence.
SiteGenesis to SFRA migration process (step-by-step)
SiteGenesis code cannot be converted directly to SFRA. A successful SFCC storefront migration requires a structured migration plan covering assessment, architecture design, redevelopment, integration validation, and thorough testing. Enterprise SiteGenesis to SFRA migration implementations typically follow five phases.
Phase 1: Discovery and audit
Inventory all custom cartridges, pipelines, controllers, ISML templates, integrations, Business Manager configurations, custom objects, and metadata. Map each component to its SFRA equivalent, or flag it for custom redevelopment. This phase also covers SEO: URL structures, redirect requirements, metadata schemas, structured data, and canonicalization all need explicit planning to protect organic search equity.
Phase 2: Architecture and design
Define the SFRA cartridge path structure. Design the extension architecture for custom functionality. Identify which LINK cartridges replace existing integrations and which require custom builds. Decide on a parallel-run or phased migration approach based on business risk tolerance.
Phase 3: Development and integration
Rebuild storefront pages, controllers, and templates in SFRA. Redevelop custom business logic using SFRA’s middleware and server module patterns. Validate OCAPI and SCAPI dependencies. Rebuild payment, tax, OMS, search, and marketing integrations. Migrate scheduled jobs and background processes.
Phase 4: Quality assurance and performance testing
Run unit, integration, and functional test suites. Conduct regression testing across device types and browsers. Validate Core Web Vitals targets, test analytics instrumentation, and verify promotional and pricing logic across all scenarios.
Phase 5: Launch and post-migration
Execute an SFRA zero downtime launch using staging and production environments. Monitor performance, conversion, and error rates for the first four weeks post-launch. Validate SEO continuity through redirect mapping and crawl monitoring.
Common SiteGenesis to SFRA migration challenges and how to resolve them
| Challenge | Business impact | Resolution |
| Deep pipeline customizations with no SFRA equivalent | Scope creep and extended timelines | Audit pipelines in Phase 1; redevelop as SFRA middleware or hooks |
| Third-party integrations without SFRA-compatible versions | Integration gaps at launch | Identify replacements during discovery; build custom connectors where needed |
| SEO URL and redirect mapping | Organic traffic loss post-launch | Plan the redirect strategy before development; validate with crawl tools pre-launch |
| Data migration across catalog, promotions, and accounts | Incomplete or inconsistent storefront data | Run parallel environments; validate data completeness before cutover |
| Team unfamiliarity with SFRA patterns | Slower development and inconsistent code quality | Schedule SFRA training before development begins; add code review checkpoints throughout |
SiteGenesis to SFRA migration checklist
This SiteGenesis to SFRA upgrade checklist is designed to be worked through in sequence with your migration team and your SFCC implementation partner, covering all three phases of your SFCC storefront migration.
Pre-migration
- Complete custom cartridge and pipeline inventory
- Map all third-party integrations to SFRA-compatible alternatives
- Document SEO URL structures, redirect requirements, and structured data schemas
- Identify SFRA-only LINK cartridges that replace existing integrations
- Assess catalog, customer, and order data migration requirements
- Define phased or parallel-run migration strategy
Development
- Implement SFRA cartridge path and extension architecture
- Rebuild custom controllers, ISML templates, and frontend assets
- Validate SCAPI and OCAPI dependencies
- Redevelop or replace third-party integrations
- Migrate Business Manager configurations, custom objects, and metadata
- Set up automated test suites covering unit, integration, and functional tests
Launch
- Confirm rollback plan before go-live
- Execute full regression testing across devices and browsers
- Validate Core Web Vitals and page performance targets
- Confirm analytics and tracking instrumentation
- Implement SEO redirects and validate with crawl monitoring
- Monitor conversion, performance, and error rates for 30 days post-launch
SFRA migration cost and timeline: What drives them
SFRA migration cost and SFRA migration timeline vary significantly across enterprise retailers. The key drivers are storefront complexity, custom cartridge count, integration scope, number of locales and sites, existing technical debt, and whether the project uses a phased or full-cutover approach. A dedicated migration team also moves considerably faster than one sharing capacity with ongoing operations.
According to estimates from SFCC practitioners documented by Salesforce Commerce Cloud consulting partners, straightforward SiteGenesis to SFRA migration implementations run six weeks to six months for mid-sized storefronts, with complex enterprise projects extending further. A detailed discovery audit is the only reliable basis for a project-specific estimate of SFRA migration cost and timeline.
SiteGenesis to Composable Storefront: Is SFRA the right destination?
Salesforce is actively investing in Storefront Next (also called Composable Storefront), a React-based headless storefront built on Next.js positioned as the recommended path for new storefronts. As 64Labs’ May 2026 analysis notes, some SFCC practitioners now recommend that SiteGenesis retailers skip SFRA and go directly to Storefront Next.
SFRA remains a fully supported, proven migration target for retailers who need a stable path with a shorter SFRA migration timeline, particularly those with large existing cartridge investments or integrations that are already SFRA-compatible. SiteGenesis to Composable Storefront is the stronger fit for retailers starting from a clean slate or those whose 24-month roadmap requires headless architecture and front-end flexibility from day one. A qualified Salesforce Commerce Cloud partner can assess which path fits your situation before you commit resources to either.
Why choose Ranosys for SiteGenesis to SFRA migration services
Ranosys delivers SiteGenesis to SFRA migration solutions for enterprise retailers across the US and Southeast Asia. As a Salesforce Summit Partner, our SFCC team manages the full migration lifecycle: storefront audit, SFRA cartridge architecture design, custom cartridge redevelopment, integration validation, performance optimization, and post-launch support.
Our SFRA implementation services and SiteGenesis migration services include:
- SiteGenesis storefront audit and migration scoping
- Storefront Reference Architecture (SFRA) cartridge design and custom development
- Third-party integration re-implementation covering payments, OMS, search, and marketing
- SEO continuity planning and redirect implementation
- QA, regression testing, and performance validation
- SFRA zero downtime launch planning and execution
- Salesforce Commerce Cloud managed services and post-migration support
Every engagement starts with a structured discovery phase so your team has a realistic view of scope, SFRA migration timeline, and cost before development begins.
