Laravel Upgrade in the UAE: Support Dates, What Breaks and the Order of Work
Laravel upgrade in the UAE: PHP 8.2 security support ends 31 Dec 2026 and Laravel 12's on 24 Feb 2027. What breaks, the order of work and who does it.
A Laravel upgrade in the UAE is easy to put off while the app still works. But PHP 8.2 stops receiving security fixes on 31 December 2026 and Laravel 12 on 24 February 2027, and after that, a newly found flaw in your app’s foundations stays open while the packages you depend on move on without you.
When should you plan a Laravel upgrade in the UAE?
Quick answer: Plan it now if your app runs on PHP 8.2 or older, or on Laravel 12 or older: PHP 8.2 loses security support on 31 December 2026, Laravel 12 on 24 February 2027. Audit your packages, put tests on the paths that move money, upgrade one major version at a time and release in stages, with a way back.
Running an older Laravel app? Plan your Laravel upgrade with us →
What waiting costs you
An unsupported version doesn’t stop working on the day support ends. What stops is the fixes. A security issue found next year will be patched only in supported versions, and the packages your app relies on, such as payment SDKs and PDF or Excel libraries, drop old versions as they release new ones. Each month you wait, the jump gets longer: one version becomes three, and a small feature request turns into an upgrade project before the feature can start.
Which version are you on, and what should you do?
Run php artisan --version and php -v on your server, or ask your developer, then find your row. Dates are from the Laravel support policy and PHP’s supported versions, checked on 24 October 2026.
| You are on | Support today | What to do | Size of the job |
|---|---|---|---|
| Laravel 10 or older | No security fixes: Laravel 10’s ended on 4 February 2025, older versions earlier | Climb one major version at a time to 13, moving PHP to 8.3 or newer on the way. From very old versions, compare the climb with a rebuild | The largest: several steps, many packages |
| Laravel 11 | Security fixes ended on 12 March 2026 | 11 to 12, then 12 to 13 | Usually moderate |
| Laravel 12 on PHP 8.2 | Bug fixes ended on 13 August 2026; PHP 8.2 security fixes end on 31 December 2026 | PHP to 8.3 or newer first, then Laravel 13 | Two smaller steps |
| Laravel 12 on PHP 8.3 or newer | Security fixes until 24 February 2027 | Laravel 13 before that date | Usually the smallest |
| Laravel 13 | Bug fixes until Q3 2027, security fixes until 17 March 2028 | Keep packages updated, and plan for the next major version | Ongoing upkeep |
How to read it: Laravel 13 needs PHP 8.3 or newer, and Laravel 12 runs on PHP 8.2 to 8.5. That overlap is what lets you move PHP first, on Laravel 12, and the framework second.
What this means for you: on Laravel 12 and PHP 8.2, you have two deadlines and two smaller jobs. Move PHP before 31 December 2026, then Laravel before 24 February 2027. Doing them in that order keeps each release small enough to test properly.
What breaks in a Laravel upgrade
Laravel keeps each major release small; its guide estimates the 12-to-13 framework changes at ten minutes. Older apps take longer because of what sits around the framework:
- Packages. Every Composer package must support the new Laravel and PHP versions. Maintained packages usually do. Some were abandoned and need replacing, and that is often where the time goes.
- PHP changes. Each PHP version deprecates old behaviour; PHP 8.2, for example, deprecated the dynamic properties older code used freely. Deprecation warnings left alone become errors in a later version.
- Framework changes. Each step renames or tightens something. In Laravel 13, the CSRF middleware has a new name, and syncing the new session settings can log every user out once.
- Custom code inside the framework. Overridden core classes, home-made global helpers and copied vendor files break first.
- The server around the app. Queue workers, scheduled jobs, PHP extensions and the front-end build all move with the upgrade.
- Integrations. Payment, SMS and courier SDKs pinned to old versions each need a test against the provider’s sandbox.
How a Laravel upgrade runs, step by step
- Audit. Versions, every Composer package and whether it supports the target, custom code that touches the framework, and the server. The audit sizes the job before anything changes.
- Tests before changes. Cover login, payments, invoices, reports and every integration. If the app has no tests, these come first, because they decide whether the upgrade is safe to release. Our article on quality assurance in software development explains why someone other than the developer should run them.
- One major version at a time, on a branch. Follow Laravel’s upgrade guide for each step, fix deprecations and replace abandoned packages. PHP moves at a point where both Laravel versions support it.
- Staging with realistic data. A copy of production with personal data masked. The tests run, then QA checks screens, queues, scheduled jobs and emails by hand.
- Staged release with a way back. Release in a quiet window, with a backup and the previous version ready to restore. Watch the error logs and queues closely for the first days, then start the next step.
Not sure how far behind you are? Send us your Laravel and PHP versions and your
composer.json. We reply with the steps we see, the packages likely to need replacing and how the release could be staged. Plan your Laravel upgrade with us →Not ready for a call? Ask for our company profile and we’ll send it to you.
Upgrade or rebuild?
An upgrade keeps your code; a rebuild replaces it. Upgrade when the app is organised and the business still works the way the app does. Consider a rebuild when the app is several major versions behind, has no tests, and the features need changing anyway. Our guide to legacy system modernization in the UAE compares refactoring, rebuilding and replacing, module by module.
Hire Laravel developers or bring in a team?
Who does the upgrade depends on who knows the app today, and what happens after it:
- Your own developers, if they know the app well. An outside review of the audit and the plan is a sensible check before the first release.
- Our hours, on time and materials, for an upgrade whose scope may shift as the packages are checked. You see the hours logged against each task.
- A dedicated Laravel developer who joins your team for the upgrade and stays for the upkeep. We source candidates for the role, and you interview them and choose who joins, through staff augmentation in the UAE.
- A full-time hire, when the app needs a Laravel developer every month, not only for the upgrade. Until then, you pay for the upgrade rather than a salary that runs on after it is done.
How we run Laravel upgrades
We have upgraded Laravel versions for clients; the projects are under NDA, so we don’t name them here. Laravel and PHP are among the stacks we build in, alongside .NET, Java, Go, Python and Flutter.
Two of the ways we work matter most on an upgrade. Independent QA: a dedicated testing and quality assurance process, so the person checking the upgraded app on staging is not the one who changed it. CTO oversight: every project is supervised by senior technical leadership, who decide with you whether to upgrade or rebuild, and in what order. Upgrades and upkeep are part of our custom software development in Dubai.
Send us your versions
Since 2014 we have built software for more than 100 clients across the UAE, Saudi Arabia, Qatar, Kuwait, the USA and Canada, from our headquarters at Dubai Digital Park in Dubai Silicon Oasis and our offices in Houston and Alexandria. Send us your Laravel and PHP versions; the package list helps if you have it. Your price is agreed in your proposal, and it follows how many versions you are behind, the packages to replace, the test coverage and the integrations to check.
Plan your Laravel upgrade with us → We ask about your goal, what you use today, your timing and who else should be involved. You leave with clear next steps. The call commits you to nothing, and we sign an NDA first if you want one.
Frequently asked questions
How long does a Laravel upgrade take?
One major step on a tidy, tested app can be small: Laravel estimates its 12-to-13 framework changes at ten minutes. The time goes into packages, custom code and testing, and it grows with every version you are behind. The audit sizes the job before anything changes, and your timeline is agreed in your proposal.
Can we jump straight from an old version to Laravel 13?
Not safely in one step. Each major release has its own upgrade guide, and the changes stack up, so the work goes one version at a time, with tests run at each step. The steps can be released together once the last one passes, but they are made and tested in order.
Will our app go down during the upgrade?
It doesn't need to. The work happens on a branch and a staging copy, and the release goes out in a quiet window with a backup and the previous version ready to restore. One thing to plan for: some configuration changes, such as a new session format, can log users out once, so agree when that happens.
What if our app has no tests?
Then the first task is a short set of tests on the paths that matter most: login, payments, invoices, reports and integrations. They are what tells you the upgraded app still does what the old one did. The same tests keep paying off after the upgrade, on every release that follows.
Who owns the code after the upgrade?
You do. The code and IP pass to you at the end of the project, once it is completed and paid. On staff augmentation, the work is done in your own repositories.
