Transfer content between environments

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.

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.

If the Developer Extensions 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.

Use Export for deployment to improve developer collaboration

NOTE: This section applies only when the Developer Extensions 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.

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 

NOTE: This section applies only when the Developer Extensions 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.

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.

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

Sitefinity Cloud provides a pipeline to restore the database from one environment to another. For more information, see 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.

You can import a database from a .bacpac file to any environment. For more information, see 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.