Rolling Update vs Blue‑Green Deployment: Preserving In‑Proc Session State During Zero‑Downtime Migration

Goal

Migrate a small ASP.NET Core application to a new version without any service interruption while keeping user session data that is stored in‑memory.

Constraint

The application relies on in‑proc session state, which is lost whenever the worker process recycles. Any migration strategy must therefore avoid a process recycle or externalize session state.

Approach 1 – Rolling Update with Overlapped Recycle

Deploy the new binaries to the same IIS site, enabling IIS’s overlapped recycle so that the old worker process continues to serve requests until the new one is ready. This keeps the same session store but can trigger duplicate initialization of singletons or hosted services in ASP.NET Core.

Approach 2 – Blue‑Green Deployment

Publish the new version to a separate IIS site or App Service slot, run health checks, then switch traffic via a load balancer or URL rewrite. The old site remains untouched, preserving its in‑proc session data while the new site starts fresh.

Unresolved Decision

Which approach best balances zero‑downtime guarantees with session continuity, given the documented limitations of overlapped recycle for ASP.NET Core?

Specific Questions

1. Does IIS overlapped recycle reliably preserve in‑proc session state during a rolling update of an ASP.NET Core application?
2. Will a blue‑green deployment guarantee session continuity without externalizing session state, or are there hidden pitfalls?
3. What are the potential risks of duplicate singleton initialization when using overlapped recycle in ASP.NET Core?