Blue green deployment: 8 checks before switching production traffic

A blue green deployment runs a current application version and a replacement version in separate environments, then moves production traffic to the replacement after validation. This can reduce the interruption involved in a release and preserve an application environment to return to if problems appear.

However, switching a router back does not automatically reverse database changes, payments, messages, or work already in progress. The business needs a plan for those effects as well as the application servers. Otherwise, an apparently simple rollback can create a second failure.

This guide explains eight checks for a blue green deployment strategy: environment scope, data compatibility, traffic routing, sessions, background jobs, health signals, recovery, and final verification. It focuses on the decisions that determine whether the release remains understandable under pressure.

How the deployment model works

Teams commonly call the current environment blue and the replacement green. They deploy and test the new version in green while blue continues serving users. After readiness checks, they change the routing so green receives production traffic.

Microsoft’s guidance on CI/CD for microservices describes blue-green deployment alongside other release approaches. The exact unit can vary: a whole application environment, a service, or another defined boundary. State that boundary before discussing the switch.

A canary rollout answers a related but different question by exposing a change to a limited population before expanding it. Some platforms combine environment separation with gradual routing. Describe the actual behavior rather than relying on a label to imply a particular traffic pattern.

1. Define what belongs to each environment

List the application services, configurations, network routes, caches, workers, and dependencies involved. Two sets of application servers do not create two independent systems if both still depend on a shared database or queue.

Decide which resources remain shared and which have separate instances. Shared resources can simplify data continuity but create compatibility requirements. Separate resources can improve isolation while introducing synchronization and recovery work.

Build environments from reviewed definitions where practical. Manual configuration can leave green with a different timeout, permission, or external endpoint from blue. A successful local smoke test may not expose that difference until real traffic arrives.

Our guide to a continuous delivery platform explains useful supporting capabilities. The platform should show what will change and preserve the inputs that produced each environment.

2. Make database changes compatible with the switch

Both application versions may run during a transition, and the old version may need to run again during recovery. Therefore, database compatibility often determines whether a fast application rollback is realistic.

Consider an expand-and-contract approach when appropriate. First add a compatible field or structure. Then deploy application changes that can work during the transition. Only remove the old structure after the team no longer needs the previous version and has checked dependent consumers.

A destructive schema change can prevent blue from reading data written by green. Similarly, a new status value may confuse the old application even when the schema itself remains valid. Test data meaning as well as column presence.

AWS guidance on data synchronization and schema changes explains why shared and separate stores need deliberate treatment. Keep application deployment and database migration responsibilities explicit rather than assuming one switch controls both.

Database product features have their own rules

Managed database blue/green features differ from a generic application release pattern. Read the exact product’s switchover and recovery behavior. Do not assume that the old database remains synchronized or can accept an immediate return after new writes begin elsewhere.

3. Verify the routing mechanism and its timing

Traffic may move through a load balancer, gateway, service route, or another supported mechanism. Identify where the decision happens and how quickly all relevant clients observe it. DNS-based changes, for example, can encounter cached answers and long-lived connections.

Check health probes and routing eligibility before the switch. A process can answer a basic health request while lacking a required dependency or configuration. Use readiness signals that reflect the service’s ability to perform its role.

Also test how the old environment drains existing requests. Terminating it immediately can interrupt work that started before the routing change. Long-running requests, downloads, and streaming connections may need a separate transition policy.

Record how an operator verifies the effective route. A control panel reporting a completed change is useful, but request-level evidence should confirm which version actually handles user work.

4. Preserve sessions and user workflows

A user may begin checkout on blue and submit the next step after traffic reaches green. If session state exists only in blue’s memory, that user can lose progress. If both versions interpret the session differently, the problem can be harder to detect.

Choose a supported session strategy and test mixed-version behavior. This may involve compatible shared state, stateless tokens with suitable validation, or an explicit transition rule. The right choice depends on the application and its security requirements.

Review cached content too. An older browser page may call a newer API, while a cached script may reference a changed endpoint. Keep compatibility windows and asset publication behavior in the release plan.

Use contract testing for important consumer assumptions. Include older clients that remain supported, especially mobile apps that customers cannot update at the exact moment of a server release.

5. Control workers, schedules, and messages

Routing user requests does not control background work. If both environments run the same schedule, they may send two reminders, process two imports, or create duplicate exports. Decide which environment owns each job before enabling green.

For queue consumers, check whether both versions can process the same message format. Define how outstanding messages, retry queues, and long-running jobs move through the transition. A worker that started under blue may finish after green becomes active.

Protect consequential actions from repeated delivery. A payment or invoice export should recognize an existing business operation where the workflow requires it. Our guide to idempotency keys covers that boundary.

Include external callbacks in the routing review. A provider may call a fixed URL long after the initial request. The new environment must interpret that callback and find the relevant operation state.

6. Define health signals and stop conditions

Choose the evidence that determines whether the rollout should continue. Request errors and response time matter, but business completion signals often reveal a more useful picture. A checkout page can load normally while every payment confirmation fails.

Compare the new environment with an appropriate baseline and inspect absolute service targets. A quiet period with few requests may provide too little evidence to establish that a release works under normal load.

Segment important signals where feasible. Overall success can hide a failure affecting one tenant, payment method, or older client version. Select segments from the business risks rather than creating an unmanageable dashboard.

Connect this evidence to observability engineering. Operators should identify the version serving a request and trace the relevant workflow. Preserve enough context to distinguish a release defect from a shared dependency outage.

7. Rehearse rollback and forward recovery

Write a recovery plan before the release. State who can pause the switch, which signals trigger action, and how the team verifies the result. Also identify the point after which returning to blue would create incompatible data or other unacceptable effects.

Application rollback can restore earlier code, but it cannot unsend a customer email or reverse every external transaction. Some incidents need forward recovery, such as a corrective release, reconciliation, or an approved business adjustment.

Amazon RDS switchover documentation illustrates product-specific guardrails and transition behavior. That mechanism has a defined scope. Treat post-switch recovery as a separate question rather than extending a pre-switch guarantee beyond its documented conditions.

Rehearse with safe test data and representative in-flight work. Ask a colleague to follow the runbook. If they cannot determine the current writer, active environment, or outstanding jobs, improve the evidence before relying on the plan.

8. Verify business records before retiring blue

After the switch, confirm that important workflows complete and their records agree. Check orders, payments, messages, and scheduled work according to the release scope. A healthy server fleet does not establish that every business action reached the right state.

Keep blue available only for a defined purpose and period. An indefinite idle environment adds cost and can become a security or configuration maintenance burden. However, deleting it immediately can remove a recovery option before the team has enough evidence.

Document the conditions for retirement. These can include completed observation, verified compatibility, reconciled uncertain work, and an approved recovery route for the active version.

Finally, remove obsolete credentials, routes, and scheduled jobs as appropriate. Update the environment record so future operators do not mistake an old resource for a supported production path.

A practical order-service exercise

Suppose an order service adds an optional delivery instruction. The database change adds a compatible field first. Blue ignores the field safely, while green reads and writes it. Both versions continue accepting the existing request format.

The team deploys green and verifies the actual permissions and dependencies. It tests a user who starts an order before the switch and completes it afterward. It also tests a queued confirmation and a delayed payment callback.

During the transition, only the designated scheduler creates reminder jobs. The team observes order completion and callback processing by application version. If a stop condition appears, it uses the rehearsed recovery route and reconciles uncertain actions.

After the observation period, the team retires blue under its documented criteria. A later release can remove obsolete compatibility code when supported consumers no longer need it.

When the pattern may be excessive

A small internal tool with an agreed maintenance window may not need two full environments for every change. Meanwhile, a stateful system with hard-to-reverse data transformations may need more planning than this pattern alone provides.

Compare the added infrastructure and operational work with the interruption and recovery risks. Blue green deployment is valuable when environment separation and controlled routing solve a real release problem. It should not become a promise of zero downtime or instant rollback without evidence.

Warm the replacement without triggering real side effects

The new environment may need caches, connections, or compiled resources ready before it receives normal traffic. A warm-up plan can reduce surprises, but its requests must not accidentally send customer messages or create production transactions.

Choose safe readiness checks and representative test records. Where a check touches a real external system, use the provider’s supported testing route or an explicitly controlled operation. A read-only label on a script does not establish that every downstream call is harmless.

Next, observe resource use as green starts. Two environments can temporarily compete for shared database connections or partner capacity. Include that overlap in the capacity review, especially if green’s startup triggers a large cache refresh. This checks the transition workload as well as the steady state after the switch.

Make the switch one part of a complete release

A dependable blue green deployment combines compatible data, controlled routing, explicit worker ownership, useful health signals, and rehearsed recovery. Oxen Softwares teams can start with one service and a representative transition exercise before expanding the pattern.