Laravel Application Takeover Checklist

The line-by-line checklist we work through before taking responsibility for someone else's Laravel application — access, environment, dependencies, data, queues, and the handover artefacts that should exist.

Taking over an unfamiliar Laravel application is a repeatable process, not an act of heroism. This is the checklist we work through before we accept responsibility for a codebase, published so you can run it yourself or hold whoever you hire to it.

Access and ownership

[ ] Repository ownership transferred to an organisation you control
[ ] Hosting account billing in your name (Forge, Vapor, Ploi, AWS, DigitalOcean)
[ ] Domain registrar and DNS provider logins verified with 2FA
[ ] Database credentials, and confirmation of where backups are stored
[ ] Object storage (S3 or equivalent) bucket ownership and lifecycle rules
[ ] Stripe, mail provider, error tracker and any external API accounts
[ ] A written list of every cron entry and daemon running on the servers

Environment reproducibility

[ ] composer install completes on a clean machine with no manual patches
[ ] .env.example lists every variable the application reads
[ ] The app boots with php artisan serve or in a container
[ ] php artisan migrate --seed builds a usable database from empty
[ ] Front-end assets build (npm ci && npm run build) without pinned local hacks
[ ] README documents the local setup in fewer than ten steps

If the application only runs on one person's laptop, treat that as a critical finding, not an inconvenience.

Framework and dependency health

[ ] Laravel version recorded and checked against the security-support window
[ ] PHP version recorded and checked against php.net's supported versions
[ ] composer audit run and every advisory triaged
[ ] Abandoned packages identified (composer show --all and a look at each vendor's last release)
[ ] Direct dependencies distinguished from transitive ones
[ ] Any forked or vendored packages found and documented

Data and privacy

[ ] Full database dump taken and test-restored locally
[ ] Storage directory copied and checksummed
[ ] Personally identifiable data inventoried — you cannot protect what you have not listed
[ ] Encrypted columns and APP_KEY dependencies identified before any key rotation
[ ] Backup schedule verified by restoring, not by reading a config file

Runtime behaviour

[ ] Queue workers confirmed running, with a named driver and a supervisor config
[ ] failed_jobs table inspected — a large, old table means silent feature failure
[ ] Scheduler cron entry present and schedule:list reviewed
[ ] Horizon or an equivalent dashboard reachable, if Redis queues are in use
[ ] Log destination known and log growth bounded
[ ] Error tracking wired up and receiving events

Security hygiene

[ ] APP_DEBUG=false in production, verified on the live host
[ ] No credentials committed to the repository history
[ ] Storage buckets not publicly listable
[ ] Admin routes behind authentication and authorisation, not obscurity
[ ] Mass-assignment protection reviewed on models exposed to user input
[ ] Rate limiting present on auth, password reset and public API endpoints

Tests and change safety

[ ] Test suite exists, runs, and passes on a clean checkout
[ ] Coverage of the two or three flows that make money, at minimum
[ ] CI pipeline runs the suite on every pull request
[ ] A deploy can be rolled back, and someone has actually done it once

Handover artefacts that should exist

[ ] Architecture note: the models, the jobs, and the external systems
[ ] Runbook: how to deploy, how to roll back, what to do when the queue backs up
[ ] Access matrix: who holds what, and what to revoke when someone leaves
[ ] Known-issues list with severity, so the next developer inherits knowledge instead of surprises

How to use this

Work top to bottom and mark each line pass, fail or unknown. "Unknown" items are the ones that hurt: they are the parts of the system nobody has looked at. A takeover is finished when there are no unknowns left, not when the app deploys.

If you want this run for you as an independent document, the Laravel Triage Audit covers the framework, dependency, runtime and security sections and returns a ranked fix list in five business days. For applications that are already broken in production, the Laravel application rescue sprint starts at $1,000.