---
schema_version: "1"
id: 21d479d9c32f5b4369c2d60116258846664306c241bd2a824ce32b3cc3a70067
title: Deploy an Experience Cloud Site from Sandbox to Production
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/experience/264-0-0/networks_migrate_overview.md
canonical_url: https://help.salesforce.com/s/articleView?id=experience.networks_migrate_overview.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 2e0f42a757ce0920a0904882f6eb7021e83297b6b59cc9ee4a9de4162bd1f5fd
description: 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.
products:
  - Experiences
release: "264"
---
# 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.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Enterprise</strong>, <strong>Performance</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong> Editions</td></tr></tbody></table>

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](https://trailhead.salesforce.com/content/learn/trails/determine-which-application-lifecycle-management-model-is-right-for-you) on Trailhead.

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.

## 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.

![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-experience-communities-264-0-0-production-enus/bf7df212-91a1-4fa3-a007-4d6f3e3b470b/images/icon_tip.png)

Tip 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.

- **[Deploy Your Experience Cloud Site with Change Sets](https://help.salesforce.com/s/articleView?id=experience.networks_migrate_changesets_overview.htm&release=264.0.0&type=5)**  
    Use change sets to move all or part of your Experience Cloud site between related orgs that have a deployment connection. You can use the Network component type to move any full Experience Cloud site. Or, you can use the Digital Experience component type to move partial site content for enhanced LWR sites.
- **[Deploy Your Experience Cloud Site with the Metadata API](https://help.salesforce.com/s/articleView?id=experience.networks_migrating_from_sandbox.htm&release=264.0.0&type=5)**  
    Use Metadata API to move your Experience Cloud site from one Salesforce org to another. Set up and test your site in your test environment, and then retrieve the site’s data and deploy it to your production org.