# Transfer content between environments

## Overview

By default, Sitefinity Cloud comes with a *Staging* (non-Production) environment and a *Production* environment. The *Staging* environment is meant to be used by developers for testing functional changes with test content, while *Production* is meant to be used by content editors to manage the actual content of the website.

* Functional changes originate on a local development environment, are then committed to the source code and deployed to *Staging* and *Production* via the Continuous Delivery pipeline.
* Content changes originate on the *Production* environment and can be restored back to other non-Production environments like *Staging* or а local development environment.

This provides a separation between code and content, where developers cannot accidentally promote test/dummy content to *Production* and content editors cannot accidentally change the database schema on *Production*.

In case you have more complex content management processes that require content changes to be made on a non-Production environment before being promoted to *Production*, or a complicated migration project that requires content to be moved from one environment to another, Sitefinity Cloud provides several options to do that.

## Content structure (database schema changes)

Sitefinity enables you to customize the structure of content types that come out-of-the-box as well as build new content types (also called dynamic modules). A custom content type is a custom content structure that represents a business object. Examples of custom content types can be FAQ, Release Notes, University course descriptions, and so on. Sitefinity provides a visual interface for modeling dynamic content types called Module Builder.

Content structure changes are considered functional changes, part of the application development process. As such, content structure changes should be done on the *Staging* (non-Production) environment and then synced to *Production* using Site Sync. This allows developers to implement and test content structure changes, as well as related custom widgets and functionality, before they reach the *Production* environment. By default, content changes cannot be synced from *Staging* to *Production* - this provides separation, where developers cannot accidentally promote test/dummy content to *Production*, while content editors cannot accidentally change the database schema on *Production*.

[![Transfer Content Structure (Default Setup)](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/0f25b12a8ff649c475a82dc1eca0f25f/transfer-content-structure-and-content-\(default-setup\).jpg "Transfer Content Structure (Default Setup)")](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/0f25b12a8ff649c475a82dc1eca0f25f/transfer-content-structure-and-content-\(default-setup\).jpg)

If the [Developer Extensions](https://www.progress.com/documentation/sitefinity-cms/cloud/platform-overview/developer-extensions--sitefinity-cloud-paas-) toggle is enabled, the Sitefinity CMS application becomes fully customizable through code changes. In this setup, content structure changes can only be done on a local development environment. Developers use *Export for deployment* to generate the database export files and then commit them to source code (see details below). The files then automatically become part of the deployment package. Once the package is deployed to a Sitefinity Cloud environment, Sitefinity will detect the changes and apply them on startup. This makes the source code "the single source of truth" when it comes to the database schema and ensures consistency across the environments.\
In this setup, content structure changes are not allowed directly on Sitefinity Cloud environments to avoid conflicts with changes done on local development environments. Using the source code also allows for comparing and merging changes made by different developers.

The diagram below visualizes the comparison to the default setup.

[![Transfer Content Structure (comparison)](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/e70f8957a1853e07a0795d59b10f10ec/transfer-content-structure-and-content.jpg "Transfer Content Structure (comparison)")](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/e70f8957a1853e07a0795d59b10f10ec/transfer-content-structure-and-content.jpg)

### Use Export for deployment to improve developer collaboration

> info  **NOTE**: This section applies only when the [Developer Extensions](https://www.progress.com/documentation/sitefinity-cms/cloud/platform-overview/developer-extensions--sitefinity-cloud-paas-) toggle is enabled.

The *Export for deployment* mechanism enables you to export all database schema changes in a specific format on the file system. The exported files can then be added to your solution and committed under source control.

> info  **NOTE**: The Deployment folder is not included in the Visual Studio project by default. To promote the changes to the next environment, you must explicitly include the folder in your project.

Every time Sitefinity starts, it checks the` ~/App_Data/Sitefinity/Deployment` folder and applies any changes detected there. This way, all members of your development team can collaborate by committing their database schema changes to source control. This helps with merging changes and resolving conflicts, and ensures they are all working with the same schema locally.

### Promote database schema changes to Sitefinity Cloud environments

> info **NOTE**: This section applies only when the [Developer Extensions](https://www.progress.com/documentation/sitefinity-cms/cloud/platform-overview/developer-extensions--sitefinity-cloud-paas-) toggle is enabled.

After you have used *Export for deployment* to generate the database export files and have committed them to source code, the files automatically become part of the deployment package. Once the package is deployed to a Sitefinity Cloud environment, Sitefinity will detect the changes and apply them on startup. This makes the source code "the single source of truth" when it comes to the database schema and ensures consistency across the environments.

## Use additional environment for Content Authoring (Content Pipeline)

The Additional Environment add-on can be used in different ways, one of which is serving as a dedicated *Authoring* environment for content editing. The *Authoring* environment is set up as a duplicate of the *Production* environment, having identical code deployed to both environments through the Continuous Delivery pipeline. This enables content editors to use an environment that has the same Renderer application version and database schema as the *Production* environment. In this setup, Site Sync is automatically configured from *Authoring* to *Production*, allowing content editors to make changes on *Authoring* first and then promote them to *Production*. For more information, see [Site Sync](https://www.progress.com/documentation/sitefinity-cms/sitesync).

For the purposes of specific scenarios, you might need to sync content between multiple or all environments. This is supported in general, however not recommended, because the environments can have different Renderer application versions or database schemas (which can interfere with the synchronization process). In case you have such specific need to customize the setup, contact your Customer Success Manager, onboarding facilitator or Progress Sitefinity Support.

If the [Developer Extensions](https://www.progress.com/documentation/sitefinity-cms/cloud/platform-overview/developer-extensions--sitefinity-cloud-paas-) toggle is enabled, the Sitefinity CMS application can also have different versions on the different environments, which prevents Site Sync from operating. This is why, the same Sitefinity CMS deployment package is deployed to both *Authoring* and *Production*.

The diagram below demonstrates how an *Authoring* environment works in the default setup as opposed to enabled Developer Extensions (PaaS) setup.

[![Transfer Content Structure and Content (with Authoring Environment)](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/5185eef9950cab8ff61ed73399b92c54/transfer-content-structure-and-content-with-content-authoring-environment.jpg "Transfer Content Structure and Content (with Authoring Environment)")](https://www.progress.com/documentation/sitefinity-cms/cloud/assets/5185eef9950cab8ff61ed73399b92c54/transfer-content-structure-and-content-with-content-authoring-environment.jpg)

## Restore the database between environments

Sitefinity Cloud provides a pipeline to restore the database from one environment to another. For more information, see [Restore the database between environments](https://www.progress.com/documentation/sitefinity-cms/cloud/backup-and-restore-the-project-database#restore-the-database-between-environments).\
When using this approach, you replace the content and schema on the target environment with the ones from the source environment. This approach does not allow you to merge content changes made on the target environment with ones made on the source environment. If you need more granular control over what content is being transferred, you have to use Site Sync instead.

## Import a database from a BACPAC file

You can import a database from a `.bacpac` file to any environment. For more information, see [Import a database from a BACPAC file](https://www.progress.com/documentation/sitefinity-cms/cloud/backup-and-restore-the-project-database#import-a-database-from-a-bacpac-file).\
When using this approach, you replace the content and schema on the target environment with the ones from the BACPAC file. If you need more granular control over what content is being transferred, you have to use Site Sync instead.