A Dublin software company changes one line in its container file, rebuilds successfully and announces that its Node.js upgrade is complete. The customer portal opens normally. At midnight, a background job tries to generate an invoice attachment and fails inside a native dependency that the daytime smoke test never touched.
Runtime maintenance is rarely glamorous enough to win a product roadmap discussion. Yet the work determines whether a business can continue receiving upstream fixes and shipping changes without a growing compatibility gap. The deliverable is a working application on a supported stack, with evidence that the important jobs still run.
The lifecycle trigger is already here
As checked on 15 October 2026, the Node.js release schedule lists Node.js 20 as end of life, with its scheduled support end on 30 April 2026. Select a supported target by checking the current lifecycle and the requirements of your framework and dependencies. Avoid choosing a release only because its major version is the largest number. Node.js release schedule
The Node.js project explains that an end-of-life line no longer receives normal upstream maintenance and can create ecosystem compatibility problems. A paid extended-support arrangement, where available, needs its own evaluation; it is not the same thing as continuing upstream support. Node.js end-of-life guidance
For a buyer, this is a reason to commission a bounded upgrade assessment now. It is not a reason to approve a rushed change without understanding what actually runs in production.
Inventory the runtime you have, not the one in the README
The repository may specify one Node version while a build runner, scheduled task and production container use three others. Record the versions from the running workloads and deployment configuration. Include administrative scripts that operate on production data and any separately hosted workers.
List the operating-system base image, package manager, architecture and native dependencies. Image processing, database drivers, PDF tools and cryptographic integrations can have platform-specific behaviour. A successful laptop install does not prove that the production image can build or execute the same dependency.
Node's addon documentation distinguishes native integration approaches and recommends Node-API for ABI stability across versions. That is helpful context, but a dependency's packaging, external libraries and supported platforms still need checking. Node.js C++ addon documentation
Ask what the business would notice first
Build the acceptance list with operations and customer support. Which tasks cause immediate commercial disruption if they fail? Sign-in, checkout, exports, scheduled billing and document generation usually deserve attention before an obscure visual component.
Choose representative data for those journeys. Include a large export, an unusual character in a customer name, a slow external response and a job retried after interruption. Where production data is sensitive, construct or safely prepare test material that preserves the relevant shape without exposing unnecessary information.
Give each journey an owner who can recognise a correct result. A generated PDF that opens is not necessarily a correct invoice. The totals, currency, pagination and attachment identity may all matter to the customer receiving it.
Separate required compatibility work from optional renovation
A runtime upgrade can become an uncontrolled rewrite if every outdated library becomes a reason to redesign the application. Classify changes as required for the target runtime, justified security or support work, and optional improvement. Price and approve those groups explicitly.
Sometimes the framework itself must move because its supported runtime range is incompatible with the target. That is a real dependency, not scope creep. Other changes can wait. The assessment should explain which constraints force a sequence and which choices are discretionary.
Keep a reproducible dependency lock and a record of the actual image used for acceptance. If a later rebuild resolves different dependencies, the team may no longer be running what was reviewed. This is especially important when the original application has weak release discipline.
Treat background work as a first-class product surface
Scheduled jobs are easy to miss because they do not appear in a browser checklist. Inventory their timing, input source, output destination and external side effects. Decide how to exercise them safely in a preview environment without sending real customer mail or charging a real account.
Include jobs already queued before the upgrade. A new worker may need to read a payload written by the old application. Likewise, rolling a worker back may fail if newer jobs use a format it does not understand. Compatibility belongs at the queue boundary as well as the HTTP boundary.
For a deeper handover checklist, read custom software maintenance agreements. Our testing strategy guide explains how to select checks that protect behaviour rather than merely mirror implementation.
Rehearse recovery before calling the release ready
Keep the previous deployment available while the candidate is verified, but document what can and cannot be reversed. A runtime-only change may be straightforward to roll back. A combined database migration or dependency change with new external effects can make the path more complicated.
Define the promotion criteria and the stop criteria. Compare error rates, job completion, response time and resource usage under representative load. Investigate a meaningful regression before deciding that it is an acceptable cost of modernisation.
The recovery rehearsal should include restoring the previous service, checking queued work and verifying that users can complete an important journey. A written instruction that nobody has executed is weaker evidence than a successful controlled rehearsal.
Commission an upgrade with a usable finish line
A reviewable proposal should include the current-state inventory, chosen target and rationale, compatibility changes, test evidence, deployment plan and maintenance handover. Ask for a list of unresolved risks rather than an unqualified promise that the new version fixes everything.
If the application is business-critical, make support during the first relevant operating cycle part of the scope. For a nightly billing system, that means watching the billing cycle, not only the first five minutes after deployment.
TuniCyberLabs can assess the application through our custom software development and modernisation service. Request a Node.js upgrade assessment with the repository, deployment model and the jobs your business cannot miss.