Project upgrade-programme-legacy-app-to-supported-stack · revised 11 October 2026
Project
Bring one legacy app's runtime, framework and key dependencies onto supported versions
An inventory and ranked plan first, then each agreed step taken in order, tested and accepted, until the app's runtime, framework and key dependencies are on supported versions.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the plan, the price and the terms in writing.
The result you are buying
When a runtime, a framework and several dependencies are all behind, the upgrades depend on one another. A framework step may need a newer runtime, which may need a dependency replaced, which may need a test suite that runs. Done in the wrong order, or all at once, nobody can tell which change broke which behaviour. A programme exists to take the steps in a planned order, each tested before the next starts.
Who it’s for: A founder or engineering lead whose app is several versions behind in more than one place, so that no single upgrade fixes the problem.
Usually starts when: A host or customer demands supported versions by a date, a full upgrade has been put off for years, or an earlier attempt failed halfway because the steps were taken in the wrong order.
The result: You buy the finished programme, not the individual steps. The app's runtime, framework and key dependencies are on versions their vendors support, every step in the agreed plan has been accepted by you or removed from it in writing, the whole test suite and your named business flows pass on the final stack, and you hold a release plan.
How the work fits together
The programme is complete when every step in the agreed plan has been accepted by you or removed from the plan in writing, and the whole test suite and your named business flows pass on the finished stack. You accept the finished programme, not each internal action.
Fix one failing GitHub Actions job and show a green run Job First
One failing job in one workflow runs green on your pull request branch, on the same trigger, with the before and after logs attached. You review and merge the change.
If your pipeline is red at the start, we fix that first so every step can be checked.
Get a tested, ranked upgrade plan for one app's runtime and dependencies Job Included
One repository: every runtime, framework and direct dependency checked against the vendor's published support dates, the existing tests run as a baseline, and a ranked upgrade path.
One, always the first step
After: Fix one GitHub Actions job
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.
If the plan names it
Taken before a framework step that needs a newer Node.js.
After: Upgrade inventory and plan
Move one Express 4 app to Express 5 with route patterns and error handling tested Job Optional
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.
If the plan names it
After: Upgrade inventory and plan
Move one Python 3.9 or 3.10 app to Python 3.13 with removed modules and wheels sorted Job Optional
Run one Python 3.9 or 3.10 application on Python 3.13: dependencies installed from a clean environment, removed standard-library modules replaced, and the tests and named flows passing on a copy.
If the plan names it
After: Upgrade inventory and plan
Move one Rails 7.0–7.2 app to Rails 8.1 with its key flows tested Job Optional
Take one Rails 7.0, 7.1 or 7.2 app to Rails 8.1 one minor version at a time, on the Ruby each step supports. Tests and five named business flows pass on a staging copy before your release.
If the plan names it
Older Rails apps are taken to Rails 7 as a quoted step first.
After: Upgrade inventory and plan
Move one MySQL application database to PostgreSQL with data reconciled and queries passing Job Optional
Move one application's MySQL database to PostgreSQL: schema converted, every table's rows reconciled, the app's queries and tests passing on PostgreSQL, and a rehearsed cutover with a way back.
If the plan names it
After: Upgrade inventory and plan
Change one column on one large table in steps, with every row reconciled and a way back Job Optional
Change one column of a large PostgreSQL or MySQL table in steps while the app runs: new column added, backfilled, reconciled row by row, then switched, with the old column kept until sign-off.
One for each table the plan names
For example, an integer key that is running out of range.
After: Upgrade inventory and plan
Move one Heroku web app and its Postgres database to a host you control Job Optional
Move one Heroku web app and its Postgres database to a host you choose. A backup you restore is reconciled table by table, and a cutover with a rehearsed way back is agreed first.
If the plan includes leaving Heroku
Usually taken after the runtime steps, so the app moves once, on supported versions.
After: Upgrade inventory and plan
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 app on supported versions.
How an engagement works
The price covers the agreed steps only. Steps you add later are quoted separately, and a step that turns out to be bigger is re-scoped with you before it starts.
How it starts
You tell us the stack, the reason and any deadline, and send a link to the repository or its manifest names.
You agree the inventory and ranked plan in writing, at its own fixed price, payable after sign-off. Nothing is shared and nothing starts before then.
After that agreement you share a read-only copy through the secure handoff, and we run the inventory and ranked plan and propose the steps, their order and a fixed price for the agreed list.
You agree the list, price and terms in writing. Anything the inventory adds beyond what was quoted is priced in writing before work on it.
We take each step in order on a copy, sending a pull request with its evidence for you to accept before the next begins.
We run the final checks and send the summary and release plan.
Who decides what
You decide the steps and accept each one. Your team merges and releases on its own gates.
Handover
Each accepted step arrives as a pull request with its evidence and reverse steps. Anything unfinished is handed back with notes.
Sharing your product safely. Send a link and the version numbers, never code contents or secrets, in the first enquiry. After you agree the inventory in writing, we use the secure handoff for a read-only copy and synthetic test data.
What is included, and what is not
- The inventory and ranked plan
- One pull request per agreed step, with its test results and rollback notes
- The final test and business-flow results on the finished stack
- A written final summary and release plan
Included
- One application in one repository with one primary database, and its agreed list of upgrade steps
- The inventory and ranked plan as the first agreed step, a one-off job you can also buy alone; it sets the steps, their order and the price of the rest, and anything it adds is priced in writing before work on it
- Each agreed step taken on a copy in the planned order, tested, and handed over as its own pull request before the next begins
- A final run of the whole test suite and up to five named business flows on the finished stack, and a release plan with a way back (shown in the quote as one stated line, because no single step contains them)
- A written final summary showing every step, how it ended and what is left
Not included
- Steps added after the price is agreed, unless you add them to the plan in writing
- New features, redesign or changing the application's behaviour
- Production deployment and live data changes, which stay with your site holder
- Replacing a dependency that has no supported release and no maintained alternative without a separate decision
- Moving an operating system, a database server or a host onto a supported version: the inventory records their versions, and any step for them is quoted separately
- Security audits, compliance reviews or any guarantee of future support dates
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every step in the agreed plan is either accepted by you or removed from the plan in writing, with its pull request, test results and reverse steps attached.
Evidence: The final summary, with your acceptance or removal recorded for each step.
On the finished stack, the whole test suite passes as it did at the start, or each difference is explained in writing and accepted by you.
Evidence: Test output from the recorded baseline and from the final state.
Every runtime and framework version in the final inventory shows the vendor's published support status with a link and the date checked, and none that the plan set out to move is listed as past its end of support.
Evidence: The final inventory with its source links.
Up to five named business flows complete on staging on the finished stack, and a release plan with rehearsed reverse steps exists for the final release.
Evidence: Flow screenshots or redacted records, and the release plan with the rehearsal log.
Sign-off. You accept each step, 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 plan 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
- One application whose source, lockfile and tests can be shared and run on a copy
- Each step in the plan is one of the one-off jobs listed here, or a step we quote in writing with its own acceptance checks
- You can name up to five business flows and provide test accounts for them
- A person on your side accepts each step, and an authorised site holder can make the releases
We stop and tell you if
- The inventory shows a step that cannot be tested on a copy without production data or secrets
- A required dependency cannot be upgraded or replaced and the owner will not accept that risk in writing
- The app is several applications in one repository and the owner will not split the programme
- Nobody on your side can accept steps or make releases
What could go wrong
Each step is a separate pull request that your team merges, so any one can be reverted on its own while later steps are re-planned. Before each release agree a database snapshot and a write plan, and rehearse the reverse steps on staging for any step that changes data.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A step is bigger than the plan assumed. | The inventory states its assumptions, each step is re-scoped with you before it starts if they fail, and the price changes only by written agreement. |
| A change in one step hides a failure from an earlier step. | Steps are taken one at a time in the planned order and the whole suite is run after each. |
| The deadline arrives before the programme is finished. | The plan ranks steps by deadline as well as by dependency, and says which steps must finish first to meet it. |
Each step is reviewed separately from the work that produced it, and a second reviewer re-checks the order of the plan before work starts. 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 release on your own gates
Access we would need
- A read-only copy of the repository with secrets removed
- A fork or branch for pull requests, with no production access
Questions
Why start with an inventory?
Upgrade steps depend on each other, so the order matters. The inventory finds the order, the size of each step and the dates that matter before anyone commits to a price.
Can I buy just one step?
Yes. Each step in the plan is also sold on its own as a one-off job, where one exists for your stack.
What if my stack is not one of the listed steps?
We quote that step in writing with its own acceptance checks, or tell you it is outside what we offer.
Do you release the finished app?
No. Your site holder releases it under your accounts after reviewing our evidence and the reverse steps.
Send an enquiry
Send us
- The language, framework and runtime versions as best you know them, and why you want the programme now
- A link to the repository, or the manifest and lockfile names
- The deadline set by a host or customer, if there is one
- The business flows that matter most
Later, once you agree
- Only after you have agreed the inventory in writing: a read-only copy of the repository with secrets removed, through the agreed company-controlled secure handoff
- How to run the tests, with synthetic fixtures if they need data
- A named person to accept each step and a site holder for each release
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the code, accounts, keys and the live system. Before you agree the inventory in writing we need no code, copy or access. After that we work from an authorised copy with secrets removed and return pull requests that your team reviews and releases under its own gates. 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 “upgrade-programme-legacy-app-to-supported-stack” as the subject.