Node.js 20 EOL: The 2026 Cloud Migration Playbook

Node.js 20 EOL is not hypothetical anymore—it lands on April 30, 2026. If you’re still running production on 20.x, you now have weeks, not quarters, to ship upgrades. The good news: moving to Node 22 LTS or Node 24 LTS is straightforward if you approach it as an engineering program rather than a scramble. This guide lays out exact cloud timelines, key breaking changes, and a concrete 30/60/90‑day plan that gets you safely to green.

What “EOL” really means for Node 20 in 2026

After April 30, 2026, the Node.js project stops shipping security fixes for 20.x. That’s the line. No more CVE patches, no more backports. You can keep running your apps, but you’ll carry risk and likely fail security reviews. Most vendors track that upstream date with their own deprecation schedules.

Two stable landing zones exist today: Node 22 LTS (security support through April 30, 2027) and Node 24 LTS (security support through April 30, 2028). If you need minimal change risk this quarter, target 22. If you’re already modernizing tooling, 24 gives you a longer runway.

Cloud runtime matrix: real dates, real constraints

Here’s the thing—platform dates quietly force your hand. Even if your code “works,” CI/CD and cloud runtimes eventually refuse creates or updates. Treat these as immovable milestones.

AWS Lambda

Lambda follows three phases tied to Node 20’s upstream EOL. On April 30, 2026, AWS stops security patches for the nodejs20.x runtime and it falls out of support. On June 1, 2026, you can’t create new Node 20 functions. On July 1, 2026, you can’t update existing Node 20 functions at all. Your functions will still invoke, but you’ll be stuck on an unpatched runtime and blocked from shipping fixes until you migrate.

The path forward is production‑ready: Node 22 is GA on Lambda, and Node 24 is available as well. If you’ve been delaying because of handler patterns, note that modern async/await is the first‑class path; callback‑style handlers aren’t the focus anymore. Plan integration tests around cold starts, ephemeral storage, and any native modules that bind to OpenSSL.

Azure Functions

Azure tracks the same upstream cadence for Node 20 (support ends April 30, 2026) and offers Node 22 GA with Node 24 in preview. If your Functions apps rely on extensions or durable orchestrations, validate compatibility early—especially if you’re using older storage SDKs that pinned to Node 16/18 constraints. Azure SDKs aim to track LTS windows; expect older Node support to drop sooner than your code assumes.

Vercel

On Vercel, the default runtime for new projects is the latest LTS (presently Node 24), with Node 22 and Node 20 still selectable during this transition period. If you deploy hybrid apps (Edge + Serverless Functions), make sure your "engines" field, NODE_VERSION build config, and any node: built‑ins you use line up across both execution environments. For monorepos, set the version at the project level and enforce it in CI to avoid drift.

Containers and Kubernetes

If you’re shipping containers, the migration is easier but not automatic. Pull official Node 22/24 images, refresh your base OS (AL2023, Debian Bookworm, or Ubuntu 22.04/24.04), and rebuild native modules. This is the moment to go distroless or slim—smaller surfaces reduce your patch load across 2026. Validate OpenSSL and CA bundles for outbound TLS. Expect small memory profile changes from stream defaults in Node 22.

Why upgrade now? A pragmatic risk and ROI lens

Security teams will flag Node 20 the moment it crosses April 30. If you’re in regulated industries or sell enterprise, you’ll feel that pressure in vendor reviews. On the cost side, every week you delay adds rework: the Lambda update block on July 1 means emergency migrations later, exactly when you don’t have time. Flip the view: a planned migration unlocks performance gains from Node 22/24 (faster streams, better AbortSignal, and built‑in WebSocket) and simplifies your dependency tree by removing legacy polyfills.

Node.js 20 EOL: the upgrade paths that actually work

Three sane routes exist:

• 20 → 22 LTS: lowest risk, smallest diff. Recommended for most backends and Lambda/Functions apps.
• 20 → 24 LTS: best long‑term runway. Do this if your tooling and libraries already test on 24.
• Dual‑track: ship 22 fast for production, keep a 24 branch running in CI so you’re prepped for a Q2 rollout.

Whichever path you pick, test both CommonJS and ESM flows, and compile native addons against the target runtime. If you maintain libraries, publish prebuilt binaries for 22 and 24 to avoid install pain for consumers.

What changes moving from Node 20 to 22/24?

Let’s get practical with the differences you’ll feel in code and production. None of these are scary, but they’re easy to miss if you only run smoke tests.

ESM and CommonJS interop gets easier (but mind the flag)

Node 22 introduces support for requiring synchronous ESM graphs via --experimental-require-module. That makes it easier to bridge older CJS code with packages that ship ESM‑only. For libraries, consider adding a "module-sync" export condition and test both import paths. For apps, resist shipping that flag to production unless your integration tests cover module loading edge cases at startup.

Streams are faster by default

Node 22 bumps the default high water mark for streams (e.g., from 16 KiB to 64 KiB in many cases), trading a bit more memory for throughput. If you’re memory‑constrained on small Lambda sizes or container limits, load test with production traffic to catch regressions early.

WebSocket goes native

Node 22 includes a browser‑compatible WebSocket client out of the box. If your server‑to‑server real‑time code pulled in ws purely for the client, you can simplify. Don’t delete the dependency blindly—feature‑parity isn’t total for every niche—but many apps can drop a package and a transitive tree of subdependencies.

Fetch and AbortSignal are faster

Internal improvements to AbortSignal creation speed up network code, which you’ll notice in request‑heavy services and test suites that hammer the fetch API. It’s a “free win” after you upgrade.

Tooling quality‑of‑life

Watch mode is stable, glob utilities are available in core, and there’s an experimental --run flag to execute scripts without invoking npm. These polish points don’t block migration, but they make developer experience better once you land on 22/24.

Migration readiness checklist (use this verbatim)

Here’s a short list we use with clients to keep upgrades boring—in the best way.

• Inventory: Find every build, function, and container using Node 20. Include background workers, cron jobs, and ephemeral scripts.
• Runtime target: Choose 22 for speed to green, or 24 for longer support. Document the rationale in your RFC.
• Engines and CI: Set "engines": { "node": "22.x" } (or 24.x). Update CI images and test matrix to run 22 and 24 side by side for two weeks.
• Dependencies: Refresh the top 20 dependencies by impact. Look for native modules (e.g., bcrypt, database drivers). Plan rebuilds and verify prebuild availability.
• ESM strategy: Decide if you’ll enable --experimental-require-module. If yes, write a one‑pager on how you detect and test it.
• Secrets and TLS: Confirm CA bundles, mTLS settings, and OpenSSL usage. Rotate any pinned ciphers that break under newer OpenSSL defaults.
• Performance baseline: Capture p95 latency, memory, and cold start times today. You can’t validate improvements without a baseline.
• Rollout plan: Blue/green or canary with fast rollback. Lock a freeze date before the Lambda update block (July 1, 2026) if you’re on AWS.

30/60/90‑day plan you can paste into your tracker

Day 0–30: Prove it in CI, ship to a canary

Pick Node 22 as the default target. Update CI images and run the full suite nightly on 22 and 24. Tackle the first failures: type definitions that assume old lib.dom versions, test runner snapshots with subtle differences, and native addon rebuilds. In staging, deploy a canary that handles 5–10% of traffic. Watch memory and streaming endpoints.

Day 31–60: Production rollout and parity work

Move to 50–100% traffic on Node 22. Remove workarounds you only needed for Node 20 (polyfills, custom WebSocket shims). Measure p95/p99 deltas versus your baseline. For serverless, right‑size memory after the streams change—many services can reduce memory once you’ve tuned concurrency.

Day 61–90: Hardening and optional lift to 24

Close the loop: dependency audit, SBOM refresh, and threat model updates. If you want the longer runway, lift a stable service from 22 to 24 in a dark‑launch and prove no regressions. Document everything so new services start life on 24.

People also ask

Do I need to jump straight to Node 24?

No. Node 22 buys you security coverage through April 30, 2027 and is the fastest stable landing. If you can afford an extra sprint, validating on 24 now saves an upgrade later.

Will my Lambda functions stop running after April 30, 2026?

They’ll keep running, but you’ll be on an unsupported runtime. More importantly, you won’t be able to create new Node 20 functions after June 1 or update existing ones after July 1, 2026. Don’t wait for those blockers.

What about node-gyp and native modules?

Plan a full rebuild on the new runtime. Prefer packages that publish prebuilt binaries for 22/24. For internal addons, ensure your CI images use the same compiler toolchain as production and test on your final base image.

Is ESM finally safe at scale?

Yes—with guardrails. Node 22’s ESM/CJS interop is better, and most major frameworks ship ESM builds. Standardize import conventions in your repo, add a lintrule for file extensions, and keep the experimental flags contained until you’ve proven them in staging.

Pitfalls teams hit—and how to dodge them

Here are the avoidable traps we see repeatedly:

• Forgetting background jobs. Those “tiny scripts” often hold production credentials. Inventory them.
• Rolling back to Node 20 after a failed cutover. On Lambda post‑July 1, 2026, that rollback may be impossible.
• Upgrading only the runtime. Your base OS, OpenSSL, libuv, and CA bundles change your app’s behavior too.
• Skipping load tests. The stream defaults and WebSocket stack can change memory and connection churn under pressure.

A quick cost model to get buy‑in

Take one service handling 1,000 rps. Assume a conservative 3% latency improvement after upgrading (from AbortSignal, streams, and dependency cleanup). That can translate into shedding a replica at peak or fitting into a smaller Lambda memory tier—both save real money. Now add the security posture: avoiding an urgent upgrade in late June when Lambda blocks Node 20 updates saves at least one unscheduled incident sprint. That’s the ROI story your PM needs.

Make it stick: process changes after you migrate

Future‑proofing is cheap compared to emergency work. Add the following to your engineering ladder:

• Set a calendar reminder for the next Node LTS EOL dates (22 in April 2027; 24 in April 2028).
• Keep a dual‑version CI job permanently. Catch breakage early.
• Publish a “runtime README” per service with Node version, base image, and flags. Treat it like code.
• Standardize a minimal “hello world” load test that every service must pass on new runtimes.

What to do next (today)

• Decide your target: 22 or 24. Write it down.
• Flip your CI to test on the target runtime this week.
• Schedule a canary release within 30 days.
• Mark June 1 and July 1, 2026 as hard Lambda dates on your calendar.
• Book an internal review of WebSocket, streaming, and native module hotspots.

If you want a deeper, step‑by‑step walkthrough, our 90‑day plan covers the sequence, tooling, and checklists in detail. Read Node.js 20 EOL: Your 90‑Day Migration Playbook, then adapt it to your stack.

We’ve shipped these upgrades—let’s ship yours

We help teams migrate runtimes without drama. See how we build and modernize production apps in our portfolio. If your team needs a partner to plan, test, and roll out a Node 22/24 migration across Lambda, Functions, and containers, explore our engineering services or contact us to schedule a working session. Prefer to DIY? Keep an eye on the latest shop notes on our blog.