Session preservation limits for rolling upgrades with Vaadin stateful UI

Goal and constraints

The goal is to migrate a small Vaadin application with no perceived downtime. Vaadin keeps UI component tree state in the HTTP session on the server, so a redeploy normally invalidates sessions and forces reload or state loss.

Rolling upgrades are commonly discussed with sticky session affinity and node draining, while full session replication is limited because UI instances are not serializable by default and require careful application design. Push connections via WebSocket may reconnect to a different node during drain, and client bootstrap behavior on session loss depends on configuration.

An unresolved decision is whether the migration includes a Vaadin version change. A framework upgrade combined with redeployment can invalidate serialized session state and client-side resources even if sessions are preserved by the deployment strategy.

Does the plan rely on sticky sessions with draining, or is cross-node session continuity required? If a Vaadin version change is part of the migration, is session state expected to remain compatible? What client behavior is acceptable for active push connections when a node is drained?