Blazor Server or WebAssembly for a Shared-Login, Zero-Downtime Migration

Assume a small ASP.NET Core application on .NET 8 LTS or a supported later release, with legacy MVC pages and cookie authentication, must move selected features to Blazor while both surfaces remain reachable during a no-restart rollout. The unresolved choice is whether the migrated UI should run on the server through SignalR or in the browser as WebAssembly.

Blazor Server can participate in the existing ASP.NET Core authentication and session context, but each active circuit retains server-side state and depends on a persistent connection. Blazor WebAssembly can be served alongside the legacy app without holding those circuits, yet browser-side components cannot directly read ASP.NET Core session state; shared login depends on API design, cookie attributes, and origin policy. Prerendering may affect which state is available during the initial request.

For a same-origin rollout, which approach preserves the required login and session semantics with the least operational complexity? What should be verified for cookie transmission, session continuity, and circuit reconnect behavior when the legacy and Blazor surfaces coexist?