This content is archived. See latest version here

Last updated: Mar 25 2013


Mirroring in EPiServer CMS makes it possible to maintain content in one location and pushing the content to other sites. Mirroring rules and associated batch jobs are conveniently managed from the EPiServer CMS administration interface. With content mirroring you can define a selection of pages and allow them to be published in another EPiServer CMS system. Mirroring keeps track of pages that have been moved and deleted, maintaining the exact page structure. This functionality is used for instance in a staging environment.

The Mirroring Service can be configured as fully connected mesh topology. In the traditional way, the mirroring service is configured as one-way-mirroring, which means that the mirroring service sends the content to another service. In EPiServer CMS the mirroring service is able to detect if the content (files and pages) has been mirrored before. In other words, if you run a mirroring job many times without changing of the content, then the content on the target site will be ignored and unchanged.

By creating a customized mirroring provider you can also deliver content mirroring in other structured formats such as static HTML and XML. The mirroring feature can also be used to enhance content creation procedures, ensuring scalability and shorten response times for enterprise editors that are widely spread geographically.

Other Available Options

Mirroring is used in many different ways related to availability and performance of databases and websites. EPiServer CMS supports several SQL Server high-availability options. These include fail-over clustering, database mirroring, log shipping and replication. For instance, database mirroring is used to retrieve a “hot” standby database that operates in read-only mode, and all transactions are copied to the mirror, either synchronously or asynchronously. Instant fail-over can be configured using a “witness” server. Log shipping is similar to database mirroring, but multiple destination servers can be supported, and it can be configured to delay writing changes to the destination.

Do you have feedback on this documentation? Send an email to For development-related questions and discussions, refer to our Forums on