Identify the version currently used by the web process, build process and command line. Check the application package metadata and the hosting plan’s available runtimes.

1. Review the official Node.js release status and choose an Active LTS or Maintenance LTS branch compatible with the project. Do not select a branch solely from an old rule about odd and even version numbers.

2. Check framework, database driver and native dependency support for the intended runtime. Record the version requirement in the repository or build configuration.

3. Reinstall dependencies from the project lock file in a clean environment using the target runtime. Build the application and run its meaningful compatibility checks.

4. Test the same startup command and important workflows in staging. Include uploads, outbound API calls and scheduled or background processes.

5. Change the production runtime through the supported panel or deployment control and restart the application. Keep the previous tested release available.

Verify the running service reports the intended runtime through private diagnostics and that web and worker processes agree. Check error and restart rates after the change.

A native module error after switching Node often requires a compatible rebuild or dependency release. Returning only the runtime without restoring compatible dependencies may not fully recover the app.

• Troubleshooting a Node native dependency build
• Deploying repeatable Node dependencies with npm ci
• Deploying a Node.js application on an eligible Nabtech plan
• Investigating a Node app that works locally but fails on hosting

• Node.js release schedule
• Node.js end of life