Planning a Laravel upgrade when the business depends on the application

Your Laravel application still takes orders, produces reports or keeps the operations team working. You also know it needs an upgrade. The hesitation is understandable: nobody wants a maintenance project to interrupt the system the business uses every day.

A Laravel upgrade needs a plan that connects the technical changes to the work your staff and customers actually do. Before estimating the job, I would want to understand the current application, the proposed destination and how we will prove that the important workflows still work.

I am Adam, the developer behind DawsonyWeb. This is how I would scope an upgrade for a live business system, particularly one that has changed hands or gone a while without regular maintenance.

Establish what is running before choosing the upgrade route

I would start by recording the installed Laravel and PHP versions, the application's packages and the services it depends on. I would also check how the application is deployed and whether its development setup can reproduce the relevant production behaviour.

The framework version is one part of that picture. A third-party package, a custom integration or a hosting restriction may affect the route we can take.

Laravel publishes version-specific upgrade guidance describing dependency changes and changes that may affect application behaviour. I would work through the guidance relevant to the actual starting and target versions. The linked guide is for Laravel 12 to 13; an older application needs the appropriate earlier guides considered too.

Separate the upgrade from the wish list

It is tempting to combine an upgrade with a redesign, a reporting overhaul and the feature everyone has been requesting. I would make each of those an explicit scope decision.

There may be good reasons to replace a dependency or change a piece of custom code during the upgrade. Those requirements should be explained. Unrelated improvements can be planned separately, so there is a clear baseline for checking whether the upgraded application behaves correctly.

Otherwise, a changed result becomes harder to interpret. Did the upgrade break the report, or did the new reporting rules change its output? Keeping the scope understandable makes the review easier for everyone involved.

Write down the workflows the business cannot lose

I would ask the people using the system to identify their essential tasks. That list should include work that happens outside the browser, such as scheduled exports and background processing.

A useful starting set might be:

• Signing in and accessing the records appropriate to that user.
• Creating and updating a representative business record.
• Producing the reports used for operational decisions.
• Sending notifications and processing background jobs.
• Exchanging information with external systems.

Each item needs an expected result. “Check reporting” is difficult to sign off. “Generate this report for this sample period and explain any differences from the agreed baseline” gives us a concrete check.

What if the Laravel application has few tests?

I would establish a baseline before making broad changes. That means reproducing the important journeys and adding focused checks around behaviour that matters to the business.

The goal is useful evidence. A large number of tests is not automatically reassuring if none of them covers the process your staff depend on. Equally, a manual check alone may be difficult to repeat consistently throughout a substantial upgrade.

I would agree a practical combination of automated checks and staff acceptance testing. Known problems should be recorded at the start, so an existing defect is not confused with a new regression. If something cannot yet be verified, that uncertainty belongs in the plan.

Make staging safe enough to test real workflows

The test environment should allow realistic checks without accidentally contacting customers or changing live business records. I would review email delivery, external integrations, scheduled tasks and payment configuration before exercising those workflows.

For example, a copied application may contain a scheduled export. In an isolated test setup, I would want to know where that export goes and whether it is allowed to run. Simply using a different website address does not answer those questions.

Test data also needs thought. It should represent the awkward cases the application handles, while limiting unnecessary use of personal or confidential information.

Plan recovery before the production release

I would want a written release procedure, a recovery plan and an agreed decision point for stopping if checks fail. That includes who is available to make the decision and who will tell staff what is happening.

A backup is useful, but the plan needs to explain how recovery would work. If customers can create new records after deployment, restoring an earlier database could remove those records. If the upgrade changes the data structure, returning to the old application code may need more than switching a release folder.

Those are reasons to assess recovery in advance. Depending on the changes, the sensible approach might include a maintenance window, a compatible deployment sequence or a tested forward fix. I would not promise zero downtime without understanding the application and release requirements.

Check the first real processing cycle after launch

Opening the homepage is a small part of release verification. I would also want evidence that the scheduled and background work resumes as intended.

If a report runs overnight, its first completed run belongs in the follow-up checks. If an integration sends records to another system, I would trace a representative record through that handover. The person responsible for those checks should be agreed before deployment.

For background processing specifically, my article on investigating stuck Laravel queues explains why a functioning website can still have missing emails or unfinished imports.

What affects the cost of a Laravel upgrade?

I would estimate from the application's starting point, package compatibility, custom code, test coverage and release requirements. The number of versions involved is useful context, but it does not describe the whole job.

A scoped proposal should identify confirmed work, unresolved dependencies and the checks included in the price. If an initial review is needed to make the estimate meaningful, I would explain what that review is intended to establish.

You can see my development and support pricing for ways to start. There is no universal upgrade price that sensibly covers every business application.

Get an upgrade plan around your actual system

To start a conversation, tell me what the application does, which Laravel version it uses if you know it, and whether there is a deadline driving the upgrade. Mention any integrations or workflows that would be costly to interrupt.

I provide Laravel development and ongoing support for businesses that depend on their platform. You work directly with me, from understanding the system through to agreeing the implementation and release checks.

Putting off a Laravel upgrade?Tell me about the application and what your business needs to keep running. I can help scope the work and a practical release plan.
Discuss your upgrade with Adam