Its a methodology deployed when making a change to an existing piece of software or when migrating a software from one environment to another e.g., from base metal to cloud or from one cloud environment to another.
The Blue-green deployment technique reduces downtime and risk by running two identical production environments called Blue and Green.
At any one time, only one of the environments is live, with the live environment serving all production traffic. For example, if Blue is live while Green is idle.
As a new version of the software is prepared, deployment and testing of the new version takes place in the Green environment. Once the new version of the software is deployed and fully tested in the Green environment, the router is switched to Green so that all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.
The only wrinkle is if the App uses a relational database a Blue-Green deployment can lad to discrepencies between the Bue and Green databases during the updating process. A static intermediate maintenance database is sometimes used to address this issue.
This technique can eliminate downtime and keep production live during the deployment and testing. Blue-Green deployment methodology also reduces risk: e.g., if something goes wrong with the new version on Green, production can immediately be switched back to the last good version by switching the router back to Blue.
Although this is pretty standard stuff for IT people the explanation could be very useful for the Business side to better understand what is going on with their change requests and for management who are investing in the could migration and are getting user feedback.