Taking over a Laravel SaaS codebase when your developer or agency leaves

Start with the question nobody asks: do you own the code?

Most founders assume that paying for software means owning it. In UK law it doesn't, on its own.

The Copyright, Designs and Patents Act 1988 makes the author of a work its first owner (section 11(1)). The exception is work made by an employee in the course of their employment, which belongs to the employer (section 11(2)). An agency or a freelancer isn't your employee. So unless their contract assigned the copyright to you, they may still own the code you paid for, and you hold whatever licence the contract gave you. And an assignment only counts if it is "in writing signed by or on behalf of the assignor" (section 90(3)).

So before anything else, find the contract and look for an assignment of intellectual property. If there isn't one, getting a short written assignment signed while the relationship is still civil is worth more than any technical step below. This isn't legal advice. If the contract is unclear, or the parting is not friendly, a solicitor should read it.

Two related things to check while the contract is open:

• Paid packages and licences. Commercial Composer packages, admin panels, themes and SaaS starter kits are licensed to whoever bought them. If that was the agency's account, the licence may leave with them.
• Data protection. If the departing developer had access to production data, they were acting as your processor. That access needs to end, and the next developer needs the right contract (more on that below).

The first 48 hours: get the keys before you need them

The urgent work in a takeover is access, not code. A product can run for months on code nobody understands. It can't survive the domain expiring or the payment account being locked to someone who has left.

Go through this list and, for each line, write down whose name or account it sits in today:

Moving the repository. If the code lives in the agency's GitHub organisation, the cleanest move is a transfer into yours. GitHub's documentation says issues, pull requests, wiki, stars and watchers move with the repository. Webhooks, secrets and deploy keys stay associated with it too, which is exactly why they need reviewing straight afterwards. Old links redirect to the new location, unless someone creates a new repository at the old address.

Rotating secrets. Anything the departing party could see should be changed: database passwords, API keys, cloud credentials, the mail provider's keys. Laravel's own APP_KEY needs care. The Laravel documentation is plain about what happens if you simply change it: all logged-in users are logged out, and data encrypted with the old key can no longer be decrypted. The safe way is to generate a new key and list the old one in APP_PREVIOUS_KEYS. Laravel then encrypts with the new key and falls back to the old ones when decrypting, so nobody notices.

How I'd run it: list first, change second. Changing passwords before you know what depends on them is how a takeover causes its own outage.

The first week: find out what you actually have

With access secured, the next question is what state the product is in. Four checks answer most of it.

1. Which Laravel and PHP versions, and how long they have left

Laravel's support policy gives each major version 18 months of bug fixes and two years of security fixes, with a new major version roughly every year. As of October 2026, Laravel's own table reads:

So a product on Laravel 11 or older gets no security fixes at all now, and one on Laravel 12 has until February 2027. PHP has its own clock. PHP.net lists 8.2's security support ending on 31 December 2026; 8.1 and older are already end of life. Laravel 13 needs PHP 8.3 or later.

Finding these takes a minute. The Laravel version is in composer.lock, and php -v on the server gives PHP.

2. Known vulnerabilities in the dependencies

composer audit checks the installed packages against published security advisories, from Packagist by default. Run it with --locked to audit what the lock file says is deployed, rather than whatever happens to be in a local vendor folder. Its --abandoned option also reports packages their maintainers have abandoned, which are the ones that will never get a fix.

3. Can it be built from nothing?

Clone the repository onto a clean machine, install the dependencies, run the migrations against an empty database and run the tests. Each step that fails is something only the departing team knew. Typical gaps:

• an .env value nobody wrote down
• a package from a private repository
• a manual step in deployment
• a database change made by hand in production and never written as a migration

If there are no tests, that's a finding too.

4. What runs when nobody is looking

SaaS products do a lot in the background: queued jobs, the scheduler, webhooks from the payment provider, emails on a timer. List every scheduled task and every queue the app uses, and where each one runs. A takeover that misses the job that renews subscriptions finds out at the end of the month.

Personal data: the paperwork changes with the developer

A SaaS product almost always holds personal data, and anyone who can reach the production database is processing it for you. UK GDPR Article 28 requires processing by a processor to be governed by a written contract that sets out what they may do with the data.

In practice that means two things:

• the outgoing developer's access ends, including copies of the database on their machines
• the incoming developer signs a data processing agreement before they get production access

It's a short document, and its absence is a common finding when a product is audited later.

Fix, stabilise or rebuild

Once the first week's checks are done, there's usually pressure to rewrite. Sometimes that's right. Usually it isn't, and the reason is simple: the existing code, however messy, encodes years of decisions about how your customers actually use the product. A rewrite has to rediscover all of them.

A reasonable way to decide:

• Stabilise and keep it when the product works, the framework can be brought into support with ordinary upgrades, and the problems are mostly missing tests, missing documentation and old dependencies.
• Rebuild a part when one area is the source of most bugs, or blocks something the business needs: billing, permissions, a reporting engine. Replace that part behind the same interface and leave the rest.
• Rebuild the whole only when the product can't be brought onto a supported framework and PHP version at a sane cost, or when the data model is wrong for what the business has become.

Whichever it is, the first job is the same: get the product onto supported versions, with a working build and a tested backup. That's also the point at which a sensible decision about the rest can be made.

Afterwards: what a maintenance retainer should cover

Once the product is stable, the question becomes how to stop this happening again. A SaaS maintenance retainer is the usual answer, and it's worth knowing what a good one contains:

• Security patches on a schedule. Framework and PHP within their support windows, and dependency advisories checked every month, not when something breaks.
• One planned major upgrade a year. Laravel releases a major version roughly every first quarter, so the upgrade can be budgeted rather than discovered.
• Backups that are restored, not just taken. A restore test at a fixed interval, written down.
• Monitoring with a named person who is told when jobs fail, the queue backs up or errors spike.
• Everything in your name. Repository, hosting, domain and payment accounts stay in the company's accounts; the developer gets access, never ownership.
• Exit terms in the contract. The code, documentation and access are handed over on request, unconditionally, and copyright is assigned in writing. That's the clause that would have made this whole guide unnecessary.

If you're in the middle of a takeover now, the stalled build and SaaS takeover page sets out how I take one on. What an MVP costs in the UK covers the numbers if you're weighing a rebuild.