SFRA to PWA Kit Migration: A Phased Strategy That Works

Migrating from SFRA to PWA Kit isn't a binary decision you resolve in a single planning sprint. It's a transition that, if mismanaged, puts revenue, SEO, and your team's sanity at risk. The reason is simple: the storefront can't stop selling while the architecture changes underneath it. The practical answer isn't "big bang." It's controlled coexistence between the monolith and headless for a defined period, with clear exit criteria.

This article doesn't treat PWA Kit as an automatic synonym for better performance. It treats it as an architecture change with real cost: duplicated maintenance, routing complexity, and SEO risk. That cost only pays off when the gain in performance and delivery speed outweighs the effort. The goal here is to give the Tech Lead arguments and a plan to defend the right decision with data, not with headless hype.

Why the "big bang" migration almost always fails

Replacing SFRA with PWA Kit in one shot means rewriting PDP, PLP, cart, checkout, search, and customer accounts. It also means migrating every integration: ERP, OMS, payment, and shipping. All of it has to be production-ready before anything ships. In practice, this freezes the business roadmap for months. For a Tech Lead without the authority to grow the team, a frozen roadmap means technical debt piling up in parallel, while nobody ships a new feature.

The risk isn't only about timeline. It's regression: a new checkout, tested only in staging, goes live all at once. Any edge case bug (coupon logic, split payment, international shipping) becomes a production incident with no fallback path. Incremental migration exists precisely to eliminate this all-or-nothing bet.

Applying the strangler pattern to SFCC

The strangler pattern works by strangling the monolith piece by piece: replacing functionality one unit at a time until the old system becomes redundant. It's the most defensible strategy for migrating from SFRA to PWA Kit because it lets you:

Validate PWA Kit in production with real traffic before migrating a critical page (checkout, for example);
Roll back a specific route to SFRA without rolling back the entire project;
Spread the team's effort across months instead of concentrating risk into a single go-live window.

In practice, this means SFRA keeps serving part of the catalog while PWA Kit takes over another part. Both stacks run simultaneously for a period. This is where most migration guides fall short: they describe the target architecture but skip the intermediate state. That intermediate state is exactly where the Tech Lead actually lives.

Community technical guides in the SFCC space, like the Realm Split Guide for Migrating an SFCC Site (Rhino Inquisitor), document an equivalent line of reasoning for realm migrations. The core idea is separating what changes from what stays stable, treating the transition as an architecture project with named phases rather than a single cutover. The same principle applies to migrating rendering (SFRA) to headless (PWA Kit): the unit of migration isn't "the site," it's the route.

Route-based routing: the piece that makes coexistence work

The mechanism that enables the strangler pattern here is route-based (or URL-pattern-based) routing at the edge/CDN layer. It decides, per request, whether the response comes from SFRA or from PWA Kit.

Path-based routing. /product/ and /category/ go to PWA Kit as soon as they're ready; /checkout/ and /my-account/ stay on SFRA until migrated. Simple to implement, but it requires discipline to avoid "orphan" URLs, routes that exist in both systems with diverging responses.

Feature flag / header-based routing. Useful for gradual rollout within the same route (for example, 10% of PLP traffic goes to PWA Kit). This lets you compare performance and conversion rate side by side before the final cutover.

Domain or temporary subfolder routing. Less elegant for the end user, but it reduces CDN configuration complexity early in the project. It's useful when the team is small and needs to prioritize delivery speed over architectural elegance.

The trade-off here is direct: the more granular the routing, the more control you have over risk. In exchange, configuration complexity grows, along with the surface area for routing bugs. This is a silent problem that doesn't show up in functional testing, only in production under load.

This isn't just architecture theory. On an international project for a health and beauty retailer in the UK and Ireland, we ran a migration following exactly this reasoning. We first migrated the CMS to Amplience, building the components and content pages. Then we configured the domain's firewall/edge layer to route those content pages specifically to PWA Kit, while the rest of the navigation kept being served by the legacy site.

The remaining routes were absorbed into PWA Kit in sequence, in technically controlled phases. Each phase was validated in production before enabling the next traffic cutover. The practical gain from this phasing wasn't only technical. It gave the business team visibility into real progress, without requiring a single high-risk go-live.

Session and authentication: where coexistence breaks

One of the most common mistakes in incremental migrations is underestimating session sync between SFRA and PWA Kit. SFRA uses traditional server-side sessions; PWA Kit consumes SLAS (Shopper Login and API Access Service) via token. If a shopper navigates between an SFRA route and a PWA Kit route in the same cart, they should never perceive the system switch. Cart, login, and preferences need to persist.

This is exactly the kind of technical problem addressed by community documentation on SLAS Session Sync in SFRA and SiteGenesis (Rhino Inquisitor). The focus there is keeping tokens and sessions coherent between the server-session world and the headless token world. Ignoring this during planning is the most common cause of "phantom logout" and lost carts during coexistence periods. It's also the kind of bug that erodes business confidence in the migration, even when the architecture itself is correct.

Token migration in general deserves its own scrutiny during this kind of transition. We covered a related case in depth in our article on UUID to JWT token migration in Salesforce Commerce Cloud, which walks through the operational risks of changing how identity is represented across an SFCC storefront, a problem that rhymes closely with what happens during SFRA-to-PWA-Kit session handoff.

Session and authentication aren't the only piece of state that needs to survive the stack switch. Shopper context (geolocation, currency, audience segmentation) also needs to persist when a route migrates from SFRA to PWA Kit. This is the piece PWA Kit consumes via the Commerce SDK to keep personalization consistent between both stacks during coexistence, without depending on server-side session.

SEO during the transition: what can't break

SEO is the most fragile asset in a rendering migration, because Google reindexes with delay and penalizes inconsistency. Non-negotiable points:

301 redirects before the traffic cutover, not after. If the URL structure changes between SFRA and PWA Kit, the redirect needs to exist the moment the old route stops responding. Never after.
Consistent canonical tags and meta tags between both stacks during coexistence. If SFRA and PWA Kit generate different title/description pairs for the same product entity, at different phases of the rollout, that's a problem. Google treats it as unstable content, which affects ranking. SFCC meta tag rules have documented nuances (Rhino Inquisitor, Deep Dive into SFCC Meta Tag Rules) worth reviewing before replicating that behavior in PWA Kit.
A single, up-to-date sitemap, reflecting which system serves each URL at any given moment. Not two competing sitemaps.
Core Web Vitals monitored per route, not just globally. It's common for PWA Kit to improve LCP on the PLP while worsening CLS on the PDP due to poorly tuned hydration. The aggregate metric hides this.

The most expensive mistake here isn't technical, it's sequencing. It means migrating a route before validating that the new stack's technical SEO is at the same level, or better, than the monolith's. Losing ranking on a high-traffic category during the transition costs more in revenue than any mid-term performance gain.

The real cost of duplicated maintenance

During coexistence, the team maintains two stacks. Catalog bugs, promotions, and integration issues need to be fixed in both places until the corresponding route's migration is complete. For a Tech Lead without the authority to grow headcount, this is the most concrete trade-off in the entire project.

Ways to mitigate it without pretending the cost doesn't exist:

Prioritize migration by maintenance impact, not only by business value. Migrating the routes that generate the most support tickets or hotfixes on the monolith first reduces the duplicated cost fastest.
Freeze new feature work on SFRA for routes already partially routed to PWA Kit, avoiding the team building the same business rule twice.
Set a shutdown deadline per phase, not a single "end of project" date. Each migrated route should have a decommissioning date for the corresponding SFRA code. Without this, "temporary maintenance" becomes permanent.

How to decide the migration order

The correct order usually follows decreasing risk, not decreasing business value:

PLP and content pages: lowest state complexity, highest perceived performance gain. Good for validating the PWA Kit stack in production with controlled risk.
PDP: more complex (variants, availability, personalization), but still no financial transaction involved.
Cart and customer account: requires the session sync discussed above.
Checkout: migrate last, and only after SLAS, session, and payment integrations have been validated in production during earlier phases.

Migrating checkout first, because it's the page most discussed in headless conversations, is the classic mistake. Whoever does this is optimizing for the demo, not for operational risk.

Conclusion

Migrating from SFRA to PWA Kit is an architecture decision with real trade-offs: performance against timeline, UX gain against duplicated maintenance cost, rollout speed against SEO risk. The strangler pattern with route-based routing, well-planned session sync, and SEO discipline during the transition don't eliminate that cost. But they make it visible, sequenced, and reversible. That's exactly what separates a defensible migration from a bet.

If your team is evaluating this kind of migration and needs to validate the strategy before committing the roadmap, it's worth talking to a team that has run this exact transition in production, with real traffic, without freezing delivery. Schedule a conversation with Develoci to discuss the phasing plan that fits your context.