A new warehouse application deploys successfully. Minutes later, some dispatch documents turn out to be wrong. The team sends traffic back to the old servers, but those servers no longer understand the new shipment status. The routing rollback worked. The warehouse did not recover.
Blue-Green Deployment lets a team prepare a release separately from the serving environment and change which environment receives traffic. Returning safely depends on more than routing. Work through those conditions before deployment, while the previous version can still perform the required business operations.
Separate preparation from cutover
Let Blue serve users while Green receives the new application. These are distinguishable deployments and configurations, not permanent roles. On a later release, their roles may reverse.
Green can be started, checked and warmed without replacing Blue. Once it is ready, routing moves to Green. This separation is the core of the original description. The colours do not prescribe how many databases to run or how the routing change works.
The candidate environment needs comparable permissions, certificates, connections, limits and partner access wherever those affect behaviour. Test operations still need protection from real consequences. Testing document generation in Green must not dispatch a real consignment or reserve stock a second time.
Capacity deserves a separate check. An environment that handled a few test requests has not demonstrated readiness for the entire workload. Warming its caches through a shared database may also affect Blue before any customers move.
Draw the environment boundary through the data design
A common arrangement has both application versions use the same data store. That avoids copying current data during every cutover. It also requires both versions to understand the structure and meaning of records they may encounter while coexisting.
Adding an optional field may be compatible; deleting a field required by the older application is not. A new status value can break an old reader without changing the schema at all. A migration completing successfully is therefore insufficient evidence. Test old application operations against records written by the new version.
Changes are often separated into a compatible expansion, application transition and later removal of obsolete structures. The AWS guidance on blue-green data changes discusses this approach. It does not make the migration itself free from locking or operational risk.
Separate databases create a different problem. Green needs current data before cutover, while returning to Blue requires a plan for records created afterwards. Routing back to an older copy can discard acknowledged changes. Separate stores require a synchronisation and recovery design, not merely two connection strings.
Browser requests are only part of the workload
Some connections and in-flight operations can remain in Blue after routing changes. The old environment cannot automatically be terminated at that instant. Allow agreed work to finish or preserve it for safe continuation. Routing configuration itself also takes time to propagate, a concern explicitly addressed by Argo Rollouts' blue-green implementation.
Background work is particularly important for the warehouse. If both environments run the daily dispatch-document job, duplicates can appear regardless of where users are routed. Scheduled tasks and queue consumers need an explicit handover, safe repeated processing and compatible message formats.
Partners may also call back to an address recorded before the release. Changing the main route does not reconfigure another company's integration. Employee sessions, temporary files and unfinished operations all need an understood transition.
Rollback has conditions and an expiry point
Keeping Blue powered on is not enough. Data, credentials and external processes keep changing while Green serves traffic. Eventually the older application may cease to be safe even though its servers remain healthy.
Define rollback conditions before release: which changes are permitted, who decides to return and which checks follow the routing change. For a defective dispatch-document format, the team must identify documents already created as well as restore the application. Printing again must not silently trigger another shipment.
Application rollback, data repair and compensation for external effects are separate procedures. Sometimes a forward fix with a temporarily restricted feature is safer than putting old code in front of unfamiliar records. A generic increase in error rate cannot decide that trade-off alone.
When can the spare environment be retired?
After cutover, watch more than HTTP failures. The warehouse needs completed dispatches, readable documents, processed carrier confirmations and no duplicate work. Process readiness may stay green while those outcomes are wrong.
Choose the observation period around when the changed behaviour actually runs. If the release affects an evening job, a few quiet minutes of daytime traffic provide little evidence. Keep a suitable recovery option or verify that job before the rollback window closes.
Costs include temporary spare capacity, configuration comparison and maintenance of coexisting versions. Not every resource must be duplicated, but shared dependencies remain shared failure points. A simpler rolling update with a well-tested recovery path may be sufficient. To limit initial customer exposure, a prepared second environment can also be combined with a canary rollout.
The release plan should state the last change after which returning to Blue is still verified, and the procedure beyond that point. Exercise cutover and return with a dispatch document already created and a job still unfinished. That distinguishes a genuinely usable previous version from spare servers that merely happen to be running.