Job laravel-old-app-to-supported-version · revised 9 October 2026
Upgrade one Laravel 6–10 app with its key business flows tested
Upgrade a Laravel 6–10 app to a currently supported version on staging. Inventory every route and job, then deeply test five agreed business flows before the client-controlled release.
You might be seeing
- A warning that the app uses an unsupported Laravel version
- Your host will remove the PHP version it runs on
- Composer cannot install or deploy the app on a new server
No passwords, keys, card details or admin invites needed to start.
What usually happened
The app is several Laravel major releases behind. An automatic dependency bump does not update route, authentication, queue and database behaviour or third-party packages, so forcing a newer PHP or Laravel version can break logins and transactions. The business needs an accountable tested upgrade, not a PR it cannot evaluate.
Who it’s for: Owner of a custom Laravel app that runs the business but has nobody maintaining it.
Usually starts when: The host removes the PHP version the app needs, a security scan flags its old Laravel version, or the original developer has left and routine changes can no longer be deployed.
The result: A Laravel app on a supported version passes a route and job inventory on staging, and up to five named business flows pass detailed checks. The owner sees any untested paths and accepts the remaining risk before a live release.
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 exact Laravel version
Ask whoever holds the code to open composer.lock, or run this read-only command in a copy of the project folder.
composer show laravel/framework | grep -E "^versions"Look for: A version beginning 6, 7, 8, 9 or 10. A version beginning 5 needs a separate assessment.
See which PHP version the server runs
Your hosting control panel shows it under PHP settings, or your host can tell you.
Look for: The current PHP version and the newest one the host offers. Send both; they decide the target Laravel version.
What you get
- A compatibility inventory and staged upgrade path
- Changed app code and dependencies with the tests and smoke-check results
- A list of packages that could not be upgraded, if any, and the deployment and rollback steps
Included
- One Laravel 6–10 app with one database, up to five named critical flows and a manageable route/job inventory
- An inventory of every production route, command, scheduled task and queued job from source and host configuration
- A staged framework and PHP upgrade path, including package compatibility decisions
- A staging smoke check of every inventoried route and job without real customer mail or payment, and deep before/after tests of the five critical flows
- A release decision sheet naming any path or integration that could not be tested
Not included
- New features, redesign or a database re-platform
- A Laravel 5 or older app, which needs a separate code and data assessment
- Deploying to production under your account or managing live credentials
- Rewriting an abandoned third-party package if no supported alternative exists
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The target app installs with its lockfile on the agreed supported PHP version, and the test command finishes without failures
Evidence: Dependency and test logs from the isolated copy
Every inventoried route loads or returns its documented expected status on staging; the five named critical workflows complete without new fatal errors
Evidence: Route inventory with status per route, plus screenshots and redacted test records for the five deep flows
Every inventoried scheduled command and queue job has a staging smoke result; each named critical job runs once without sending customer mail
Evidence: Job inventory, smoke result and captured mail for critical jobs; any untestable job is named as a release risk
The rollback steps restore the old application and database snapshot in a test restore
Evidence: Before/after restore result
Sign-off. You review the route/job inventory, the five detailed workflow results and any untested integration before approving your site holder’s live release. A route list alone is not proof every business rule works.
If it fails. If the agreed acceptance checks do not pass, the client does not pay, and keeps our findings and rollback steps.
When it fits, and when we stop
It fits when
- The app is Laravel 6–10 and its source code and composer lockfile are available
- You can name up to five workflows the business needs and can provide a test account
- A safe copy of the app and database can run without live payments or customer email
- Your site holder can approve and carry out a live deployment
- Every production route and background process can be inventoried, or the remaining uncertainty is accepted in writing before any deployment
We stop and tell you if
- The code or its dependencies are encoded or cannot legally be changed
- A required package has no compatible release or alternative and needs a large rewrite
- There is no safe way to test a copy without real payment cards or regulated data
- The database migration cannot be reversed or rehearsed without a separate data plan
- A critical production route, job or integration cannot be checked on staging and the owner will not accept that explicit risk
- The business cannot pause writes for cutover and has no tested way to reconcile records if a rollback is needed
What could go wrong
Before release, agree a write freeze and take a database snapshot. Keep the old release available. If a live check fails after writes resume, export and reconcile every intervening record into the restored old app, rehearse that procedure on staging, and only then reverse traffic; restoring a snapshot alone would discard customer data.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A dependency upgrade changes login or payment behaviour | Test each named flow on staging and review the auth and payment diff independently. |
| A database change cannot be undone cleanly | Rehearse the data migration on a copy; stop if rollback requires a separate plan. |
| Staging sends real emails or changes real records | Use sanitised data and captured mail; never test with live payment cards. |
A second reviewer checks every change to login, payments, queues and database migrations, and re-runs one workflow 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.
- Restore a copy and inventory every production route, scheduled command, queue job and external integration before deciding the upgrade path
- Read composer.lock and plan the version path, checking each package for a release that supports the target
- Step through each major version, applying that release’s upgrade-guide changes and running the tests after each step
- Smoke-test every inventoried route and job on staging, then deeply test the five agreed flows with captured mail and fake payment data
- Independent review of authentication, payment, queue and database-migration changes
- Hand over the changed code, results, and deploy and rollback steps; your site holder deploys
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 maintenance arrangement that keeps dependencies supported and reruns your key flows after changes.
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
- Laravel Shift sells automated upgrade PRs for individual version steps at a much lower starting price. If you have a developer who can review, merge and test them, start there.
- Your host may offer a supported PHP version alongside the old one while you prepare the upgrade. This buys time but does not restore security support for the old framework.
Questions
Can I use an automated upgrade tool instead?
Yes, if someone can review and test its PR against your actual business flows. This job includes the testing and an accountable staging result.
Will you put the upgraded app live?
Your site holder deploys it under your account after reviewing our staging evidence and rollback steps.
Start with an email
Send us
- The current Laravel and PHP versions, if known
- A redacted copy of the composer package list, not secrets or application code in the first email
- The five most important business workflows and what breaks now
- Who holds the code and hosting accounts
Later, once you agree
- A controlled copy of the source and composer.lock, with secrets removed
- A sanitised database snapshot or fixture and a test account
- The site’s holder available to review the staged result and deployment steps
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
The client owns the accounts, domain, live system and keys. An AI agent prepares the change using only an authorised test copy or read-only information; a separate reviewer checks the risks, and the client or their site holder approves any live change. Synthetic Industry is owned by a person and remains accountable for the agreed work. We never ask for passwords in the first enquiry.
Or write to hello@syntheticindustry.ai with “laravel-old-app-to-supported-version” as the subject.