Engineering
Framework and Version Upgrades
Frameworks stop getting security fixes on a schedule, and the longer an upgrade waits, the more versions it has to cross. We plan and run Laravel, Drupal, React Native and PHP upgrades on a staging copy first, with a rollback written down before anything goes live.
What we upgrade
Laravel and Nova
Laravel majors and the Nova admin that rides on them, including multi-version jumps. We have scoped Laravel 8 to 13 with Nova 3 to 5 on a member portal, and proposed Laravel 11 to 12 with Nova 4 to 5 and a Mix to Vite move on a serverless platform. The approach is in our Laravel upgrade guide, and the wider service is Laravel development.
Drupal 10 to 11
Drupal 10 reaches end of life on 9 December 2026. We are upgrading a regulator's Drupal site from 10.1 to the 11.3 line, with all 30 contributed modules done on staging and testing and release still to come. Read what end of life means and how the upgrade runs.
React Native and Expo
Moving a large React Native app to a current React Native and Expo release, with a phased store rollout so a bad build can be stopped early. We scoped this for an app of nearly 200 screens. See React Native development.
PHP versions
The PHP release under the framework is often the first deadline. We plan PHP moves alongside the framework work so you do not upgrade twice. See PHP 8.2 end of life for the dates.
How an upgrade runs
Every upgrade starts with the same audit: the current version, the packages and modules that block the next one, the tests that exist, and the environment. That gives a plan with decisions in it, not a surprise in week three.
Audit
Dependencies, deprecated code, test coverage and hosting, with a written view on the packages that are abandoned.
Staging first
The upgrade is done and tested on a copy. Production is not touched until staging is clean.
Baseline and acceptance
Page speed and key journeys are measured before the work, so the result can be compared with a number rather than a feeling.
Release with a rollback
A documented rollback is agreed before the release, and the cut-over is timed for your quiet period.
When to rebuild instead
Upgrade or rebuild
Most applications are better upgraded than rebuilt. When most packages are abandoned or nobody can say what the system does, a staged rebuild is safer. Our project rescue audit tells you which applies.
The proof
Work we have shipped, not a capability deck.
Common questions
Which framework upgrades do you do?
Laravel and Laravel Nova, Drupal, React Native and Expo, and the PHP versions underneath them. Our Laravel upgrade guide and Drupal 10 to 11 guide set out how we approach two of them.
Can you skip versions, say Laravel 8 straight to 13?
The code usually moves one major at a time, because each upgrade guide assumes you are on the previous version. The work can still be planned and delivered as a single project, with the intermediate steps tested on a staging copy rather than released one by one.
Will the site or app be down during the upgrade?
The upgrade happens on a staging copy, not on the live system. The release is planned around your quietest period, with a rollback written down beforehand. Where the hosting allows it, we plan the cut-over to avoid downtime.
What if a package we depend on is abandoned?
We find these in a dependency audit at the start, so you hear about them before you commit. The options are a patch, a fork, a replacement or removing the feature. Each is a business decision with a different cost, and we put them in front of you with a recommendation.
Is it better to rebuild than upgrade?
Usually not. If the code is understandable and the behaviour can be tested, an upgrade is faster and carries less risk. A rebuild earns its place when most packages are abandoned or nobody can say what the system does. Our project rescue audit gives you a view on which applies.
How long does a framework upgrade take?
The range depends on how many versions behind the application is and how well tested it is. The dependency audit is what turns that into a number. The honest answer is that scope decides it, not the platform. How we engage sets out the engagement models and the timeline ranges each one tends to run to, and we give you a milestone plan once we have scoped the work rather than a number before.
Trusted by
Start a conversation
Start a conversation
Tell us what you want to build, fix or scale, we’ll come back with a clear way forward.