Name the forcing event and its date
Write down what prompted the question: a host retiring a runtime, a customer questionnaire, a scanner report or a new engineer's surprise. Record the version named, the date and who gave it. The event decides the deadline and which component must move first; the rest of the stack is a question for an inventory. A single warning is a symptom, not a scope.
- Ask the host for the date in writing, for the exact runtime you use.
- Note any requirement date from a customer or policy that differs from the vendor's.
Decide who accepts, who merges and who releases
Every paid job here ends in pull requests and evidence, not a deployment. Name the person who accepts each step, the person who merges and the person who can release to production and reverse it. If nobody can accept or release, resolve that before spending anything: a tested change that cannot be released is not an outcome.
- You keep the repository, accounts and keys.
- No job needs a production password or customer data in the first enquiry.
Choose the smallest job that answers the question
If you do not know what is behind or in what order, the inventory and plan is a fixed-price first step with no change to your code. If one component is the known problem, a single fixed upgrade fits when your stack is one of the listed ones: Rails 7 to 8.1, Node.js to 24 LTS, Express 4 to 5, Python 3.9 or 3.10 to 3.13, Heroku to a new host, MySQL to PostgreSQL, one column on one large table, Webpack to Vite, a TypeScript folder, one legacy front-end feature, or one module pulled out of a monolith. If several steps depend on each other, a programme takes them in order. To stay current afterwards, the monthly services keep versions supported or run the next version in CI.
- Prices are untested proposals; payment follows the agreed checks and your sign-off.
- A step without a published job is quoted in writing with its own checks, or declined.
What to bring, and what not to send
Bring the language and framework versions, the names of the manifest and lockfile, the test command and how long it takes, and the three flows that matter. Do not send environment files, tokens, passwords, database dumps or customer records. After agreement the code goes through a company-controlled secure handoff with secrets removed, and tests run on a copy with synthetic data.
- A link to a public repository is enough for the first enquiry.
- If tests cannot run without production data, say so; some jobs stop there.
When this is not for you
These jobs do not fit a repository that holds many applications, an app with no way to run tests on a copy, or work that needs security, legal or compliance conclusions. They also do not promise that a version stays supported: vendors change their dates. An engagement that cannot be tested safely is better declined than priced.
- No guarantee of future support dates.
- No audit or certification: dates and advisories are reported as vendors publish them.
Sources and limits
- Node.js release schedule Checked 2026-10-11.
- Vendors publish release, support and end-of-life dates per version, and the Node.js project says its dates are subject to change.
- GitHub Docs: about Dependabot version updates Checked 2026-10-11.
- Dependabot opens pull requests for newer versions; confirming that tests pass and merging are left to you.