Project legacy-front-end-modernisation-programme · revised 11 October 2026
Project
Move one legacy front end onto a maintained build and replace its worst features
For one Webpack-built front end: the build moves to Vite, then up to three jQuery or AngularJS features are replaced one by one, each proved by the same browser checks before and after.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the list, the price and the terms in writing.
The result you are buying
A legacy front end is held in place by two things: a build that nobody dares upgrade and a handful of features written with libraries that are no longer supported. A rewrite is too big to start, so changes go on top of the old structure and make it harder to leave. A programme that moves the build first and then replaces the worst features one at a time lets the front end keep working at every step.
Who it’s for: A founder or engineering lead whose browser front end is held back by an old build and a few features that nobody wants to touch, and who wants to modernise it without a rewrite.
Usually starts when: A security or dependency review flags old front-end libraries, an important feature depends on an abandoned plugin, or new work keeps being delayed because the build and the old features resist change.
The result: You buy the finished programme. The app builds and runs with Vite, up to three named features no longer depend on the old jQuery plugin or AngularJS code they used, each feature's agreed browser checks pass before and after its replacement, and a list shows exactly what old code remains.
How the work fits together
The programme is complete when the build move and every feature on the agreed list have been accepted by you or removed from the list in writing. You accept the finished programme, not each internal action.
Move one Webpack single-page app to Vite with its routes, settings and tests intact Job Included
Replace the Webpack build of one browser app with Vite: every loader and plugin accounted for, environment variables renamed safely, and the same routes rendering from the new build.
One, always the first step
Replace one jQuery or AngularJS feature with maintained code and keep the page working Job Included
Replace one feature on a page built with old jQuery plugins or AngularJS with maintained code, proved by the same browser checks passing before and after and the rest of the page unchanged.
One for each feature on the agreed list, up to three
After: Webpack app to Vite
Convert one JavaScript module to TypeScript with strict checks on that folder only Job Optional
Convert one named folder of a JavaScript codebase to TypeScript under strict checking, with the rest of the code untouched, the tests passing and the type check running in CI.
One folder, if you add it to the list
After: Webpack app to Vite
Move one Node.js 18, 20 or 22 app to Node 24 LTS with builds and tests passing Job Optional
Run one Node.js app on Node 24 LTS: clean install from the lockfile, native modules rebuilt or replaced, the test suite and the container or CI configuration all on 24, checked on a copy.
Offered first if the build tools need a newer Node.js.
Keep your app's runtime and dependencies on supported versions, month after month Standing service Optional
We check one repository each month against vendors' published support dates, open tested pull requests for patch and minor updates, and warn you early when a major step is coming.
Offered afterwards to keep the front end's dependencies current.
How an engagement works
The price covers the agreed list only. Features you add later are quoted separately, and a feature that turns out to be bigger is re-scoped with you before it starts.
How it starts
You tell us about the front end, the features and the old libraries, and send the version numbers.
We read the build and the feature list and propose the steps, the order and a fixed price for the agreed list.
You agree the list, price and terms in writing. Nothing starts before then.
We move the build first, then replace each feature, sending a pull request with its evidence for you to accept before the next begins.
We send the final summary and hand over what is left.
Who decides what
You decide the list and accept each step. Your team merges and deploys on its own gates.
Handover
Each accepted step arrives as a pull request with its evidence and the steps to revert it. Anything unfinished is handed back with notes.
Sharing your product safely. Send the version numbers and a description in the first enquiry, never code contents or secrets. After you agree the programme, we use the secure handoff for a copy of the front end and test data.
What is included, and what is not
- The build move as a pull request, with its inventory of old build features
- One pull request per replaced feature, with its contract and before-and-after test runs
- A final summary with the list of remaining old-library uses
Included
- One browser front end with one Webpack build and up to three features, each on one page, agreed in a written list before the price is fixed
- The build move first, as the one-off job you can also buy alone, so the replacement features are built on the new build
- Each feature taken in turn: its contract written down, a browser test script run before and after, the old code removed from the page and the rest of the page left running
- Optionally, one folder of the replacement code converted to TypeScript, if you add it to the list
- A final summary: what moved, what old code remains and what each remaining piece would cost to replace
Not included
- Replacing the whole front end, the framework or the router
- Features added after the price is agreed, unless you add them to the list in writing
- Server or API changes, redesigns or new features
- Support for browsers older than your current requirement
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The build move and every feature on the agreed list is either accepted by you or removed from the list in writing.
Evidence: The final summary, with your acceptance or removal recorded for each step.
For each replaced feature, the agreed browser test script passes against the old feature and then unchanged against the replacement, on the Vite build.
Evidence: Two test run logs per feature, attached to its pull request.
The final summary lists every remaining use of jQuery or AngularJS in the front end by file and feature, and none of the replaced features appears on the list.
Evidence: A search result and the summary list, compared by the reviewer.
Sign-off. You accept the build move and each feature, or send it back with comments, and then you accept the finished programme.
If it fails. A step we cannot complete is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- The front end is a client-side app built by Webpack 4 or 5 and the features are in the repository
- Each feature is on a page that runs on a copy with test data and can be exercised in a browser
- A person on your side can say what correct behaviour is for each feature and can accept each step
- Your team deploys the build under its own gates
We stop and tell you if
- The app is server-rendered from the same build, or must support browsers older than Vite's documented targets
- A feature is so entangled with the rest of its page that it cannot be separated without a page rewrite
- The features can only be exercised with live customer data or real payments
- Nobody on your side can accept steps
What could go wrong
Each step is a separate pull request that your team merges, so any one can be reverted on its own. If the programme stops, accepted steps stay accepted and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A feature is bigger or more tangled than it looked. | We read each feature and its page before pricing, name the ones that are bigger jobs and re-scope them with you before work on them starts. |
| Replacing one feature breaks another on the same page. | Each replacement is checked with a before-and-after run of two untouched features on that page. |
| The new build changes behaviour in a way the routes do not show. | The build move is accepted first, with a route and settings check, so any later feature problem is not mixed up with it. |
Each step is reviewed separately from the work that produced it, and you accept every step. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each step
- You merge and deploy on your own gates
Access we would need
- A read-only copy of the front end with secrets removed
- A fork or branch for pull requests, with no production access
Questions
Why move the build first?
New code should be written on the build you intend to keep. Accepting the build move first also means a later feature problem cannot be confused with a build problem.
Will jQuery or AngularJS be gone at the end?
Only if every feature that uses them was on the list. The final summary shows exactly what remains, so you can decide on the next round.
Can I buy one feature on its own?
Yes. Each feature replacement and the build move are also sold on their own as one-off jobs.
Send an enquiry
Send us
- The Webpack and Node.js versions, and the framework or libraries the front end uses
- The features you want replaced, the pages they sit on and the old libraries they use
- How the front end is built, served and deployed
- The reason for the programme and any deadline
Later, once you agree
- A controlled copy of the source and build configuration with secrets removed, through the agreed company-controlled secure handoff
- A way to run each page on a copy with test data, and a test account where needed
- A named person to accept each step
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the code, hosting and data. We work from an authorised copy with secrets removed and return pull requests that your team reviews, merges and deploys. We never ask for passwords 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 “legacy-front-end-modernisation-programme” as the subject.