Aura to LWR: migrating a B2B Commerce store

Migrate an Aura B2B store to LWR when you need features or changes that are hard to build in Aura, or when custom Aura code keeps growing. There is no deadline: as of 27 October 2026 Salesforce has published no retirement date for Aura stores. Salesforce recommends the LWR template for new stores and offers a migration guide1 for existing ones, but no migration tool. You create a new store from the B2B Commerce (LWR) template and move components, checkout and configuration into it. I plan this as a rebuild of the storefront on top of the same commerce data, and I start inside the running Aura store.

Which store do you run, and is there a deadline?

Salesforce B2B Commerce, which Salesforce now also markets as “Agentforce Commerce for B2B”, has had three generations: the Visualforce managed package, stores on the core platform built with the Aura template, and stores built with the LWR template (Lightning Web Runtime). How to tell them apart is covered in B2B Commerce versions: Visualforce, Aura or LWR?.

According to the migration guide2, only orgs that were enabled for Commerce before Spring ’23 can still choose the Aura template. Salesforce recommends the B2B LWR template for new stores and suggests that existing Aura stores consider migrating.

A retirement date does not exist. Aura stores are not on the list of active product and feature retirements3, and the migration guide names none. The list itself says that retirements not listed there are communicated through release notes, help articles or targeted emails, so keep an eye on the release notes three times a year. Until then, decide by features and effort, not by fear of a date nobody has announced.

An LWR store runs only Lightning web components

The key differences4 are short, but each one affects custom code:

Area	Aura store	LWR store
Components	Aura components and Lightning web components	Lightning web components only
Styling	Your own CSS classes	--dxp styling hooks, mapped to the Theme panel
Data access	force:recordData, lightning:recordForm	Wire service on Lightning Data Service
Checkout	Checkout flows in Flow Builder	Salesforce Commerce Checkout, arranged in Experience Builder
Cart page	Record page	Named page

Two rows deserve attention. The first is checkout. For Aura stores, Salesforce says to use Flow Builder to create checkout flows5. LWR stores use the Salesforce Commerce Checkout that is installed with the store. Its shipping, tax and payment integrations run separately from the Aura checkout subflows, and Salesforce recommends extensions over integrations6 for custom logic. If your Aura checkout has a subflow that calls the ERP for a credit check, that logic has to be rebuilt. How extensions work is covered in Commerce extensions: custom code that survives updates.

The second is the cart page. It changed from a record page to a named page, so every component that navigates to the cart or builds a link to it with lightning/navigation needs an update, according to the guide’s Migrate Your Store7 page.

Prepare in the Aura store first, then switch

The guide splits the work into preparation in the Aura store and the switch to a new LWR store. I follow the same split, because the preparation can run while dealers keep ordering.

Preparation in the running Aura store (Prepare for Store Migration8):

1. Inventory. In Setup, search for Lightning Components to list your Aura and Lightning web components.
2. Replace Aura components. Lightning web components run in Aura and LWR stores, often without changes. Aura components can contain Lightning web components, but not the other way round, so migrate child components first. If one Aura component cannot be replaced yet, reduce it to a thin wrapper. All Aura components have to go eventually.

For developers

How do I rework data access and events for LWR?

• Move data access to the top. Keep data operations in the outermost component, so the data layer changes in one place and nested components stay reusable.
• Convert events. Aura events declared with aura:event become DOM events in Lightning web components.
• Use wire adapters. Replace force:recordData with @wire and adapters from the lightning/ui*Api and Commerce namespaces. Apex methods you want to keep can be imported into Lightning web components.

The switch:

1. 01

   Create the store

   Create a store from the B2B Commerce (LWR) template in Setup. The guide states that a new template is needed to complete the migration (Create a Store with the LWR Template (opens in a new tab)).

2. 02

   Finish the refactoring

   Put the components into an SFDX project, finish the refactoring, update cart navigation and move branding to styling hooks.

3. 03

   Move the configuration

   Move the store configuration from the old store to the new one with a change set.

4. 04

   Publish

   Deploy, place the components in Experience Builder, preview on desktop and mobile, publish.

Salesforce writes that you do not have to recreate the store from scratch and that migration is mainly refactoring. That is true for the commerce data. For the storefront I would not rely on it: a new site, new styling, a new checkout and a new cart page add up to a rebuild of everything the buyer sees. I estimate and test it like one.

What does the guide leave open?

The migration guide covers components and store configuration. It says nothing about catalogue, buyer groups, entitlement policies and price books, or about URLs and dealer bookmarks. Plan explicitly how the new store is connected to the existing buyer groups and price books, and test it with real buyer accounts before any dealer sees the store.

Experience metadata is easier to handle in a pipeline than with change sets. Salesforce describes deploying store metadata9 with the Salesforce CLI and the ExperienceBundle or DigitalExperienceBundle types, committed to version control. The same page warns that some settings are not captured by the metadata and must be reapplied by hand, and that domains, URLs and single sign-on are tasks after deployment. Write those settings down before the switch. Where store configuration belongs in a pipeline is covered in the DevOps chapter on data and configuration.

When is it worth it?

I would plan the migration when at least one of these applies:

• A feature you need is not available or hard to build in your Aura store. Salesforce’s 2026 announcements, such as B2B Search, the Buyer Agent, headless commerce and order templates, do not say which store template they require. Check each one in the release notes and documentation before you base the migration on it.
• Custom Aura code keeps growing. Every new Aura component is code you will rewrite later.
• Checkout needs a change anyway. A new ERP interface or a new payment option is a good moment to rebuild checkout on LWR with extensions instead of extending a flow.
• The partner who built the store is leaving. A new partner should not have to learn Aura first.

If the store runs stably, has little custom code and no change is planned, waiting is a legitimate choice. Do the preparation steps anyway, because Lightning web components work in both stores.

Worked example: a machine builder has run an Aura store since 2021 with about 30 custom components and a checkout flow with an ERP credit check. In the first quarter the team replaces the leaf components with Lightning web components inside the Aura store and releases them normally. In the second quarter it builds the LWR store in a sandbox, rebuilds the credit check as a PlaceOrder extension and moves the styling to the Theme panel. Then one pilot buyer group switches to the new store, the old one stays online as a fallback for two weeks, and the remaining groups follow, as described in B2B shop rollout to dealers.

List Aura components and checkout subflows

Start with the inventory: list all Aura components, the checkout flow with its subflows and every place that links to the cart. Then decide which components you replace inside the Aura store in the next two releases. Plan the switch itself into your Salesforce release calendar, with regression tests for search, cart and checkout, because three Salesforce releases a year hit both the old and the new store. The other topics of this chapter, from agents to rollout, are in the B2B Commerce masterclass chapter on agents, migration and rollout.

Sources9

1. 1migration guide (opens in a new tab)developer.salesforce.com
2. 2migration guide (opens in a new tab)developer.salesforce.com
3. 3list of active product and feature retirements (opens in a new tab)help.salesforce.com
4. 4key differences (opens in a new tab)developer.salesforce.com
5. 5use Flow Builder to create checkout flows (opens in a new tab)developer.salesforce.com
6. 6extensions over integrations (opens in a new tab)developer.salesforce.com
7. 7Migrate Your Store (opens in a new tab)developer.salesforce.com
8. 8Prepare for Store Migration (opens in a new tab)developer.salesforce.com
9. 9deploying store metadata (opens in a new tab)developer.salesforce.com