--- schema_version: "1" id: d2b5ee4af9c7131199b4884f1908e9fcc9748b7331d4e32eb98ae41d1fe7afb1 title: Deploy Experience Metadata to a Target Org collection: developer version: current locale: en-us portal_url: https://docs.salesforce.com/developer/current/en-us/commerce-cloud/salesforce-commerce/guides/d2c-commerce/b2b-d2c-comm-deploy-experience-metadata.md canonical_url: https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-d2c-comm-deploy-experience-metadata.html source_site: developer.salesforce.com content_type: documentation content_hash: 7004628717fea9052fa1316cc7b89d23c5d85765642b1009731c08bd501e85ff products: - B2B Commerce Developer Guide - Salesforce APIs --- # Deploy Experience Metadata to a Target Org Experience metadata supports the look and feel of the store, the user interface, and the user experience components. Deploying experience data can involve transferring customizations made to the store’s layout, design, and navigation and moving custom code or integrations. ## Deploy Experience Metadata with Change Sets To deploy the Experience metadata with Change Sets, follow the steps outlined in [_Migrate Your Store Configuration_](https://help.salesforce.com/s/articleView?id=commerce.comm_migrate_store.htm&type=5). Configure the source and target [_deployment connections_](https://help.salesforce.com/s/articleView?id=platform.changesets_about_connection.htm&type=5), and follow the same set of steps substituting Experience Bundle, Network, and Custom Site for the component types. ## Deploy Experience Metadata with the DigitalExperienceBundle and DigitalExperienceConfig for Enhanced LWR Sites The experience bundle metadata deployment process involves extracting the metadata from the source environment. Use Salesforce DX, Metadata API, change sets, or a third-party deployment tool, and then deploy to the target environment. Before you deploy DigitalExperienceBundle, review these considerations. - **Dependencies–**Make sure that all related metadata, such as Apex classes, Lightning components, and custom objects that the digital experience depends on, are included in your migration package. - **Compatibility–**Check that the target org is compatible with the features and settings of the digital experience that you’re migrating. - **Validation–**Test the migration in the target org without committing the changes so that you can address issues before the actual deployment. - **Backup–**Before deploying to the target org, back up your current target metadata in case you need to roll back to a previous state. - **Testing–**After deployment, thoroughly test the digital experience in the target org to confirm that all functionality works as expected. ## Deploy Experience Metadata with the ExperienceBundle for LWR Sites Note: These guidelines outline a general approach to deploying Experience metadata for LWR sites. Each Salesforce Commerce instance is unique, and your process can vary. To retrieve and deploy DigitalExperienceBundle metadata, follow these guidelines. 1. Make sure the source environment is fully configured. 2. Document any manual configurations or settings that the metadata doesn’t capture. 3. Use the Salesforce Command-Line Interface (CLI) to retrieve the DigitalExperienceBundle metadata from the source environment. a. For example: `Sf Projet retrieve start --target-org my_scratch –-metadata ExperienceBundle -dir ./` This sample command pulls the metadata into your local Salesforce DX project. 4. Commit the retrieved metadata to a version control system like DevOps or Git. This step is crucial for tracking changes and maintaining a history of your configurations. 5. Make sure that the target environment is ready for the deployment. a. Set up dependencies that the DigitalExperienceBundle requires, such as custom objects, Apex classes, permission sets, and profiles. 6. Deploy the Metadata. a. Use Salesforce CLI to deploy the DigitalExperienceBundle metadata to the target environment with a command. b. For example: `Sf project deploy start --metadata ExperienceBundle --target-org a-prod-org --dir ./` c. Monitor the deployment for any errors and resolve them as needed. 7. After the metadata is deployed, perform any necessary post-deployment steps such as configuring domains, updating URLs, or setting up single sign-on (SSO) if necessary. 8. Manually reapply any settings or configurations that aren’t deployed with the metadata. ## Deploy Experience Metadata with the Salesforce Metadata API, Salesforce CLI, and Salesforce DX Deploying a Salesforce B2B Commerce enhanced LWR store’s DigitalExperienceBundle metadata from one environment to another involves a series of steps. Here's a general process to follow. These guidelines outline a general approach to deploying Experience metadata for enhanced LWR sites. It’s important to have a rollback plan in case you encounter critical issues that can’t be resolved in the target environment post-deployment. Test your rollback procedures in the source org before the actual deployment to ensure that they work as expected. 1. Make sure that the source environment is fully configured. 2. Document the manual configurations or settings that the metadata doesn’t capture. 3. Use Salesforce CLI to retrieve the DigitalExperienceBundle metadata from the source environment. a. For example, this command pulls the metadata into your local Salesforce DX project. `Sf Projet retrieve start --target-org my_scratch –-metadata DigitalExperienceBundle -dir ./` 4. Commit the retrieved metadata to a version control system like DevOps or Git to track changes and maintain a history of your configurations. 5. Make sure that the target environment is ready for the deployment. a. Set up dependencies that the DigitalExperienceBundle requires, such as custom objects, Apex classes, permission sets, and profiles. 6. Deploy the metadata to the target environment. a. For example: `Sf project deploy start --metadata DigitalExperienceBundle --target-org a-prod-org --dir ./` Monitor the deployment for any errors and resolve them as needed. 7. Perform post-deployment steps, such as configuring domains, updating URLs, or setting up single sign-on. 8. Manually reapply settings or configurations that couldn’t be deployed with the metadata.