---
schema_version: "1"
id: 2b834243c0c3a042866a284c97e09b1a650bd4502696efd290939c118e5e9984
title: Considerations Before You Migrate an Aura Site to Lightning Web Runtime (LWR)
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/experience/264-0-0/exp_cloud_migrate_lwr_considerations.md
canonical_url: https://help.salesforce.com/s/articleView?id=experience.exp_cloud_migrate_lwr_considerations.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: b10980521df0ded364914aa1ea8fab9c48753f4296f0b54e86485e285c3cef9c
description: Sites that run on Lightning Web Runtime (LWR) boast increased speed, scalability, security, and design flexibility over Aura sites. Migrating your Aura site to an LWR site requires considerable planning. Keep these considerations in mind.
products:
- Experiences
release: "264"
---
# Considerations Before You Migrate an Aura Site to Lightning Web Runtime (LWR)
Sites that run on Lightning Web Runtime (LWR) boast increased speed, scalability, security, and design flexibility over Aura sites. Migrating your Aura site to an LWR site requires considerable planning. Keep these considerations in mind.
### Required Editions
Available in: Salesforce Classic and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions
Important Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations.
## General
- Unlike Aura templates, which have specific components for specific site functions, LWR templates provide more general components that use concepts like data binding to achieve the same goals, but faster and more dynamically.
## Custom Aura Components
- Identify any custom Aura components on your site, and replace them with Lightning web components (LWCs).
- When building LWCs, use new LWC features such as [@slot](https://www.learnexperiencecloud.com/s/article/How-to-Create-Super-LWCs-with-Slots-in-Experience-Cloud-LWR), [responsive properties](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/get_started_responsive_properties.htm), and [custom property editors](https://resources.docs.salesforce.com/rel1/doc/en-us/static/pdf/Custom_Property_Types_and_Editors_Beta_Summer-23.pdf).
- Use data binding to show CRM data and CMS content on the site, where possible, instead of wires or Apex controllers.
- See [Learn Experience Cloud](https://www.learnexperiencecloud.com/experience-cloud-lwr-apps) and [Github](https://github.com/forcedotcom/commerce-on-lightning-components) for LWCs you can use for reference.
## Object and Site Pages
- We recommend that you use the same base URL for object pages in the LWR site that mirror existing object pages in the Aura site. For example, if you have an existing page in your Aura site like `www.company.com/s/account/123456789/account-name`, we recommend that you give the object page in LWR a base URL of `/account`. Using the same base URL makes it easier for you to set up redirects later.
- We recommend that you use the same base URL in the LWR site that mirrors existing site pages in the Aura site. For example, if you have an existing Builder page like `www.company.com/s/my-custom-page`, use `/my-custom-page` as the base URL in your LWR site.
- Replace your Aura page layouts with flexible page layouts in LWR.
## Custom Domains and Custom URL
Let’s say that your Aura site URL uses a custom domain like `www.company.com/s` or a Salesforce domain like `company.my.site.com/s/`, and the same domain serves the new LWR site, but without the /s/.
- Create the LWR site without /s/.
- Before go-live, set the LWR site to use `company.my.site.com/path` so that you can test redirects.
- At go-live, delete the Aura site’s custom URL. In Setup, create a custom URL for the new LWR site that uses the custom domain.
- To keep the old Aura site to serve content that you can’t render in LWR yet, add a new custom URL for the Aura site with a path such as `/archive`.
## Topics
- If your Aura site uses topics and topic assignments with custom object records, replace the topics and topic assignments with custom objects such as Topic\_\_c and Topic\_Assignment\_\_c.
- To drive sharing, consider setting up a master-detail relationship between Topic\_Assignment\_\_c and topic, and consider setting up lookup relationships to other objects for topic assignments
- To drive sharing with site users, if needed, consider adding custom fields like a Site Identifier picklist field on the Topic\_\_c object.
- Grant the proper object permissions to the Topic\_\_c and Topic\_Assignment\_\_c objects for the LWR site guest user.
- Create guest sharing rules to share the right Topic\_\_c records with the guest user record. If Topic\_Assignment\_\_c records have a master-detail relationship toTopic\_\_c, Topic\_Assignment\_\_c records are also visible.
## Record Data Extract, Transform, and Load (ETL)
- Topics and Topic Assignments
- Export all topics and topic assignments for objects that are currently in use on the Aura site.
- Import topics into the new custom object Topic\_\_c.
- Import Topic Assignments into the new custom object Topic\_Assignment\_\_c, relating the new Topic\_\_c record with the EntityId that the topic assignment was related to
- Records Containing URL Fields
- Export records with the URL fields.
- Locally update the URL field values with the new site URL. Import the file back into the org to update the records.
## User Sharing and Permissions
- Guest Users
- A new guest user is automatically created when you create an LWR site. Review the profile permissions and permission set assignments for the Aura site guest user, and carry over any necessary configuration to the LWR site guest user.
- If there are existing, and still needed, guest user sharing rules in place for the Aura site’s guest user, duplicate them for the LWR site’s guest user.
- Authenticated Users
- Any existing sharing mechanisms for authenticated users are carried over from the Aura site to the LWR site.
- Create sharing mechanisms for any new custom objects or components that you created for the new LWR site.
- Any existing profile, permission set, and permission set assignments are carried over from the Aura site to the LWR site.
## CSS
- Any CSS overrides that target standard markup in Aura don’t apply to markup in LWR. You must update the CSS style sheets.
- There’s no dedicated CSS editor at the site-level for LWR sites. Add your CSS directly in the head markup. Components on LWR sites have a CSS Class section on the Style tab, where you can add a CSS class at the component level.
- If the style sheet is a file that’s part of an archive (.zip), the markup is
- ```
```
- If the style sheet is the only file uploaded directly as a static resource, and not part of an archive (.zip), the markup is
- ```
```
- Test and confirm that CSS in LWCs works properly.
- Design tokens in LWR sites differ from the ones in Aura sites. To update the tokens used in your components and style sheets, refer to the [–dxp styling hooks documentation](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_hooks_map.htm).
## Google Analytics and Other Head Markup Scripts and Style sheets
- Google Analytics
- If you’re using the standard integration for Google Analytics, you must reconfigure it in LWR. As long as the LWR site is using the Aura site’s domain name, you can use the same Google Analytics ID.
- If you’re using a script in the head markup, paste the script to the LWR site. As long as the LWR site is using the Aura site’s domain name, the script works.
- Style sheets and Other Static Resources
- Include any style sheets, JavaScript files, or other static resources in the head markup of the LWR site.
## Sitemap and Snapshot Generation
- Sitemaps and snapshots are generated with the `my.site.com` domain, which means that you can test them before migrating the custom domain from the Aura to LWR site. To minimize SEO impact, make sure that sitemaps and snapshots are populated properly.
- Consider placing a redirect from `/s/sitemap.xml` to `/sitemap.xml`. That way, you can redirect any sitemap submissions that you have to the new sitemap without updating them everywhere.
## File Asset Images
- f you’re referencing any file assets as `/file-asset/`, you must update them to `/sfsites/c/file-asset/`.
## CMS
- With Winter ’24, you can publish content from all CMS workspaces to LWR sites.
- There are no CMS components in LWR sites. Use data binding to show CMS content in LWR sites.
## Redirects
Consider adding these redirects (in CSV format).
- /s, / and /s/, /: Redirects the Aura home page URL to the LWR home page URL.
- /s/sitemap.xml, /sitemap.xml: Redirects the Aura sitemap URL to the LWR sitemap URL, rather than resubmitting to search engine crawlers.
- /s/(customPage), /(customPage): Catches all pages to redirect one-level pages to their equivalent one-level pages in LWR.
- /s/article/(articleAlias), /article/(articleAlias): Knowledge article redirect./s/contact/(contactId), /contact/(contactId): Object detail page redirect. (Here, contact is used as an example, but the same structure can be applied to any standard or custom object.)
- External URL redirects aren’t supported. If you need an external URL redirect, set up a solution that redirects to a Visualforce page, which in turn redirects externally.
## Multilingual Sites
- The new LWR language URL construct is a path rather than a query parameter, as it is in Aura. See [Create a Multilingual LWR Site](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/multilingual_lwr.htm).
## Visualforce Pages
- If you run any Visualforce pages in your Aura site, such as custom robots.txt files, custom sitemaps, or other custom Visualforce pages, note the difference in URL structure between Aura and LWR for running Visualforce pages.
- In Aura, the site is served behind the /s path, and Visualforce pages are served one level higher.
- Example: Aura site at `mycompany.my.site.com/helpcenter/s/` would serve Visualforce pages from `mycompany.my.site.com/helpcenter/apex/myVisualforcePage`.
- Example: Aura site at `helpcenter.mycompany.com/s/` would serve Visualforce pages from `helpcenter.mycompany.com/apex/myVisualforcePage`.
- LWR sites are served at the root right after the site path, if any, and Visualforce pages are served from a path that is automatically created as a default for that site. The automatically created path for Visualforce pages is a combination of the site’s path + “vforcesite”. You can customize and modify this path from the Custom URLs section in Setup, if necessary.
- Example: LWR site at `mycompany.my.site.com/helpcenter/` would serve Visualforce pages from `mycompany.my.site.com/helpcenter/helpcentervforcesite`.
- Example: LWR site at `helpcenter.mycompany.com` would serve Visualforce pages from `helpcenter.mycompany.com/vforcesite`.
## Mobile Publisher Apps
- Mobile Publisher offers beta support for LWR sites.
- The Playground app allows LWR sites with or without “/s”
- Check out [LWR (Beta) Limitations](https://help.salesforce.com/s/articleView?id=xcloud.branded_apps_lwr_gaps.htm&type=5&language=en_US)
- We strongly recommend that you test your app in the Playground app before creating and requesting a beta app.
Note This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at [Agreements and Terms](https://www.salesforce.com/company/legal/agreements/).
#### See Also
- [B2B Commerce Aura to LWR Migration Guide](https://developer.salesforce.com/docs/commerce/lwr-migration/overview)