Jupyter Server restart terminates active kernels: diagnosing kernel-state continuity during migration

A small Jupyter deployment requires migration to a new host while keeping user-visible downtime minimal. The goal is to cut over routes and sessions with as little interruption as possible, specifically for active notebook kernels.

Core Jupyter Server behavior dictates that a server process restart terminates all child kernels, since kernels are not persisted in memory across restarts. The documented jupyter_server REST API (/api/kernels, /api/contents) can inventory active sessions and autosaved notebook content, but it does not provide a mechanism to checkpoint or migrate in-memory kernel state. JupyterHub rolling restarts with container-based spawners can start new pods before old ones stop, reducing perceived downtime for new logins, yet kernel variables and execution state are still lost. This creates an unresolved decision: whether to accept a brief maintenance window with expected kernel-state reset, or to invest in an external orchestration layer that decouples kernels from the server lifecycle--core Jupyter offers no built-in live kernel migration.

What is the minimal acceptable duration of kernel-state interruption during a proxy-cutover migration? Can the /api/kernels and /api/contents endpoints reliably prompt users to save state before a planned restart? Is it feasible to externalize kernel state without a custom spawner, given core Jupyter's current API surface?