Upgrading an Old Laravel or PHP Site in 2026

Real Costs, Real Tools, and the Question Nobody Asks First

Most business websites do not break on the day their software stops receiving security fixes. They keep working. Leads come in. Pages load. The contact form is still there. The owner opens the site and sees exactly what they expect to see.

That is the dangerous part.

There is no warning on the homepage saying: THIS WEBSITE IS RUNNING ON SOFTWARE FROM 2018. Nothing turns red when a framework reaches end of life. Nobody receives a notification because a package has quietly been abandoned. The site can look completely healthy while the technology underneath it gets harder to maintain, harder to secure and harder to change.

The owners are rarely careless. Usually, the website simply never gave them a reason to look.

So the real question in 2026 is not whether an old Laravel or PHP site still opens. Of course it does. The question is how much of the business now depends on software that nobody has looked at closely for years.

In short

• More than a third of PHP websites still run on PHP 7 or PHP 5, which no longer receive security fixes (W3Techs, September 2026).
• Laravel can only be upgraded one major version at a time, and PHP has to move with it: Laravel 13 requires PHP 8.3 or newer.
• Automated tools handle the mechanical steps, but most of the cost is in testing, abandoned packages and silent failures such as undelivered email.
• An honest price for a legacy upgrade is possible only after an audit; a rewrite is worth discussing when an upgrade approaches about 60% of its cost.
• Upgrades often uncover problems outside the code, such as hosting that blocks AI crawlers, and those deserve the same attention.

THE ILLUSION

The Site That Looked Fine

One of the most useful things about a technical audit is that it removes the visual illusion. Before the audit, a website is a website. After the audit, it becomes a system: a PHP runtime, a framework, packages, integrations, hosting, mail delivery, database behavior, scheduled jobs, permissions, indexing rules, and years of decisions made by people who may no longer be around.

We recently looked at a site whose owner had no obvious reason to worry. The pages worked. The business was still using it every day. Underneath, the server was running PHP 5.6. The hosting account was controlled by someone outside the business. Service scripts were publicly accessible, PHP errors could be shown to visitors, and contact form emails were being silently rejected by the mail server.

The most important detail was not any single vulnerability. It was that nobody knew. And the hosting problem is more common than most owners think: many companies don't actually own their website, only a collection of dependencies held by other people.

That is what makes legacy software different from a broken website. A broken website announces itself. Legacy software keeps doing its job while quietly becoming more expensive to keep alive.

The fix in that case was not a heroic rewrite. It was a controlled move to hosting the owner controls, an upgrade to PHP 8.2, closing the exposed paths and restoring email delivery. The work took two evenings.

That is an important lesson. Sometimes the scary-looking problem is smaller than the story around it. Sometimes it is much larger. You only know after you look.

VISUAL AGE

Young Outside, Old Inside

This distinction gets lost surprisingly often.

A website can have a beautiful 2026 interface and a backend that belongs to another decade. The opposite is also possible: a site can look dated and still sit on a healthy, supported stack.

Visual age and technical age are different things. A design review cannot tell you whether a site is technically healthy. It can tell you that a page looks old. Only an audit can tell you what the business is actually running on.

When a new client asks us to look at an existing site, the version check is one of the first things we do. It takes minutes, and it often tells us more about the real condition of the system than a long discussion about how it looks.

THE NUMBERS

How Far Behind Is Behind?

PHP still runs most of the web. According to W3Techs data from September 2026, 70.2% of websites with a known server-side language use PHP. But the version picture is uneven: 63.4% of PHP websites run PHP 8, while 28.7% still run PHP 7 and 7.9% run PHP 5.

PHP 7 and PHP 5 no longer receive security fixes. And being on PHP 8 is not enough by itself, because each branch has its own support window:

• PHP 7.4: security fixes ended on 28 November 2022
• PHP 8.1: ended on 31 December 2025
• PHP 8.2: until 31 December 2026
• PHP 8.3: until 31 December 2027
• PHP 8.4: until 31 December 2028
• PHP 8.5: until 31 December 2029

Laravel moves on a shorter cycle. Each release receives 18 months of bug fixes and two years of security fixes. As of spring 2026, only Laravel 12 and 13 are supported; Laravel 11 lost security support on 12 March 2026.

These dates are not interesting because version numbers are interesting. They matter because the ecosystem moves with them.

THE ROAD

The Road Does Not Wait

A company can decide to stay on an old stack for another year. That decision is technically possible. What changes is everything around it.

And most of the market has already decided to move. In Zend's 2026 PHP Landscape Report, 68% of PHP teams completed a migration in the past 12 months, and 67% have one planned within the next 12 months. Only 21% have no migration plans at all.

Hosting providers retire old runtimes. Payment providers update SDKs. CRM connectors stop supporting old dependencies. Plugins disappear. Developers move on to current stacks. Documentation gets written for versions you do not use.

The site itself may continue to work. The road around it is what starts disappearing. We sometimes describe it to clients this way: you can stay parked while everyone else keeps driving, but the services along the road are not waiting for you.

That is why the cost of legacy is not only the cost of fixing an old framework. It is the growing cost of being the exception, a pattern we have written about as the hidden cost of standing still.

SUPPORT ENDS

When Support Ends

Usually, nothing dramatic happens on the exact day support ends. That is one of the reasons the date is easy to ignore. The risk grows quietly:

• Security. Vulnerabilities continue to be discovered, but fixes never arrive for the unsupported version.
• Hosting. Providers eventually retire old PHP versions, sometimes forcing a move under pressure.
• Integrations. Newer payment modules, CRM connectors and plugins refuse to install on the old stack.
• People. Fewer developers want to inherit unsupported systems, and those who do price in the risk.

The pace of the security side is worth knowing. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, with a median time to first exploitation of about five hours for heavily exploited flaws. Not every PHP site faces that exposure. But it shows how fast the environment moves while an unsupported system stands still.

AI AND INTEGRATIONS

Not Only About Security

Security is important. But it is rarely what finally makes a business owner act. The trigger is usually something they want to build next.

An AI assistant. Search that understands questions instead of exact phrases. A CRM that talks to the website. A new payment provider. A customer portal. An integration the old system cannot support.

This changes the conversation. If a client asks us to add an AI assistant and the audit finds Laravel 7, the question is no longer simply "Should we upgrade?" The more useful question is: "What are we trying to build, and what does that require?" If the answer requires a current stack, the upgrade is not a separate technical project. It is the first stage of the product they actually want.

Laravel 13, for example, introduces the first-party Laravel AI SDK, covering text generation, tool-calling agents, embeddings, audio, images and vector-store integrations. It also adds native vector query support for semantic search.

Not everyone needs these features. The point is that an old technical foundation can quietly become a limit on the business idea.

BUSINESS LOGIC

The Framework Is the Easy Part

This is where many upgrade estimates go wrong. A client hears "Laravel upgrade" and imagines replacing a framework version. But the framework is usually the easy part. The difficult part is everything that has grown around it.

An old application is not just code. It is accumulated business logic.

A strange function may exist because a particular customer receives a special price. A database field may look useless until you discover that accounting exports depend on it. An old integration may look obsolete until you learn that a warehouse still receives orders through it every morning. As we put it in another article, the code remembers every version of the business.

This is why we do not treat legacy code as garbage simply because it is old.

Before deciding what can disappear, understand what must survive.

TWO UPGRADES

Usually Two Upgrades

The first surprise for many owners is that PHP and Laravel have to move together. Laravel 13 requires PHP 8.3 as a minimum, so a site on PHP 7.4 cannot simply jump to the destination and hope for the best.

The second surprise is that Laravel major versions cannot be skipped. A site on Laravel 7 goes through 8, then 9, then 10, and so on.

Some transitions are calm. Others change core behavior. Laravel 9, for example, replaced Swift Mailer with Symfony Mailer and moved file handling to Flysystem 3. Those are exactly the changes that turn into silent business failures: mail stops going out, uploads stop working, a background job fails, and the homepage still looks perfectly normal.

The cost is rarely in the last version. It is in all the versions a company skipped.

AUTOMATION

Automation, Not Magic

Automated upgrade services are genuinely useful. Laravel Shift is the best-known example, with prices starting at $29 per Shift and an unlimited-repositories plan at $2,999 a year.

But $29 is the price of an automated step, not the price of knowing that the business still works afterward.

A project several versions behind needs several steps, and each step needs review. Dependencies may need replacing, custom code rewriting, tests running. Where there are no tests, someone has to check the behavior by hand.

There are now demonstrations of Laravel upgrades completed in minutes with Shift and AI. They show how far automation has come. They do not mean that a live business application with years of custom code, abandoned packages and little test coverage is a fifteen-minute job. In our experience, not even close.

The question is not whether automation works. It does. The question is who takes responsibility for what happens after the automation finishes.

AI AND BUSINESS

Who Reads the Business?

We use AI in upgrades ourselves, and it is extremely useful. It reads code quickly, spots repetitive changes, explains unfamiliar sections and speeds up mechanical migrations. It can save days of work.

But AI sees the code it is given. It does not know which pages generate leads. It does not know which email address the sales manager actually watches. It does not know that a strange database field feeds a report someone in finance depends on every Friday.

And its most dangerous mistakes are silent. The site opens. The menu works. The CSS is intact. Meanwhile, the contact form has stopped delivering leads.

So the useful question is not whether AI can upgrade Laravel. It can automate a substantial part of the work. The useful question is who checks the result against the actual business. We explored this in more depth in Do I Need a Developer, or Is AI Enough?

AI changes the economics of an upgrade, not the responsibility for it.

HIDDEN COSTS

Where the Money Hides

In Zend's 2026 survey, teams named testing the most time-consuming part of a migration (42%), ahead of refactoring (36%). At the same time, 32% of PHP developers surveyed by JetBrains write no tests at all.

That combination explains why old systems can be expensive even when the code itself is not enormous. If you have tests, the system tells you when something changed. If you do not, it expects a human to remember what "normal" looked like.

Then there are abandoned packages. On a trilingual corporate site we are upgrading right now from Laravel 7, a single abandoned forms package sits behind more than two hundred form fields in the admin panel. Replace that package and you are touching two hundred business processes.

And then there are the silent failures: mail, uploads, scheduled tasks, indexing, integrations. They survive unnoticed, and that is exactly what makes legacy work expensive. It is the same hidden technical debt that makes website redesigns more expensive.

INVISIBLE TO AI

A Site AI Cannot See

An upgrade rarely touches only the code. It touches the hosting, and that is where some of the most expensive surprises hide.

One of them we now find again and again: the site is partly closed to AI crawlers, and nobody decided that. Hosting providers often ship bot protection with default settings that block crawlers such as OpenAI's GPTBot or Meta's agents. Some also write their own rules into robots.txt without the owner noticing. The site works perfectly for people. For ChatGPT, Perplexity or an AI shopping assistant, it barely exists.

We saw this on a recent project. After a move to a new hosting account, GPTBot and Meta's crawlers received a 403 error, and the host had quietly added them to a disallow list in robots.txt. Nothing on the site looked wrong. It took one line of checks to see it and a few settings to fix.

The cost of missing it is real. A site that AI crawlers cannot read is not cited in AI answers, is described from outdated or third-party sources, and loses the new kind of search traffic entirely.

The same goes for email. Moving hosting without setting up SPF and DKIM is how contact form leads start landing in spam, or disappear before they reach the inbox.

So every upgrade we do ends with three checks that have nothing to do with Laravel: which crawlers can reach the site, what robots.txt actually says after the move, and whether email authentication is in place. Making a business readable for AI is its own discipline, and it is what our AEO and GEO optimization work is about.

BURIED HISTORY

Buried History

There is another cost that rarely appears in an estimate. Memory.

The longer a system lives without maintenance, the fewer people remain who remember why it was built that way. The developer who created the strange workaround may have left. The manager who requested the integration may have moved to another company. The vendor may have disappeared. The documentation may never have existed.

Eventually someone opens the code and asks: "Why does this work like this?" And there is nobody left to answer.

That is why legacy modernization is partly technical archaeology. You are not just updating software. You are reconstructing decisions. Everything you build starts aging the day you finish it, and your website doesn't fail when your developer leaves. It fails years earlier, when nobody writes down why things are the way they are.

MARKET PRICES

What the Market Charges

This is also why honest providers avoid quoting a legacy upgrade from a version number alone. A single-version upgrade on a well-maintained application can be a one-day job. A legacy application on PHP 7 with patched dependencies, custom integrations and little test coverage needs an audit before anyone can responsibly price it.

The market reflects that range. Paid audits start at around $299, while many firms offer free "audits" that are really sales calls ending with a guess. At the other extreme, rewriting a legacy application in 2026 typically costs from $80,000 to more than $3 million, depending on codebase size and hidden business logic.

The useful conclusion is simpler: the cost of an upgrade is determined by what is inside the system, not by the number printed after "Laravel".

THE DECISION

Upgrade, Rebuild, or Wait?

There are three legitimate answers.

• Upgrade when the site still does its job, the business logic is sound and the main problem is age. Modernization preserves what already works while bringing the foundation forward, and it is the prerequisite for AI features and modern integrations later.
• Rebuild when the cost of safely upgrading approaches the cost of recreating the same functionality cleanly. A common rule of thumb, and one we use too: if the upgrade estimate exceeds roughly 60% of a clean rebuild, the rebuild conversation deserves to happen.
• Wait only when the site is genuinely about to be replaced anyway.

Otherwise, "wait" is not neutral. It is a decision to accumulate more dependencies, more uncertainty and more technical archaeology.

OUR PROCESS

How We Do It

Our process begins with one rule: the live site is never the place where anything is tried for the first time. A website that generates leads, takes payments, books appointments or sends orders somewhere else is a business instrument, not a laboratory. It sounds obvious. A surprising number of legacy problems begin because someone did the opposite five years earlier.

So our website modernization work follows a fixed order:

1. Audit. We look at the code, packages, PHP and Laravel versions, hosting, ownership, integrations, and the things that are easy to forget until they stop working. The client receives a written report with the upgrade path, a price and a timeline. The audit is a paid step: $300 for small and medium sites, from $1,000 for large e-commerce and complex projects. The report belongs to the client and can be used with us or with another team.
2. A closed copy. Staging is closed to search engines at the server level. We do not experiment with the live business.
3. One version at a time. Each framework step is its own commit, checked before the next one begins. If something goes wrong, we roll back one step instead of reconstructing the whole project.
4. The client's review. The client checks the upgraded site before anything changes on production.
5. A quick release. It can be quick precisely because the difficult work happened beforehand. Right after the switch we check what matters to the business: the site is open to Google, forms deliver, integrations respond. If the site also moves to new hosting, we follow the migration checklist most agencies skip.
6. Monitoring and notes. We watch the site for 24 hours, hand over written notes on every change, and carry a 30-day warranty.

The point is not that our process is complicated. The point is that the complexity belongs in a controlled environment, not on the live website. And if you want the site never to fall this far behind again, that is what website maintenance and support is for.

FIRST QUESTION

The First Question

Version numbers matter. But they are not the first business question. The first question is: what does this system do for the company?

Does it generate leads? Take payments? Feed a CRM? Manage products? Send orders to a warehouse? Serve a customer portal? Publish content that brings organic traffic? Run a process nobody remembers because it has become routine?

Once we understand that, the technical audit becomes much more meaningful. We can decide what must be preserved, what can be replaced, what should be tested, and what is simply historical baggage. When the questions go beyond the code, to who controls the hosting, the domain and the accounts, that is the territory of our digital ownership and debt audit.

That is also why two sites on the same Laravel version can have completely different upgrade costs. One may be a clean application with tests and current dependencies. Another may be ten years of custom business logic.

LOOK INSIDE

The Real Question

If your site runs on an old PHP, Laravel, WordPress or OpenCart version, the answer is not automatically "upgrade". And it is not automatically "rebuild".

The first step is much less exciting. Look inside.

Find out what you are actually running. Find out what depends on it. Find out what would break if you changed it. Find out what the business cannot afford to lose.

Only then decide whether the system needs an upgrade, a rebuild, or simply a maintenance plan that keeps it from becoming a problem again. That look inside is exactly where our website modernization work starts.

The most expensive legacy system is the one everyone assumes is fine.

FAQ

Frequently Asked Questions

Can I skip Laravel versions when upgrading?

No. Laravel is upgraded one major version at a time, for example 7 to 8 to 9, and PHP usually has to be upgraded alongside it.

How much does it cost to upgrade an old Laravel site?

It depends on what is inside, not on the version number. A single-version upgrade on a maintained app can take a day; a legacy app with custom code and no tests needs an audit first. We audit small and medium sites for $300 and large e-commerce projects from $1,000.

Can AI or Laravel Shift upgrade my site automatically?

They can automate much of the mechanical work. Someone still has to review each step and check that email, uploads, integrations and search indexing work afterwards.

Is it cheaper to upgrade or to rebuild?

Usually to upgrade. A rebuild is worth discussing when the upgrade estimate approaches about 60% of the cost of rebuilding the same functionality.

Why is my site not showing up in AI answers?

One common reason is technical: the hosting or robots.txt blocks AI crawlers such as GPTBot. It is worth checking after any hosting move or upgrade.

Which PHP version should a business site run in 2026?

A supported one: PHP 8.3 or newer is the safe choice. PHP 8.2 receives security fixes only until 31 December 2026.

Sources

• PHP Statistics 2026, FOSS Post (W3Techs, php.net, Zend, JetBrains, Patchstack)
• Laravel 13 release notes
• Laravel 9 release notes
• Laravel 13 Released, Laravel News
• Shift + AI: Fully Automated Laravel Upgrades, Laravel News
• Laravel Shift plans
• StackShield vs Laravel Shift
• Upgrading with Laravel Shift, CodeWithSusan
• How Much a Laravel Version Upgrade Costs, Dev Loader
• Laravel Version Upgrade Cost in 2026, Acquaint Softtech
• Laravel Version Upgrades: Why Falling Behind Costs More Every Year, Rocking Tech
• Cost to Rewrite a Legacy Application in 2026, Cadence