Loading
Important Advisory: iOS Update Impacting CG Mobile ApplicationRead More
Experience Cloud
Considerations Before You Migrate an Aura Site to Lightning Web Runtime (LWR)

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
Applies to: LWR and Aura sites
Important
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).
  • See Learn Experience Cloud and Github 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
    • <link type="text/css" rel="stylesheet" href="{ basePath }/resource/<apiName>/<stylesheetFileName>.css?{ versionKey }" />
  • If the style sheet is the only file uploaded directly as a static resource, and not part of an archive (.zip), the markup is
    • <link type="text/css" rel="stylesheet" href="{ basePath }/resource/<apiName>?{ versionKey }" />
  • 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.

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/<fileAssetAPIName>, you must update them to /sfsites/c/file-asset/<fileAssetAPIName>.

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

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.
  • We strongly recommend that you test your app in the Playground app before creating and requesting a beta app.
Note
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.
 
Loading
Salesforce Help | Article