PHP & Laravel
Maintenance Support
Migrate, upgrade and improve an existing application, with a clear plan for handover and ongoing maintenance.
Start with what must keep working
tPanel supports custom business software, including applications built by another team. For PHP and Laravel systems, we review the current setup, critical workflows and access before agreeing maintenance, fixes or a version upgrade.
Tell us whether you need an ongoing support arrangement, a defined upgrade or help taking over an application. Each starts with understanding the code and how your business depends on it.
- Maintenance
- Routine upkeep and an agreed way to report issues.
- Upgrade
- A defined compatibility change with testing and release checks.
- Handover
- The access, documentation and responsibilities needed to support an inherited application.
A system with a backlog of faults may need remediation before routine maintenance can begin. We identify that work and agree its scope with you.
Separate routine support from a change project
| Need | What we review | What we agree |
|---|---|---|
| Ongoing maintenance | Hosting, dependencies, backups, monitoring and support needs. | Covered systems, routine tasks, contact process and response expectations. |
| PHP or Laravel upgrade | Current versions, packages, custom code and critical workflows. | Target versions, compatibility work, tests and release plan. |
| Application handover | Source repository, deployment, credentials ownership and documentation. | Access transfer, initial findings and support boundaries. |
| A fault or slow workflow | A reproducible example, logs and the affected users or records. | Investigation scope, proposed fix and acceptance check. |
What to agree for the initial application review
An inherited application needs a defined starting point. Agree the review fee, access and deliverables before work begins. The review should give you a basis for deciding what to fix now, what to upgrade and what can remain in place.
- System and access map
- Record the application, runtime, packages, hosting, integrations and who controls the accounts. Identify access gaps that prevent reliable assessment.
- Findings with priorities
- Separate reproduced faults from suspected issues. Identify affected business workflows, dependency constraints and areas that need further investigation.
- Options and scope
- Compare a targeted repair, staged upgrade or wider change. Document assumptions, exclusions and the work needed before an estimate can be confirmed.
- Acceptance and release plan
- Agree the workflows to test, who accepts the result, backup and rollback requirements, and responsibilities after release.
The depth of the review depends on the agreed scope and available access. A code review alone does not establish that every workflow is correct; critical behaviour needs to be checked with the people using the system.
Experience maintaining business applications
Our published Particle case study documents an ongoing Laravel CRM and its 2026 move to Laravel 13 and PHP 8.4. The Everau/Tangwealth case study describes a PHP and Laravel IMBA/Order Hub system that connects channels, warehouses and a wholesale customer workflow.
These projects show application development and continued maintenance. They are not claims that every inherited application can be repaired on the same schedule or upgraded through the same steps.
Plan the upgrade around the workflows at risk
- Establish the baseline
- Identify PHP and Laravel versions, packages, database, scheduled jobs and external services.
- Check compatibility
- Choose supported target versions and identify package or application changes needed to reach them.
- Test the business workflow
- Check login, permissions, data changes, queues and integrations in a separate environment.
- Agree the release
- Plan backups, data changes, the release window, rollback limits and post-release checks.
A framework upgrade does not by itself verify your business rules. An order submission, lead assignment or scheduled import needs its own acceptance check. Any data migration also needs a plan for restoring or reconciling changes if the release cannot continue.
Support dates change. Check the official PHP supported versions and Laravel release notes when choosing a target. We do not assume that a version number alone tells us the application's condition.
From older versions to a supported application
- Laravel 5.x -> 13
- A possible modernisation scope, reviewed across the intervening framework changes. Packages, authentication, custom code and tests determine the route.
- PHP 7.4 -> 8.4
- A possible runtime upgrade target, with checks for removed features, changed behaviour, extensions and package compatibility.
These are examples of work to scope, not one-click upgrades or claims about the starting versions of our published projects. We plan intermediate compatibility steps and test the business workflows in a separate environment before production changes.
Laravel 13 supports PHP 8.4, but the target version is chosen for your application and its dependencies. PHP 8.4 is not described here as the latest PHP release. See Laravel's support matrix and PHP's supported versions.
Find the gaps, then agree what to fix
- Code and dependency review
- Map the parts that affect the change: package compatibility, configuration and critical application paths.
- Faults and performance
- Reproduce reported errors and investigate slow queries or background jobs before choosing a fix.
- Permissions and tests
- Review who can access records and add checks around the workflows affected by the work.
- Migration and visibility
- Plan code or data migration where needed, and improve logs or monitoring so faults are easier to identify.
A move from custom PHP or another framework to Laravel may be appropriate when the existing structure prevents the required changes. We compare that option with retaining and improving the current application. Agree data mapping, validation, cutover and rollback limits before migration.
If the previous developer is no longer available
Start by listing the accounts and materials the business controls. Missing documentation is useful to know early; missing source code or hosting access can limit what can be assessed or changed.
- The source repository and the right to modify the application.
- Hosting, database, domain and deployment account ownership.
- Current PHP and Laravel versions, if known, plus a dependency list.
- Examples of the workflows that matter and any reproducible errors.
- Backup arrangements, recent changes and known third-party connections.
Send a summary first. We arrange appropriate access after agreeing the review; passwords, private keys and customer exports do not belong in the enquiry form.
Maintenance pricing and upgrade scope
tPanel's managed software hosting, maintenance and support plan is A$1,000 + GST per month for a standard scope. Larger systems, complex architecture or many dependencies may need a higher fee, agreed before starting or changing the scope.
The plan includes the agreed hosting, monitoring, daily database backups, routine updates, security patches and local support. See the full managed software plan for the current scope.
- Agree separately
- Confirm the scope and cost of initial handover, accumulated faults, major upgrades and new features before work begins.
- Response and resolution
- Agree support expectations for your system. A response time is not a promise that every fault can be fixed within that period.
If you only need a defined upgrade or investigation, describe that in your enquiry. We can discuss the work without assuming that a new application must be built.
PHP and Laravel support questions
Can you maintain software built by another developer?
Yes, after reviewing the setup and agreeing the handover and support scope. We need to understand the code, hosting, dependencies and access available before accepting ongoing responsibility.
Is a Laravel upgrade the same as a PHP upgrade?
No. PHP is the runtime language and Laravel is the application framework. Their requirements and support windows interact, and third-party packages may impose additional limits. We review them together when planning an upgrade.
Will an upgrade require downtime?
That depends on the deployment setup, database changes and integrations. We agree the release window, rollback approach and validation steps after review. We do not promise zero downtime before understanding the application.
Can you fix one problem without replacing the whole application?
Potentially. We first reproduce the problem and review the affected code and dependencies. A targeted fix may be sufficient; if a wider change is necessary, we explain the reason and agree the scope.
Do you provide a security certification or penetration test?
Routine patching and application maintenance are different from an independent penetration test or certification. If those are requirements, identify them explicitly so their scope and provider can be agreed.
What if we do not know the PHP or Laravel version?
Tell us what the application does and who currently manages its hosting. We can discuss how to obtain the technical information through an agreed review. You do not need to guess the version.
Planning something new?
For a new application or major feature programme, see PHP and Laravel development. If you are choosing between a freelancer, an internal hire and a development company, our hiring guide explains the trade-offs.
Tell us about the system you already run
Share what the application does, where it runs and what needs attention. We will discuss access, an initial review and a support or upgrade scope.
Working with us from another city? See how we communicate, arrange on-site visits and quote projects.