We are currently having Sitecore 8.2 update 6 runs on AWS. We are planning to implement Blue/Green deployment for zero downtime and disaster recovery. The plan is to have 2 set environments as Blue will have 1CM, 2 CDs (active) and Green will have 1CM, 2 CDs (standby). They both will share the same integrated environments including SQL, MONGODB and Solr so there is no need to update connection string. We will utilize Amazon Elastic Load Balance to route the traffic between Blue/Green environments.

My question is has anyone has implemented this type of set up before? Could you please share any drawbacks or concerns with this approach if any? The other aspect I am interested to know is there any automate way to tell load balance to route traffic to avoid manual work?

  • A concern: what if a change is deployed to one environment that changes items in the shared master db which when published causes the other environment to break? Apr 17, 2018 at 5:44
  • About question 1: I think it should work just fine with Octopus Deploy with some of the steps provided. Question 2: if you use Octopus Deploy there are steps which could help you with this. Adding and removing environments from ELB. Apr 24, 2018 at 20:57

1 Answer 1


Shared SQL?

From what I am hearing you say, you are keeping the SQL, Mongo and SOLR. In that case you can ONLY do blue/green with code deployments. No items. If you deploy template changes to blue, it will update the master/web/core for the shared green environment.

This is if I am hearing you right.

I did it with a separate SQL

I did a blue/green for a large retailer not too long ago. We had it completely separate web and sql. It was a 7.2 with no analytics so reporting/Mongo did not matter. In that case, we ran a PowerShell script that would backup the databases, restore them in the other environment. Then used RedGate to Sync the SQL for any last changes that happened during the backup restore (I would use RAZL now). Deploy all our code and items. Then test the offline environment. This would require a content freeze. If it failed, we would identify the failure and throw it away.

Having separate SQL is the only way I know of doing blue/green in Sitecore without risking the master DB because of a deployment failure that didn't pass the tests. Rolling back all your changes, all though possible, is a big risk.

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.