The engagement started with one job: take a Laravel product that was already live and earning, and move it onto a maintained boilerplate framework so that the next upgrade would not be the first one. It ended five and a half years later, after the application had been carried through every Laravel major and PHP version released in between, with feature work landing the whole way.
The problem: a product that had outgrown its first codebase
The application had been built quickly, as products usually are, on an early Laravel release with a hand-rolled structure for authentication, roles, settings and admin screens. None of that was wrong. But every one of those pieces was now something the owner alone was responsible for, and the framework underneath had moved on.
The owner was based in Singapore and ran the product as a business, not as a software project. What they needed was not a rewrite. They needed the existing behaviour preserved, the undocumented corners replaced with maintained equivalents, and someone who would still be there when the next Laravel release changed the rules again.
What we did: the migration
- Mapped the existing application first. Every route, model, job and third-party package was listed with what it did and whether the boilerplate already provided it. The decision to keep, replace or drop was written down before any code moved.
- Moved onto the boilerplate in stages. Authentication, roles and permissions, the admin layer and the settings system were swapped for the boilerplate's maintained versions one at a time, with the old implementation kept alive until the new one was proven against production data.
- Preserved behaviour, not code. Where the original application did something the boilerplate did not, the behaviour was re-implemented in the boilerplate's conventions rather than bolted on, so later upgrades would carry it forward for free.
- Rehearsed every cut-over on a staging copy. Nothing touched the live product until the same deployment had run cleanly against a copy of real data.
How it worked for the next five years
Once the product sat on a maintained foundation, the retainer settled into a rhythm that is the whole point of the arrangement:
- Framework upgrades as they shipped. Each new Laravel major was taken in turn, never skipped, so the application was always one step from current rather than four. The PHP runtime moved in step so the product stayed inside security support.
- Packages watched, not assumed. Third-party packages were reviewed on every upgrade. The ones that had stopped being maintained were replaced with living equivalents before they became the thing that blocked the next release.
- Backend feature work in the same hands. New functionality, integrations and fixes were built by the same engineer who did the upgrades, so there was never a hand-off between "the person who knows the code" and "the person who keeps it running".
- Deployment and server upkeep included. Releases, server patches and the occasional incident were part of the retainer rather than a separate conversation.
The outcome
A product that had started on an early Laravel release was still running on current Laravel and current PHP when the engagement closed, without a rewrite and without a gap in service. The owner spent the intervening years adding to the product instead of worrying about what was underneath it. That is what a retainer is for.
Running a Laravel application you cannot afford to leave behind?
We do this on a fixed price for the upgrade and a monthly care plan afterwards. Start with the free audit, see the upgrade packages, or talk to us.