Keeping Xperience by Kentico Environments in Sync

In this post, you will learn about keeping environments in Xperience by Kentico in sync.

In software development, we typically employ several environments to offer a separation of features that are currently being developed, tested, approved, and released.

Commonly this involves a 4-tier approach having a development, test, stage, and production environment. The development stage is where all new features are introduced which often involves integrating existing content into that new feature set. One problem with this development cycle is having test content on the dev server that closely resembles content that will actually be used in a production environment. Without an accurate representation of the content, section titles may be too long, images too large or too small, menus too cluttered, and other visual inconsistencies that were not caught in the quality assurance step. For this reason, I recommend some type of periodic synchronization of content. With Xperience by Kentico, there are several approaches that can be used to accomplish this.


Content Staging

Hands down, this is the easiest approach. You select the pages you want to push, click the stage button, and magically your content appears on the target server. The hardest part of using content staging is configuring the servers to talk to each other.


  • Simple – After configuration, it’s a simple point and click
  • Selective Syncing – Portions of the content tree can be selected if all the content does not need to be synchronized.


  • Not efficient with large content trees – If a content tree contains thousands of nodes, syncing may take some time. Each page is processed and synchronized separately, which in some cases may be several seconds per page. The UI might become unresponsive while this takes place.
  • Page moves are not supported – Pages need to be in the same place in the content tree. If you have the same existing content in your target environment but in a different part of the content tree, staging will not work. The content will first need to be deleted from the target. This can be very time-consuming to do.
  • Staging is disabled on production – It is best practice to disable staging source changes on your production environment. Depending on the objects being tracked, this can have performance implications and should be avoided.
  • Network Dependent – Development environments are usually closed off to the outside world, so your production server may not be able to access your dev over the internet.
  • Manual Process – Cannot be easily automated.

Export/Import Sites

Objects selection screenshot

Using the Export wizard, you can export all of the content of a production site into an archive file. This content package can then be uploaded to other environments and imported.


  • No network needed – Since we are exporting the nodes into a downloadable package, direct communication from the production server to the dev is not needed.
  • Simple – Everything is built into Kentico without the need for other tools.


  • All or nothing – Everything in the content tree is included. You cannot be selective in what is synced.
  • Not efficient with large content trees – If a content tree contains thousands of nodes, syncing may take some time. Each page is processed and synchronized separately, which in some cases may be several seconds per page. The UI might become unresponsive while this takes place.
  • Manual Process – Cannot be easily automated.

Whole Database Sync

Full database backups are a common way to synchronize environments. Using this method, you can ensure that all the content, well everything, gets its way back down to dev. For example, you can create a data-tier export (bacpac) or create a backup (bak), transfer that to the development server, and restore.


  • Complete – Since this is a clone of prod, you can ensure that your environments are in sync.


  • Overwrites – When replacing the development database with production, anything still being actively worked on will be deleted. 
  • Settings – All development-only settings will need to be reconfigured, which can be time-consuming. Don’t forget to disable email notifications.
  • Bloated Database – Your production database normally contains lots of data that is only important to the production environment, such as users, form submissions, analytics, and activity. This can be several gigabytes of extra data.
  • Slow – If your database is the bloated type, then creating that backup, transferring it to the dev server, and restoring it can take a long time. Once it’s restored, all of the settings need to be set. If you had anything being developed, those changes would then need to be re-applied.
  • Manual Process – Cannot be easily automated.

Kentico Continuous Integration (CI)

Kentico continuous integration was designed to serialize the data objects from the database into XML files on the file system so you can then add them to a version control system such as git. Typically, this is used between team members to synchronize their databases during development. An advanced use for Kentico CI is syncing content from one environment to another. This can be done by serializing the content on production, copying the files back to development, and running the ContinuousIntegration.exe utility. This process can also be scripted by utilizing the Kentico API.


  • No network needed – Documents are exported into XML files that can be copied. Server-to-server network connectivity is not needed.
  • Scriptable – Kentico CI has an exposed API, so you can create scripts to automate the synchronization process.
  • Selective – Because all the documents are in XML files, you can pick and choose which files you want to move back to the development environment. This can be done with the repository.config, manually picking and choosing files, or if scripting through business logic.


  • Complex – Since this involves multiple steps and utilizes tools in ways not originally intended, it can be difficult to get configured properly.
  • Not efficient with large content trees, kinda – If using the Serialize All Objects function within the Admin interface, large sites may timeout and become unresponsive. If this is the case, using the Kentico CI API is required.

In Conclusion

There are several ways you can use to keep your environments in sync. Each has its strengths and weaknesses, and it all depends on which approach will work best for you. For me, using Kentico CI is something I’ve only recently considered using for environment syncs, and it looks very promising.

About the Author

Tim Stauffer

Completely self-taught and a Jack of all trades, Tim’s the man when it comes to making things happen with websites and software. Given enough time, he can figure anything out. It makes him feel all warm and fuzzy inside when he makes something and others use it to make their lives better. We like his big heart. Tim enjoys “experimenting with food,” and is just a bit addicted to World War II movies.

Subscribe to Our Blog

Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.