A B2C Commerce Cloud org built in 2018 runs on SiteGenesis. The storefront works. The team has shipped seasonal launches every year. The codebase has 200+ pipelines, 80+ ISML templates, three payment provider integrations, a custom promotion engine. Salesforce officially stopped active SG development in 2017 and pushes every new customer to SFRA. The team's question is no longer whether to migrate, but when, and how much pain to accept.
Sapota's Salesforce team has worked on both SG-only orgs and orgs running parallel SG plus SFRA. The migration is real engineering. The decision to start it is more nuanced than the marketing material implies.
What the two frameworks actually do
SiteGenesis (SG) is the original B2C Commerce reference application. Pipeline-based, with a procedural flow defined visually in Studio. ISML templates render the markup. Logic spreads across pipelines, scripts, and template includes. Mature, well-understood, and the answer most Stack Overflow posts give.
Storefront Reference Architecture (SFRA) is the modern replacement, released in 2017. MVC architecture, controllers replacing pipelines, models passing structured data to views, middleware for request lifecycle. JavaScript-only (no XML pipelines). Cartridge composition via path-based overlay rather than custom inheritance. Salesforce recommends SFRA for every new project.
The frameworks are not compatible. A controller built for SFRA does not translate cleanly to a pipeline-based SG project. Custom code, custom integrations, custom payment flows all rebuild for the target architecture.
When SG is still the right answer
Three scenarios where staying on SG is defensible:
1. Heavy custom code investment with low business value at stake. An SG site processing modest order volume with custom payment, custom promotions, and three years of accumulated business logic. Migration cost may exceed 12-18 months of senior developer time. The same investment poured into new revenue features would produce more business value.
2. End-of-life or replatforming plans within 24 months. A brand evaluating Shopify, Adobe Commerce, or building custom is already off the Salesforce path. Migrating to SFRA just to migrate off again later is wasted effort.
3. Site running 24/7 with no engineering bandwidth. Migration requires staffing the work. Teams stretched thin on operational fires cannot also run a multi-quarter platform migration without dropping balls elsewhere.
These cases stay on SG. The platform continues to receive security patches but no new features. Plan operational maintenance accordingly.
When SFRA migration is the right move
Three signals pointing the other direction:
1. The roadmap depends on features SFRA has and SG does not. Modern payment integrations, headless storefront via SCAPI, certain Einstein commerce features, Composable Storefront connectivity, LINK cartridges built only for SFRA. If the next 12 months of roadmap is blocked by SG limitations, migration is the path.
2. The team is growing or changing. New SFCC developers are trained on SFRA. Hiring SG specialists is harder every year. A team that turns over even partially loses tribal SG knowledge that is hard to rebuild. SFRA is the path with the documentation, the community, and the future talent supply.
3. The current codebase is closer to vanilla SG than heavily customized. A standard SG implementation with light customization migrates in three to six months. A heavily customized one takes a year or more. Migrate while the cost is bounded.
The four-phase migration approach
Sapota's standard SG-to-SFRA migration runs in four phases. Realistic total: 6 to 12 months for a mid-size mature SG site.
Phase 1: Audit (3 to 6 weeks)
Inventory the SG codebase: pipelines, controllers, scripts, templates, cartridges, custom payment integrations, jobs, web services. Classify each artifact by complexity (simple, medium, complex). Estimate effort per artifact. Total the weeks, add 30 percent buffer.
The audit also surfaces tribal knowledge. Code nobody on the current team remembers writing, business rules baked into pipeline conditions, integrations with three-letter acronyms. All of this becomes visible during audit and saves discovery time during migration.
Phase 2: Mapping and parallel cartridge structure (4 to 8 weeks)
Design the SFRA equivalent for each SG artifact. Set up a parallel cartridge path that loads SFRA cartridges alongside SG, allowing incremental migration without a hard cutover.
A typical cartridge path during this phase:
new_sfra_storefront:plugin_payment:int_avalara:app_storefront_base
:int_legacy_promotions:custom_sg_extensions:app_storefront_legacy
SFRA cartridges sit at the front. Legacy SG cartridges remain at the back for unmigrated functionality. Each request flows through both stacks; SFRA controllers handle migrated pages, SG pipelines handle the rest.
Phase 3: Parallel run and incremental migration (3 to 6 months)
Page by page, controller by controller, integration by integration, content moves from SG to SFRA. The order is informed by traffic and risk:
- Low-traffic informational pages first. Practice the migration mechanics without risk.
- Core browse and search pages second. Volume builds confidence in the new framework.
- Cart and checkout last. Highest revenue impact, highest risk, migrated only after the rest is stable.
Each migrated component goes live behind feature flags or A/B configuration. SG path stays available as fallback for the first weeks.
Phase 4: Decommission and cleanup (1 to 2 months)
All pages run on SFRA. Legacy cartridges removed from the cartridge path. SG-specific code archived. Documentation updated. License sizing reviewed (some SG-era cartridge licenses can be retired).
The decommission is mostly housekeeping. Resist the temptation to skip it; legacy code in unused cartridges accumulates security exposure over time.
Common migration mistakes
Five patterns Sapota has seen on engagements:
1. Big-bang cutover. A team plans to migrate everything in one quarter and switch over a single weekend. Reality: untestable scope, mid-quarter incidents, executive panic. Always migrate incrementally with parallel run.
2. Lift-and-shift without refactoring. SG patterns translated literally to SFRA controllers. The code works but does not leverage SFRA's middleware composition or model patterns. Two years later, the codebase is "SFRA shaped but SG flavored," costlier to maintain than either pure form.
3. Custom code over reference. Rewriting controllers from scratch instead of extending app_storefront_base. Loses the ongoing upgrade benefits Salesforce ships in each base release.
4. Underestimating data migration. Catalog, customer, and order schema differences between SG and SFRA cartridge models. Field mapping audits missed during planning surface as data quality issues post-cutover.
5. Treating it as front-end only. Migration touches integrations (payment, tax, shipping, OMS), jobs, and email templates. Scope these in from the start; do not discover them mid-migration.
What good migration timing looks like
Programs that migrate well have these conditions in place:
- Executive sponsorship for a multi-quarter project with a clear business case.
- Dedicated team that is not also running daily operations.
- Audit completed before committing to the timeline. No migration scheduled before the inventory exists.
- Parallel cartridge approach planned from day one.
- Quarterly checkpoints with the option to pause, reassess, or accelerate.
- Plan for the renewal cycle: customers and orders flowing through both old and new paths during parallel run, reconciled monthly.
Migration timing is one of the most consequential decisions a B2C Commerce program makes. Sapota's Salesforce team has shipped both SG-only and SFRA implementations, including parallel-run migrations on production B2C sites. The 4-phase approach above is what we run when scope and timeline support it, adapted to specific catalog volume and integration complexity.
Planning or running a SiteGenesis to SFRA migration? Sapota's Salesforce team handles audit, parallel cartridge design, and incremental migration on production B2C Commerce engagements. Get in touch ->
See our full platform services for the stack we cover.
Company News
