Should I migrate from Notebook Server to Jupyter Server?

Updated

Yes, if you maintain a Jupyter web application or deployment built on the classic Notebook Server, the documentation states that Jupyter Server is a replacement for the Tornado Web Server in Jupyter Notebook, and that Jupyter web applications should move to using Jupyter Server. The migration guidance lives in the "Migrating from Notebook Server" page, with a companion page on "Running Jupyter Notebook on Jupyter Server" for those who still need the classic Notebook interface on top of the new backend.

What Jupyter Server actually is

Jupyter Server is the backend that provides the core services, APIs, and REST endpoints for Jupyter web applications. It is not a user-facing notebook interface — it is the layer that web applications sit on.

The documentation frames it explicitly as a replacement for the Tornado Web Server that was previously embedded in Jupyter Notebook. That framing is the whole reason migration is recommended: the older arrangement tied the server layer to the Notebook application, while Jupyter Server separates it so multiple front ends can share one backend.

Who should migrate

The documentation splits its audience into four personas, and the migration question lands differently for each:

Persona What they do Migration relevance
Users People using Jupyter web applications Indirect — you benefit when your tool's maintainers migrate
Operators People deploying or serving Jupyter web applications to others Direct — deployment and configuration change
Developers People writing Jupyter Server extensions and web applications Direct — this is the primary migration audience
Contributors People contributing directly to the Jupyter Server library Direct — you work in the new codebase

If you are an operator or developer running anything on the classic Notebook Server, the migration pages are written for you. If you are purely an end user clicking around a hosted notebook, the change is mostly invisible.

What runs on Jupyter Server

Migration is worth understanding because a large part of the ecosystem already builds on this backend. The documentation lists these as examples of Jupyter Server extensions:

  • JupyterLab — the computational environment
  • Jupyter Resource Usage — a Notebook extension for monitoring your own resource usage
  • Jupyter Scheduler — runs Jupyter notebooks as jobs
  • jupyter-collaboration — a Jupyter Server extension providing support for Y documents
  • NbClassic — Jupyter Notebook packaged as a Jupyter Server extension
  • Cylc UI Server — serves the cylc-ui web application for monitoring and controlling Cylc workflows

NbClassic is the notable one for migration planning: it shows that the classic Notebook experience can be delivered as an extension on top of Jupyter Server rather than as its own server.

Where to find the migration guidance

The documentation's table of contents places migration material under the Operators section, alongside related operational topics:

  • Migrating from Notebook Server — the main migration entry point
  • Running Jupyter Notebook on Jupyter Server — for keeping the classic Notebook interface
  • Managing multiple extensions and Configuring Extensions — relevant once you are on the new backend
  • Running a public Jupyter Server and Security in the Jupyter Server — deployment concerns that change with the new architecture

For developers, the corresponding material sits in the Developers section: Architecture Diagrams, Depending on Jupyter Server, The REST API, Server Extensions, File save hooks, Contents API, and WebSocket kernel wire protocols.

How to approach the migration

  1. Confirm what you are running. If your deployment is built on the Tornado Web Server inside Jupyter Notebook, you are in the migration scope described by the documentation.
  2. Read the "Migrating from Notebook Server" page first. It is the documentation's designated help entry for this transition.
  3. Decide whether you need the classic Notebook UI. If yes, the "Running Jupyter Notebook on Jupyter Server" page covers that path — NbClassic is the extension that provides it.
  4. Check your extensions. If you depend on extensions written for the old server, review the Server Extensions material and the extension management pages before switching.
  5. Review deployment and security. Operators should read the public server and security pages, since serving a Jupyter Server to others involves configuration that differs from the old setup.

Common sticking points

  • Assuming Jupyter Server is a notebook interface. It is a backend. If you expect a UI after migrating, you will need a front end such as JupyterLab or NbClassic on top of it.
  • Skipping the extension audit. Extensions are the main compatibility surface. The documentation's extension pages exist precisely because extensions are how applications plug into this backend.
  • Overlooking the operator documentation. Migration is filed under Operators in the table of contents, which signals that deployment and configuration work — not just code changes — is expected.

If you find gaps in the documentation during migration, the project asks you to open an issue or a pull request on the Jupyter Server GitHub repository.