We have a number of different sites (probably in 100+) and we have requirement of sharing content along with meta items across different Sitecore instances. We need this sharing feature as there is a number of global content that remains same and needs to be consistent.

We don't want to use a simple Sitecore package or any other serialization method like TDS etc as this content is updated by business users. It will be difficult for them to create or install the packages. Also, there are too many sites (probably in 100+) to be updated regularly. So anytime any new component along with content is available, then it should be shared (component + content) across multiple Sitecore instances. We create this global component in our Corporate Sitecore instance.

We have different Sitecore instances that hosts multiple sites. So here is the requirements.

1) All instances will host a Shared Components folder in their instance.

a. Example: Our Corporate Website instance /sitecore/content/Corp/shared-content/Sliders/Corp

and so on…

b. Example: for Sports Site instance

/sitecore/content/sports/shared-content/Sliders/Corp and so on….

Essentially, all instances will have the share-content folder in the path shown above;

All these folders across all instances are required to be synchronized based on a schedule (every 24 hours) so that content is available across all instances with all necessary meta including template. If corporate were to create a new component, they would create it on the corporate instance in the

…/ shared-content/.

2) We will create a page in the instance to share available component:

Example url: Corp/share

3) Content that is created on other Sitecore instances should be synchronized in the corporate Sitecore Instance so that the share page shows the listing of all components (titles)


Corp Sitecore Instance – Component 1, 2, 3

Sports Sitecore Instance – Component 5, 6, 7

The global shared components folder across all instances should have all the required files.

So we need the approach to share (automatically at regular interval) the content (along with assets), files (rendering/layout/sublayouts), templates, assemblies (DLL) across different Sitecore instances so that these global components can be used by marketers without manual intervention of creating/deploying the packages.

We are thinking and open to use following tools for it.

  • Sitecore Job that listens and installs packages as well as uses a manifest to gather assemblies install automatically.
  • PowerShell scripting
  • Continuous Integration/Deployment

I hope this will help in more clarification.


2 Answers 2


Based on the wording of using "Sitecore instance" I think you have decentralized your authoring? One architectural approach would be to use a centralized authoring pool that manages all the content as multiple sites and then have your separate CD's with separate publishing targets so that you can maintain your end-user performance.

In this way, you could easily create shared content at a 'global' level across the entire system and allow each site to make use of it. This would be the typical approach.

Alternatively, you could have a regular task that serializes content from a specific path on one instance and deserializes it to your other authoring instances. You'd have to select one instance that is the 'master' though so you can make sure you are always going in the right direction. However, if you start doing this you need to start questioning why you have multiple authoring instances.

  • Thanks Jay for providing some information. We basically want to share other items also like template, file etc. to run the components across different instances. Commented Jun 24, 2017 at 14:44
  • @RohitChopra Are the instances completely seperate (i,e. different core/master/web databases?)
    – Chris Auer
    Commented Sep 22, 2017 at 23:41
  • @ChrisAuer We have some sites on same instance and some sites on different instances. Commented Sep 28, 2017 at 13:14

I guess it is more "Deployment" issue than content management. In this case I would go into Teamcity + Octopus + Powershell approach. If Octopus Deploy will be too expensive then you could try to use any other similar software to do the job. Because you have got so many environments you probably should also remember about maintenance of all connections - it should be easy and secured well.

With Octopus Deploy it could work in following way:

  • TeamCity automatically (Powershell can be used as well) will create package with all changes
  • TeamCity has Octopus connector so after package creation would push changes as a package into Octopus internal nuget server
  • then Octopus when will notice that new package was uploaded will start deployment into Tentacles and all Powershell scripts on target servers (if some will be required)

As the final setup we would have centralized and easy to maintain deployment environment.

  • We are using the scripts/tools for deployment, but like I have mentioned that we need this functionality for business users and we need an easy way to share content/component. Commented Sep 28, 2017 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.