NestJS 11 — when and how should I migrate?
Teams on NestJS 10 need to decide whether to move to NestJS 11 now, given removed deprecated APIs, updated CLI/build behavior, and downstream package compatibility drift.
Blockers
- requires_version: framework/nestjs-11 → runtime/nodejs-20
- requires_version: framework/nestjs-11 → package/express-5
- requires_version: framework/nestjs-11 → package/fastify-5
- requires_version: framework/nestjs-11 → package/nest-cli-11
- requires_version: framework/nestjs-11 → package/nestjs-config-4
- requires_version: framework/nestjs-11 → package/nestjs-cache-manager-3
- requires_version: framework/nestjs-11 → package/nestjs-cqrs-11
- breaking_change_in: package/express-5 → framework/nestjs-11
- breaking_change_in: package/fastify-5 → framework/nestjs-11
- breaking_change_in: package/nestjs-cache-manager-3 → framework/nestjs-11
- breaking_change_in: package/nest-cli-11 → framework/nestjs-11
Who this is for
- monorepo
- small-team
- enterprise
Candidates
Upgrade to NestJS 11 now with a coordinated ecosystem sweep
NestJS 11 was released on 2025-01-16, and as of 2026-04-01 the official migration guide says it requires Node.js v20 or higher because Node.js v16 and v18 are no longer supported. The v11 release also moved the default Express integration to Express v5 and updated `@nestjs/platform-fastify` to support Fastify v5. Official migration notes call out breaking areas around Express v5 route matching and query parsing, cache-manager moving to Keyv-backed store configuration, middleware order changes, and the Terminus health-indicator API shift. Official ecosystem release notes for v11 also point to aligned major releases such as `@nestjs/config` 4.0.0, `@nestjs/cache-manager` 3.0.0, `@nestjs/cqrs` 11.0.0, and Nest CLI 11.x.
When to choose
Use this when you can upgrade runtime and framework packages together, especially if you are already on Node.js 20+ or planning that move now. It is the better choice when you want to stop carrying deprecated CLI/build settings and can budget time for route, cache, and health-check migration work in one pass.
Tradeoffs
You get onto the current major line and current CLI behavior, but the upgrade is not just a version bump: Express v5 path syntax, query parsing behavior, cache store wiring, and some middleware semantics can change runtime behavior.
Cautions
As of 2026-04-01, `--webpack` and the `webpack` boolean in `nest-cli.json` are deprecated in favor of `--builder webpack` and `compilerOptions.builder`. For SWC builds, official docs say `typeCheck` is off by default, and monorepos still need webpack plus `swc-loader` rather than the plain SWC builder. If you use Terminus custom indicators, the new `HealthIndicatorService` API should be adopted before the next major removes the legacy classes.
Stay on NestJS 10 temporarily and defer until dependency drift is cleared
Deferring can be rational if your codebase still depends on NestJS 10-era assumptions that NestJS 11 changes directly. Official migration docs show concrete behavior changes in Express v5 wildcard routes and query parsing, Fastify middleware path matching, cache-manager external store configuration, and global middleware ordering. The v11 release also expects aligned ecosystem majors, so teams with pinned Nest packages or custom health indicators may need more than a framework-only bump. As of 2026-04-01, the decision to wait is mainly about reducing migration blast radius, not about a pricing difference, because NestJS itself does not publish paid framework licensing for the upgrade path.
When to choose
Use this when you are blocked on Node.js runtime upgrades, have a monorepo build pipeline tied to old Nest CLI flags, or rely on downstream Nest packages that you have not validated against their v11-compatible majors. It is the safer option when short-term delivery matters more than removing deprecated behavior immediately.
Tradeoffs
You avoid immediate migration churn, but you keep older builder conventions and postpone the work needed for Node.js 20+, Express v5 or Fastify v5 semantics, and newer package majors.
Cautions
This is a postponement strategy, not a long-term steady state. As of 2026-04-01, NestJS 11 has already shipped and the official docs position Node.js 20+ as the supported floor, so the longer you wait, the more likely you are to combine framework, runtime, and package-major changes later.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "NestJS 11 — when and how should I migrate?"