Selenium Grid 4 session persistence limits during incremental migration

We are planning to migrate a small Selenium Grid deployment to Grid 4 incrementally, with the goal of avoiding interruptions to in-flight browser sessions. The documented architecture separates the Router, Distributor, Session Map, and Node processes, and nodes support graceful draining so running sessions can finish before a node exits. However, the Session Map defaults to an in-memory store, while a JDBC-backed store is available for persistence across restarts.

The unresolved behavior is how much failover state the default configuration actually preserves. If the Distributor or Session Map restarts while using the default in-memory map, in-flight session records may be lost, leaving the Router unable to route to sessions it no longer tracks. The documentation describes graceful drain and external session storage, but does not guarantee automatic failover of the Router itself. Because Grid 4 replaces the Grid 3 hub/node model, existing configurations and flags do not carry over unchanged.

Does a Grid 4 migration require an external session store and multiple Router instances to avoid session loss, or can the default in-memory map tolerate component restarts in a small setup? What is the documented failover boundary between node draining and Session Map persistence? Are there version-specific differences across 4.x releases that change which session map backends are supported?