Experience Cloud Developer Guide

Get Up to Speed with Experience Builder Sites
Develop Experience Builder Sites: The Basics
Customize the Look and Feel of an Experience Builder Template
Develop Secure Sites: Lightning Locker and CSP
Analyze and Improve Experience Builder Site Performance
Use a CMS with Your Experience Builder Site
Report on Deflections: The Deflection Signals Framework
Deploy an Experience Cloud Site from Sandbox to Production
Deploy Your Experience Cloud Site with Change Sets
Deploy Your Experience Cloud Site with the Metadata API
ExperienceBundle for Experience Builder Sites
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Deploy an Experience Cloud Site from Sandbox to Production

We recommend creating, customizing, and testing your Experience Cloud site in a test environment, such as a sandbox, before deploying it to your production org. When testing is complete, you can use change sets or Metadata API to migrate your site from one org to another. Deciding whether to use change sets or MD API depends on several factors. Some things to consider are the complexity of the changes that you’re migrating, your level of comfort with developer tools, and the application lifecycle management (ALM) model that you’re using.
Available in: Salesforce Classic (not available in all orgs) and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions

To learn more about the ALM models and development options available to you, check out Determine Which Application Lifecycle Management Model Is Right for You on Trailhead.

Tip

Lightning Bolt Solutions aren’t suitable for deploying Experience Cloud sites between your orgs. Use a Lightning Bolt Solution to share or sell a solution on AppExchange or implement a site with a turnkey solution or new look.

Note

Change Sets

If you’re more comfortable working with point-and-click tools, change sets are your deployment friend. A change set represents a set of customizations in your org (or metadata components) that you can deploy to a connected org.

You can manage your application using declarative tools. You don’t have to use a command-line interface or a version control system to meet your customization needs. You use the Setup menu to create changes in a development environment. You then migrate the changes between environments as you work through the ALM steps.

Your release artifact is a set of metadata changes relative to what’s in the production org. What gets released is only metadata that has been added or changed—if it doesn’t change, it’s not in the release.

Metadata API

If you’re up to speed on Metadata API and more comfortable in the world of code, use Metadata API to deploy changes programmatically. You can retrieve, deploy, create, update, and delete customization information for your org, such as Experience Cloud sites, custom object definitions, and page layouts.

Using Metadata API is ideal when your changes are complex or when you need a more rigorous change management process and an audit process (or version control system) to manage multiple work streams.

As with the change set process, the release artifact that you create is a set of metadata changes relative to your production org.

Some Experience Cloud site settings and features aren’t yet supported in Metadata API, so you have to migrate them manually between environments. Remember to track these changes so that you don’t forget to migrate them.

Tip