Job node-express-4-to-5-upgrade · revised 11 October 2026
Move one Express 4 app to Express 5 with route patterns and error handling tested
Upgrade one Express 4 app to Express 5: converted route patterns, removed methods replaced, async errors reaching your error handler, and a before-and-after URL table proving the same responses.
You might be seeing
- Package audits or reviews list Express 4 as the framework major version behind
- Some routes use wildcard or optional-parameter patterns and nobody is sure how they behave on a newer version
- Async route handlers sometimes hang the request because errors are not reaching the error handler
No passwords, keys, card details or admin invites needed to start.
What usually happened
Express 5 changes how paths are matched and how errors flow, and removes several methods. Wildcards must be named, optional parameters use braces and regular-expression characters are no longer allowed in paths, so a pattern that matched on Express 4 can silently stop matching or fail at start-up. Rejected promises in handlers are now passed to the error handler, request properties change shape, and static dotfile handling is stricter. An app can start cleanly and still return different statuses for a few URLs.
Who it’s for: A founder or engineering lead whose Node.js API or website is built on Express 4 and who needs the web layer on the current major version without changing what the app does.
Usually starts when: A dependency or the team's standards now require Express 5, a security or support review asks why the web framework is a major version behind, or a Node.js runtime upgrade has put the framework next in line.
The result: The app runs on Express 5. Every route pattern is converted or confirmed, every removed method is replaced, and a table of agreed sample URLs returns the same status and body shape before and after the upgrade, apart from differences you have accepted in writing. Errors thrown in async handlers reach your error handler.
Check whether this job fits
Five short questions. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Find the installed Express version
Run this in a copy of the project folder after dependencies are installed.
npm ls expressLook for: A version beginning 4. Send the line, nothing else.
List route strings with special characters
Run this read-only search in a copy of the project folder. It skips installed dependencies and prints only the matching route strings, not the surrounding code. Send what it prints.
grep -rhoE "\.(get|post|put|patch|delete|all|use)\(['\"][^'\"]*[]*?()[][^'\"]*['\"]" --include='*.js' --include='*.ts' --include='*.mjs' --include='*.cjs' --exclude-dir=node_modules --exclude-dir=vendor --exclude-dir=dist --exclude-dir=build .Look for: Route strings with an asterisk, question mark, brackets or parentheses, each printed after the method name. These are the patterns to convert first.
What you get
- The changed code and lockfile as a pull request
- The route inventory with the old and new pattern for each changed route
- The before-and-after URL table and the new or changed tests
- A short note on any behaviour that changed and was accepted
Included
- One Express 4 application with up to 60 routes and up to 10 custom middleware modules
- An inventory of every route pattern, converting wildcards, optional parameters and any regular-expression paths to the Express 5 path syntax
- Replacing every method and argument form that Express 5 removed, such as the old status-argument forms of json and send, req.param, app.del and the string 'back' redirect
- Checking request properties whose behaviour changed: body when no parser ran, the query getter, parameter shape, host with port and static dotfile handling
- A before-and-after table of agreed URLs and methods, with status and response shape, and tests for the error path of async handlers
Not included
- Moving the Node.js runtime, which is a separate job and can be done first
- Changing to another framework, rewriting routes into a new structure or adding features
- Upgrading unrelated dependencies beyond what Express 5 requires
- Deploying to production, which stays with your team
- Load, performance or security testing
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The agreed URL and method table returns the same status code and response shape on Express 5 as on Express 4, with each difference listed and accepted by you in writing
Evidence: The before-and-after table, one row per URL and method, produced from a run on a copy
Every route pattern in the app that used a wildcard, optional parameter or regular expression has a documented conversion and at least one URL that must match and one that must not
Evidence: The route inventory with old pattern, new pattern and the sample URLs
A test that throws and a test that rejects a promise inside an async route handler each produce your error handler's response rather than a hung request
Evidence: The two test results on Express 5
No removed Express 4 method or argument form remains in the code, and the existing test suite passes as it did before
Evidence: A search result showing none left, and the test output before and after
Sign-off. You review the URL table and the list of accepted differences and merge the pull request when satisfied. A match on the agreed URLs does not prove every possible request behaves the same.
If it fails. If the agreed acceptance checks do not pass, you do not pay and you keep our route inventory and findings.
When it fits, and when we stop
It fits when
- The app uses Express 4 and runs on Node.js 18 or newer, which Express 5 requires
- There are up to 60 routes and up to 10 custom middleware modules, or you accept a quote for the difference
- You can supply a list of URLs and methods that matter, with expected statuses, or let us derive the list from the routes and tests
- A person on your side can review and merge the pull request
We stop and tell you if
- The app depends on an Express 4 middleware or plugin with no Express 5 compatible release and no maintained replacement
- The app runs on Node.js older than 18 and the runtime cannot be moved first
- Routes are generated from data at runtime in a way that cannot be listed or tested on a copy
- There is no safe way to exercise the app without production data
What could go wrong
The change is a pull request your team merges, so it can be reverted like any other. Before release keep the previous lockfile and build, and revert the dependency version if a live check fails.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A converted pattern matches a different set of URLs than before | Each changed pattern is covered by sample URLs that must and must not match, compared before and after. |
| Errors in async handlers now reach the error handler and expose a previously hidden failure | We test the error path on purpose and show you what now reaches your handler, so a hidden failure is reported rather than introduced. |
| Static files served from hidden directories, such as .well-known, change behaviour | The Express 5 guide says dotfiles are ignored by default and well-known paths return 404 unless allowed; we test the paths your app serves and set the option you agree. |
A second reviewer re-reads every converted route pattern against the comparison table and checks the error-handler tests, and re-runs the URL table from the handover notes alone.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the URL and method list and the definition of done, then run the app on a copy with Express 4 and record each status and response shape as the baseline
- List every route pattern and every use of a removed method or argument form
- Upgrade the dependency, convert each pattern to the Express 5 path syntax and replace each removed form with its documented equivalent
- Review request-property uses that changed, such as the body when no parser ran, the query object and static dotfile handling, and fix or note each
- Add tests that throw and reject inside async handlers and prove the error reaches your error handler, then re-run the URL table on Express 5
- Independent review of the diff and the URL comparison, then hand over the pull request with the evidence and the steps to revert it
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly service that keeps dependencies current and runs the next major version in CI.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- The Express project publishes a migration guide and a codemod recipe for the mechanical changes. If your team can review and test the result against your real URLs, start there. expressjs.com
- If you only need the runtime on a supported Node.js line, Express 4 may keep working while that is done; do the runtime first and treat Express 5 as its own step.
Questions
Can the Express codemod do this for me?
It handles some mechanical changes. It cannot tell you whether a converted route still matches the URLs your users and integrations send, which is what the before-and-after table checks.
Do I need to upgrade Node.js first?
Express 5 needs Node.js 18 or newer. If you are below that, move the runtime first, as its own job.
Will my API responses change?
They should not. The job compares status and response shape for the agreed URLs and lists any difference for you to accept or reject.
Send an enquiry
Send us
- The Express version in the lockfile and the Node.js version in production
- A rough count of routes and middleware, and whether the routes are in a few files or generated
- Any routes you know use a wildcard, an optional parameter or a regular expression
- Whether the app has tests and how they are run
Later, once you agree
- A controlled copy of the source and lockfile with secrets removed, through the agreed company-controlled secure handoff
- How to start the app and run any tests locally, plus synthetic fixtures if routes need data
- A list of important URLs and methods, or agreement for us to derive it from the code and confirm it with you
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the code and the live system. We prepare the change from an authorised copy with secrets removed and return a pull request that your team reviews and merges and deploys under its own gates. We never ask for passwords or tokens in the first enquiry.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “node-express-4-to-5-upgrade” as the subject.